Just use the built-in fonts. Use a good fallback list so each platform gets a good option. Specifying custom fonts is largely a waste of bandwidth for a very marginal improvement in aesthetic. The people who care most are the ones making the decision to use that font. The solution, tritely, is they should stop caring about the little details that much.
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.
There seems to be a reply like this at the top of every font-related thread on HN. I often wonder whether it's coming from designer/developers or from end users.
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.
I agree entirely; the clients don't. It's an almost universal question brought up by them during the design phase - "this font looks like everyone else, we want our own". The changes to TypeKit have certainly put a squeeze on their options, but they still almost universally hate the system level fonts. Wish I could convince the business guys to push back, but eh, there are bigger problems we face on a day to day basis.
Couldn’t disagree with this more. Let me share some engineering perspective. Fonts are literally the outlines that allow the vision system to take a 2D shape and convert it to a concept in the limbic system through the semantics of language.
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.
> Use a good fallback list so each platform gets a good option. Specifying custom fonts is largely a waste of bandwidth for a very marginal improvement in aesthetic.
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.
What an absolutely stupid response to this. Of course, just use something that people would already have, 5head. Let me just ask the designer on my team to stop using anything other than Arial and Times New Roman.
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.
you're arguing not to overly optimize and sweat the details, but then prematurely optimizing by recommending against custom fonts.
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.
Don't get stuck optimizing a local maxima, which is very easy to do if you're using AB tests.
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.
For purely aesthetic purposes, this might be a fair point. However, there are many reasons to use custom fonts beyond that. One example is accessibility in a very broad sense. In some circumstances, it reasonable to use a font with more legible type across device types, more support for internationalization (i18n), or better support for uncommon characters (e.g., mathematics).
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.
"Specifying custom fonts is largely a waste of bandwidth for a very marginal improvement in aesthetic...They should stop caring about the little details that much"
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.
I try to block all the web fonts I encounter. A lot of UI symbols aren't rendered which amusingly sometimes results in overlapping text descriptions. I just can't stand looking at certain fonts or ligatures and refuse to let a website decide how it renders text.
> 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.
Strongly disagree. You may not consciously notice font choice, but it will certainly effect the way you read the page, how you interpret the the heirarchy of information and tone.
> It’s widely accepted that self-hosted fonts are the fastest option: same origin means reduced network negotiation, predictable URLs mean we can preload, self-hosted means we can set our own cache-control directives, and full ownership mitigates the risks that come with leaving static assets on third-party origins.
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.
Would it bloat Chrome significantly if Google included their web fonts in the browser? And, you know... the other browsers can actually download them? I know it doesn't seem like fair play, but... I'm surprised they haven't done it yet.
On allaboutberlin.com, I serve Google Fonts locally. Aside from the benefits mentioned in the article, it also makes HTTP2 server push possible. This means the font is pushed along with the page, without first having to parse the HTML and the CSS. It's significantly faster. There are fewer server round trips.
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 also removed yesterday the Google Fonts import and just imported them locally. Performance seemed the same in my case, but I finally managed to completely remove Google 3rd party scripts from my site (no more GA, Google Fonts or Google Tag Manager). The only 3rd party left in my case is the chat widget from Tawk.to, but I will soon replace it with a simple contact form, as I am only using it as one anyway.
It's better to block web fonts with uBlock Origin. It would be sweet if someone could add support for these fonts to Decentraleyes as well, which seems to be missing. Seems to be some debate about the merits of doing so, however: https://github.com/Synzvato/decentraleyes/issues/34
I'm okay with 1st party usage, but I don't want Google following me around the web.
I do like that now Google lets you downloads the fonts, so you can serve from your own CDN without having to hunt them down or download them manually from their CDN endpoint. One thing I'd like to see Google do is add icon font sets to their repo.
The main content may load quickly, at least with javascript disabled, and that's a good thing; but I can hardly read the text though. 300 weight text at 51% grey is awful.
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.
> 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 would be to skip the request for the CSS altogether by inlining it in the head. Therefore you'd just request the font immediately and directly. This makes the preconnect moot, and should be faster.
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.
The media query doesn’t match. Why does the browser even load the stylesheet? Shouldn’t it only load it if it starts to match? Especially for things like print stylesheets, where the media query will only become true by deliberate user action (unlike viewport size media queries where actions like rotating a device could cause them to start matching). Print stylesheets will be used by <0.0001% of users on almost all pages, and could easily be loaded only when the user tries to print the document.
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;"
> 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.
Simple: so that XML parsers can load the HTML, as they are not aware of the HTML context which allows "unclosed" tags.
Off topic, but does anyone have a thought on what is the best unicode font? That is, a font that includes all the characters for the 30+ most use languages (including all the double byte languages)? I know every system had a default unicode font that any character can fall back to (I was surprised when I was working with Turkish and the font didn't 3 of the Turkish characters so it fell back to the system font for those three. That was the first time that I learned that text is rendered character by character and if the indicated font doesn't have that character then it will keep going through the fall backs before reaching the system font and then falling back to some default no font character found symbol), but what is the best non-system font that also covers the vast majority (by percentage of people) of modern languages?
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.
I think the architectural limitation of many font formats to 65,536 glyphs means that there aren’t really any good mainstream fonts that contain the entirety of Unicode, but families like Noto have multiple separate fonts that cover most of it.
I use `font-display: optional` instead of `swap` as it leads to less paint flashing, and if the font is too slow to load, it's not the end of the world if it displays it with the fallback system font.
I noticed this is actually mentioned in the article at the end as a bonus section. In my case `optional` did seem to work better. I didn't encounter the empty page flash he mentined.
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?
Here's a simple idea for the Chromium team:
Bundle the top 100-200 Google web fonts (in .woff2 format) with Chromium (less than 20-30MBs) and boom, you just accelerated the entire internet.
Does anybody else block fonts? Not only is it wasteful for my mobile data plan, but I just have this suspicion that sooner than later they will be used as a vector for some kind of security issue.
I just set browser.display.use_document_fonts to false. This sometimes leads to problems for websites that want to use symbol fonts, but I don't mind that. If I use that website frequently I might write some user script to replace the weird letters with better letters, but that's rare.
slashdev|5 years ago
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.
thaumaturgy|5 years ago
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.
Elidrake24|5 years ago
fermienrico|5 years ago
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.
smnrchrds|5 years ago
Perhaps for English and other Latin-based alphabets. But for some other writing systems, system fonts are simply terrible.
young_unixer|5 years ago
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.
johnghanks|5 years ago
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.
clairity|5 years ago
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.
Silhouette|5 years ago
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.
devadvance|5 years ago
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.
[1] https://en.wikipedia.org/wiki/Private_Use_Areas
open-source-ux|5 years ago
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.
RenRav|5 years ago
csswizardry|5 years ago
> 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?
Angostura|5 years ago
jlg23|5 years ago
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..
[1] https://invisible-island.net/lynx/
seanwilson|5 years ago
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.
cpascal|5 years ago
Ayesh|5 years ago
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.
ezequiel-garzon|5 years ago
slig|5 years ago
csswizardry|5 years ago
nicbou|5 years ago
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.
XCSme|5 years ago
csunbird|5 years ago
brenden2|5 years ago
I'm okay with 1st party usage, but I don't want Google following me around the web.
tyingq|5 years ago
inetknght|5 years ago
Proven|5 years ago
[deleted]
partiallypro|5 years ago
kps|5 years ago
phonon|5 years ago
rkagerer|5 years ago
EDIT: Okay, still a few things they could improve on (https://gtmetrix.com/reports/csswizardry.com/N9gkLyhq)
microcolonel|5 years ago
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).
youngtaff|5 years ago
woodrowbarlow|5 years ago
> 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.
csswizardry|5 years ago
onion2k|5 years ago
Solar19|5 years ago
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.
csswizardry|5 years ago
chrismorgan|5 years ago
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.
Kovah|5 years ago
"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;"
mschuster91|5 years ago
Simple: so that XML parsers can load the HTML, as they are not aware of the HTML context which allows "unclosed" tags.
csswizardry|5 years ago
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?
unknown|5 years ago
[deleted]
irrational|5 years ago
Ayesh|5 years ago
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.
ArgyleSound|5 years ago
davidhyde|5 years ago
Good article though, great research effort.
sa46|5 years ago
1.7 seconds is pretty reasonable for a 7 year-old phone on 3G.
mstaoru|5 years ago
XCSme|5 years ago
XCSme|5 years ago
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?
xsc|5 years ago
fevangelou|5 years ago
Ayesh|5 years ago
It does not work with fonts as far as I'm aware, but it can serve popular libraries locally, saving bandwidth, and protecting privacy.
chance_state|5 years ago
threepio|5 years ago
MintelIE|5 years ago
Groxx|5 years ago
adrianN|5 years ago
inetknght|5 years ago
You mean like being rendered into a canvas to get a high-entropy fingerprint of your device?
oftenwrong|5 years ago
philliphaydon|5 years ago