I'm going to have to oppose this on the basis that I see no reason to add more bloat to our page size for what seems to already be working just fine. I'm all for good typography, by all means, but unless someone can explain exactly why this is superior I'm opposed.
@skyruler : I am getting some feedback about the new diff/code font. @DouweM and others feel (to summarize, hopefully accurately) that changing to code font is too much change. They feel that because devs are creatures of habit a change like this is bad and will make reading code an uncomfortable task. Other style changes are good but changing the font is a topic close to the hearts of many devs.
douwe [8:47 PM]
@jschatz: It’s not that easy. I’m very passionate about certain monospace fonts vs others
gabriel [8:47 PM]
me too
douwe [8:46 PM]
@jschatz: I think it warrants more discussion. I have to look at that font all day... It may be prettier in a vacuum, but I don’t see a reason to change it.
You can see the change in the linked MR or here. I am still reviewing it. @DouweM@brodock feel free to chime in but I think the problem is that we are all very used to Menlo as it is the default/font-of-choice in all editors and a change like that is drastic.
@connorshea What we are going to do (if we can resolve this disscussion) is use only one font (regular) and leave out bolds, italics, etc. We'll have to change the diff styles so they don't use any bolds/italics/other. One font for that page will add roughly 85kb. Or less.
I am very passionate about the way my editor looks, from the background of the editor, to the color of the highlighting, to the font size and the font family. And an important part of that is consistency, between Atom, Terminal, Visual Studio, Xcode, and GitLab, all of which I use to work with code in varying degrees of regularity. I have a used a lot of different editors, and a lot of different typefaces to read code and work on code, and I've tried some of the "hip" ones like Source Sans Pro etc, but I keep coming back to Menlo, in all of my editors. Of all the typefaces I've used to read and work on code, it's the one I like most.
Menlo is the default in Sublime Text, it's the default in Xcode, and the defaults in Terminal.app, Atom and GitHub are so similar you almost can't see the difference. Developers know Menlo, developers are used to Menlo and (apparently) developers like Menlo. Developers are creatures of habit, and the editor is their little nest. They will notice, and they will be upset.
Please don't change something like this without a lot of consideration; it's like replacing the rug in my room because you thought it looked like it was from the 90s, even though I have to sit and work here all day. I don't want no fancy 2016 rug, I want my cozy 90s Menlo rug!
I really, really don't like the way Code Pro looks. Characters are way too wide. I don't see a difference in readability, I (and millions of others, based on the defaults I just listed) have been using Menlo for years without a problem.
@connorshea thanks for pointing that out! I wanted to see what was using up all that space. And it turns out that just the auto complete data is .5mb. So I made an issue. Should shave off 1.5s of page load https://gitlab.com/gitlab-org/gitlab-ce/issues/14319.
Not directly comparable, but 85KB is just under a fourth of GitHub's total page size. I'd say it's worth re-considering adding that kind of weight.
If you load gitlab.com (logged in) and github.com (logged in) on mobile with 3G (unfortunately all too common around where I live, thanks Sprint), GitHub is much faster than GitLab.
@connorshea so we have 2600KB fonts? I just checked we have resources on activity feed around 2,12MB and GutHub in average 1,50MB, I don't think that any font is the issue in that case.
@skyruler I'm not trying to suggest that the page weight difference is made up entirely of fonts. I'm saying that we already have a significantly larger payload than the competition, and we need to take care when adding anything extra to that.
Safari makes up a little under 10% of the Global browser marketshare, and just under 25% in the United States (according to Can I Use, at least), and it flat-out does not render text before it downloads a font. I'm not a fan of that "feature", by any means, but it has to be taken into consideration when using custom fonts.
Chrome has a throttler in its Network panel, it's a pretty good way of estimating what it would look like to load a page on a given connection. This is this issue with the network throttled to "Regular 3G":
32 seconds to DOMContentLoaded!
@jschatz1 I actually tried to test that, but unfortunately I'd either need to host two copies of GitLab somewhere for comparison or figure out how to override the site stylesheet, which I can't figure out how to do in any browser. Firefox lets me force my own fonts on a site, but it doesn't seem to stop the fonts from downloading. Testing it locally is possible, but not entirely accurate given that the site would be loading over the local connection.
we can always get improved speeds if we enable HTTP2 connections on HAPROXY / nginx
With SPDY 3.x improvements + pipelining we can reduce total load time by better using our communication channels.
We also waste too many KB with unoptimized avatar / attachment images (we should do lossless compression on user generated content like avatar images, attachments etc... or re-encode to webp, etc).
Just done a bit of test through Google Fonts of source code pro and it only loads when the font is actually used. Page loads all resources without the source code font & then once you reference it in the CSS for the current page it then loads the font.
So a new font wouldn't slow the whole site down - only the page it is used on.
@iamphill I am saying we should find out how long it takes. Using only Source Code Pro Regular. To dispel or accept it's results and end that part of the argument.