The bigger details are usually what move the needle. Don't get stuck optimizing a local maxima, which is very easy to do if you're using AB tests. Arguably the point of an AB test is to find the local maxima, but the goal should be to broaden the search space and look for something closer to the global maxima.
Web fonts aren't popular just because they're pretty. They continue to be used everywhere because they offer a consistency that's impossible to get otherwise. With a plethora of mobile devices and desktop environments, you can't get a consistent look-and-feel for a site with just installed fonts. For some really basic sites, that's totally okay and even hits a nice quaint aesthetic, but for the kinds of sites that people pay money for, that's not good enough.
Variability in system fonts means that getting consistent paragraph and header widths and spacing is impossible. It means that the text looks too dark sometimes and too light other times. It means that the font appears unreadably small sometimes and obnoxiously large other times. It means having to build a font stack and then keep it updated as preinstalled fonts change. It means spending a lot of time dealing with issues like Helvetica Neue looking okay on MacOS but rendering like ass on somebody else's desktop because they installed a free knock-off of it. It ultimately introduces a lot more complexity and fragility than properly using a locally-hosted web font.
So don't waste resources trying. You'll create more problems than you'll solve.
Nobody tests their web fonts as thoroughly as the default fonts have been tested on their respective platforms and devices. Web fonts can have odd platform-specific bugs with kerning, hinting, and subpixel rendering. I've had web fonts render without hinting on Edge, but look fine on Chrome & IE on the same system. How does one even begin to write automated tests that detect issues like that? Using the default fonts guarantees you'll never have to worry about such bugs.
The system's installed fonts are guaranteed to work. They improve performance. They prevent re-flows. And they're what the user is accustomed to. These reasons and more are why Facebook, Github, Twitter, Wordpress, and many others use the system fonts.
End users don't care if they get Arial, Helvetica, Helvetica Neue or system sans-serif -- except in the case where they set it up themselves, and they're rather upset that you aren't using their preferred versions. But that's OK too, because those end users are almost as rare as designers.
All the inconsistency problems you're noting are of your own devising.
In conclusion, http://bettermotherfuckingwebsite.com/ forever, because https://thebestmotherfucking.website/ goes too far.
That sounds backwards to me. Using standard fonts is how you achieve consistency. Using a custom font for just your webpage is not helping me (the user) get consistency at all. That's what 'standard' means.
(Frequently, custom fonts also hurt readability, which is why I hit "reader mode" on nearly every webpage these days. Every single day I run across webpages with custom fonts that I literally struggle to read.)
The situation is just like early versions of Mozilla or Java, where they used the same UI toolkit on all platforms for "consistency". Eventually, programmers realized that users tend to switch between applications more often than they switch operating systems, so the way to achieve consistency for actual users is to match the local environment.
> Variability in system fonts means [...]
Yes, all of those are real problems. That's why I've set up my web browser in a way that results in legible text for me. As per the Pottery Barn Rule, if you use a custom font, you're taking responsibility for all of these issues -- and you're going to screw up at least some of them (or something you didn't think of), and I'll hate your webpage for it.
But if you make like, a productivity tool or some sort of SAAS? just use system fonts.
Edit: then again, I say this as a designer who has worked a lot in companies with heavy emphasis on accessibility and performance, so that may be a bit of my own bias...
Everyone is on different screen types. From desktop to mobile, different OS, low to high DPI, different resolutions to screen size (1080p on 21in monitor vs 27in monitor), different font sizes, different brightness/colors/contrasts. Most designers I have worked with have never looked at the site on different kinds of screens. Most designers only care about how it looks on mac.
Windows render font differently compare to Mac/Android. Chrome on windows renders font differently compare to Firefox.
You will never be able to render your site perfectly on all the devices.
On the other hand, I care about the loading time of web sites and the privacy issues brought by the pervasive use of Google Fonts.
I recently ripped the webfonts out of one web site and the page load time halved. I was like, "You have to be kidding!"
Also, this list won't help anyway. The clients aren't picking fonts by performance.
In fact, well engineered fonts are absolutely crucial in any medium, not just electronic. From road signs to tax documents, from web pages to warning labels - fonts are one of the most underrated aspects of graphic design. Why though? Each font has a specific purpose. Mono space fonts are used for things like code and tabulated figures while fonts such as Baskerville excel at prose. There is so much to say, I don’t know what to pick and choose. Honestly, study typography from an engineering take - it is a tool.
Perhaps there is a distaste for gawdy, large and loud typography and all the shenanigans designers do today, but that has nothing to do with why fonts are important.
I think this oversight is highly disappointing because there is bigger fish to fry. Javascript payloads, bloated reactive websites and overall regression in what a great UI should be.
Perhaps for English and other Latin-based alphabets. But for some other writing systems, system fonts are simply terrible.
If you're content with mediocrity, sure. But if you value your brand you will want the fonts to send the message that you want to be associated with your brand. Also, you'll probably want them to be in line with the rest of the design.
The default fonts on Windows, Mac, iOS, and Android are the result of millions of dollars of R&D. Custom fonts are far more likely to have issues with kerning, hinting, or subpixel rendering. They also degrade load times and cause a re-flow when the font is done downloading.
All of these issues can be avoided by using the fonts that are already installed on the user's device. That's what Github, Wordpress, Facebook, and Twitter do. They all have distinct brands without custom fonts.
That's an important point. Unfortunately loading custom fonts slows down the experience and when that happens it does tell me something about the brand.
(It's likely the overhead of loading fonts is drowned out by the overhead of all the trackers, but I have those blocked which speeds the web up enormously. Likely that makes me not the kind of reader you want...so this works out well for both sides).
If a typical HN reader had their way, every single webpage on the internet would be text-only, with monospace font, and an RSS feed.
And what a glorious improvement that would be!
(I could do without the RSS feed, though)
different fonts give sites different personalities, adding richness to the web (whether you appreciate it or not). for 99.9% of sites, being overly focused on font size/download speed is an unnecessarily trivial optimiztion.
with that said, don't remotely load google fonts because privacy does matter. for most sites, the speed and bandwidth difference doesn't matter. just serve them as first-party, cacheable assets.
That said, serving from your own domain is a great way to make sure that a third party can't break your fonts, in addition to what you mentioned about privacy.
Surely if there is one thing we have learned from the culture of comparative testing in recent years, it is that assumption is the mother of all #$%& ups.
Everyone commenting in this discussion to the effect that all sites should use system default fonts is making a huge assumption that using other fonts does not have a material effect on anything that matters to the user and/or the site owner. And yet, both in industry and in academia, lots of research has been done that did observe changes in outcomes even from relatively subtle (at least to an untrained eye) changes in typography.
If someone wants to argue that they personally do not like web fonts then of course they are free to block them. Any major content blocker on their platform of choice will do this easily enough. But if someone wants to argue that everyone else should avoid web fonts, they had better bring data. In this entire discussion, I don't see much of that, only personal preferences and the odd anecdote about a bug in a specific situation.
Another example is alternatives to image assets. Emoji are the common example here, but the private use areas [1] mean that fonts can be used to deliver what would otherwise be raster images or SVGs. A great example is mixing symbols in with text without resorting to images or CSS-via-spans to solve the problem. Think public transit icons, for instance.
For many websites, the choice of font can make a noticeable difference to the appearance of the site and yes, make it more aesthetically pleasing. Of course, it's best to choose only a minimal number of font weights to keep downloads size to a minimum.
> On this site, in which performance is the only name of the game, I forgo web fonts entirely, opting instead to make use of the visitor’s system font. This is fast, incredibly well suited to the device in question, and has almost zero engineering overhead.
So… well read, I guess?
Designers tend to disagree.
I personally agree with you, but if we were not a very small minority, lynx[1] would be much more popular today..
This is my general approach now. Feels like a lot of work to keep up with what the ideal remote loading snippet is when local hosting can be simpler and the fastest option. The deep dive into how all the approaches compare is really interesting though.
It's frustrating web developers still need to deal with this complexity just to load a font. I don't think most non-frontend developers realise how much effort it takes to make a nontrivial high performance website. Most of the time in frontend there's many ways to do the same thing, each with their own subtle performance tradeoffs.
It's probably a good idea to refresh the fonts off Google once or twice a year though. Although not often, these font file get updated.
SVG is a nice option for logos. You can inline the SVG file directly into the HTML as well so there's no loading delay - especially useful for logos that need to be rendered immediately at the top of the page.
Chrome is pretty chatty with Google; you probably wouldn't notice the extra traffic from these notifications.
The website loads from start to finish in 200ms on my end (in Berlin of course). At this point, DNS and server distancs are bigger issues than what's on the page. I find the call for system fonts rather funny, because it's such a pointless sacrifice.
Another significant benefit is privacy. I don't like sending visitor information to third parties. I removed Google Fonts requests, and I'm working on removing Analytics. Once this is done, there won't be any third party requests on the page.
I'm okay with 1st party usage, but I don't want Google following me around the web.
EDIT: Okay, still a few things they could improve on (https://gtmetrix.com/reports/csswizardry.com/N9gkLyhq)
When I see pages formatted like this, I tend to make a decision between opening the inspector and fixing the fonts, or just not bothering to read it, since it's clearly not designed to be read.
Original: https://qui.suis.je/drop/faster/illegible.png
400 weight: https://qui.suis.je/drop/faster/better.png
400 weight and black: https://qui.suis.je/drop/faster/black.png (not necessarily an improvement, once the weight is normal).
> On this site, in which performance is the only name of the game, I forgo web fonts entirely, opting instead to make use of the visitor’s system font.
Faster still is to use already installed fonts, as others have noted. But don't use "system" fonts if that means UI fonts like San Francisco or Segue. Exploit the rich font options on the desktop: Georgia, Sitka Text (Windows 8.1+), Calibri, Hoef, etc. Bootstrap and Medium started a ridiculous fad of using system UI fonts for body text. There are actual body text fonts available people.
There are tools like https://google-webfonts-helper.herokuapp.com/fonts which will get you the needed css.
<link rel="stylesheet"
href="$CSS&display=swap"
media="print" onload="this.media='all'" />
The whole thing is a dubious technique anyway because it depends on JavaScript—if JavaScript is disabled, the stylesheet will now not load ever. You’re probably OK with that in a case like this (the fonts are deliberately optional), but inevitably with such techniques people start using them on stylesheets that actually are important, because “it makes the page load faster” or something.
P.S. Why the trailing slash on the tag? It’s completely useless, by definition, and trailing slashes can mislead people into thinking that you can close tags that way, which you can’t.
"This will implicitly tell the browser to load the CSS file in a non-blocking fashion, applying the styles only to the print context. However, the moment the file arrives, we tell the browser to apply it to all contexts, thus styling the rest of the page."
The browser ignores the file because it's just for print and can be loaded later on. But when the page is fully loaded (onload="..."), the media property is set to "all" and does not stay at "print". When this happens, the browser now knows it should load it as soon as possible and does so.
As you mentioned: if JS is disabled, the file will never load. The author states that his solution is not 100% perfect: "[Async webfonts] should always be considered an enhancement anyway, so we need to be able to cope without them; we can and should design decent fallbacks for use during their absence, and;"
As it stands, browsers are fetching print stylesheets all the time (sure, at idle priority, but they’re still fetching them) even though they’re used less than once per million page loads. This seems silly.
Simple: so that XML parsers can load the HTML, as they are not aware of the HTML context which allows "unclosed" tags.
So why would you parse one with an XML parser? It’s just wrong. (And an effort doomed to failure if you ever have to deal with documents other people wrote, because very few will parse.)
I address this twice in the article, which presumably you didn’t read.
> P.S. Why the trailing slash on the tag? It’s completely useless…
Are you just looking for things to be unhappy about?
Concerning the trailing slash: it’s something I’ve long been puzzled about because it seems to me to be not merely pointless but slightly counterproductive. Here you’ve evidently deliberately inserted it, and I can’t for the life of me understand why people are doing this, so I’m asking.
I'm involved in fonts for my native language (Sinhalese), and let me tell you: dealing with fonts for multiple languages are is not easy! Some of the Asian languages including Sinhalese are pretty difficult to get right, and glyphs are quite difficult to give a character without breaking their meaning, specially when it comes ZWJs, diacritics, etc.
You can subset a font like Noto to serve your languages, but it will come pretty large. Note that for web, @font-face declarations can set a Unicode character range for each font file, so browser downloads those fonts only when necessary.
Good article though, great research effort.
LE: I don't have that problem because I don't use async CSS. I didn't even know that was a thing, why would you use JavaScript to make sure the browser doesn't wait for the CSS to load? If JS is disabled you end up without any styles or have to add a noscript fallback. Also, why would you let the browser render FOUC?
It does not work with fonts as far as I'm aware, but it can serve popular libraries locally, saving bandwidth, and protecting privacy.
You mean like being rendered into a canvas to get a high-entropy fingerprint of your device?
1. https://security.stackexchange.com/questions/91347/how-can-a...
2. https://threatpost.com/of-truetype-font-vulnerabilities-and-...
3. https://googleprojectzero.blogspot.com/2015/07/one-font-vuln...