I haven't made up my mind about whether web fonts are a good or bad thing. On one had I understand the designer's desire to express themselves artistically (or even sometimes implement functionality that wouldn't be available otherwise), on the other hand I often feel more comfortable with my own font choices and am glad that Firefox lets me override most fonts with defaults.
I think web fonts are massively overused. Sticking with the user's configured selections are better unless there are very strong reasons you need to over-ride them.
It's extra resources, time, and complexity spent on forcing something on the visitor that in most situations they don't want or care about.
I agree. (The document may specify what language the text is in and whether or not fix-pitch is wanted; the user settings should then be used to determine what font that is.) Actually, I generally would usually avoid CSS entirely, since the user's styles are generally more suitable.
(The "font-display" setting is also a setting that the user might want to change even if font downloading is enabled. My idea of "meta-CSS" would give you this and many other things for free. Meta-CSS would not inherently allow the timing to be adjusted, but it is a feature that can be added too if it is wanted.)
Another thing that I might want is to enable the document to specify its own fonts if it is SVG or PDF, but to disallow HTML documents from specifying their own fonts.
> Actually, I generally would usually avoid CSS entirely, since the user's styles are generally more suitable.
I very much doubt that's true for the average user, who will simply be using the browser's built-in default – which to an not inconsiderable extent is rather constrained by backwards compatibility concerns rather than being truly optimised for usage as "the only stylesheet you'll ever need".
Besides, even with a boring plain old homepage-and-definitively-not-a-web-app it's not too difficult to run into the limitations of what you can achieve without some custom styling even purely in terms of basic layouting and typography.
I always find builtin fonts difficult to pair when you want to use monospace for code. If you take Times New Roman and Courier New for example, Courier New is quite larger visually, so you would need to use a smaller point size for it. But how to do that when you need to handle fallbacks? On my blog, I am pairing Merriweather with a custom version of Iosevka to match x-height and ascendant height. I think this is less disturbing when reading.
For me, this is a bug of the OS or the browser. On my OS, Noto Sans is the default sans-serif font and Noto Mono the default monospace font and they pair impeccably. Whatever font you are telling my browser to use will probably be worse for me (at least because of the loading time, and because it is actually hard to match the readability of Noto in my opinion).
It's unfortunate Courier New is both so badly different from the regular fonts (and so bad at all, by the way) and also the default on Windows.
Courier New, with all its unfortunate quirks, is there for a reason, AFAICT. It copies the typewriter font metrics. There are many situations where texts are measured by the number of "standard typewriter" characters and lines, established like 100 years ago.
Using Courier New for code samples is not a great idea. I think it comes from the times when good monospace fonts did not yet exist. I always change this default, andvi wish browsers somehow stopped clinging to it.
I think this argument falls apart here: “the user's *configured* selections”. 99%+ of users don’t configure anything and just have the browser’s defaults. This isn’t because they love the defaults, it’s because they don’t know/care that you can configure things.
* I know there’s a config, but I don’t know enough about fonts to make a good choice
* Most sites override my config anyways (unless I chose an even more aggressive config that breaks websites), so why would I care?
* The idea of some site specifying a font does not bother me, even if it’s a web font that will cause an extra 25kb of download.
For what it’s worth, I really like fonts and know my way around the Firefox config, but I honestly do not care enough to change the default font because of the last two items on that list.
Long story short : designers don’t always build sites. With easy CMS solutions, content managers instead of designers, you get questionable font choices. It’s not as bad as the early days of Comic Sans, but there’s still a lot of work for typography experts out there.
Stackoverflow is switching to use system font https://news.ycombinator.com/item?id=27063991 Other big site such as Github is using system font as well. It appears there is a trend to abandon web fonts.
Two don't make a trend when we're talking about billions of web sites. Typography it too important to abandon it in favor of whatever defaults Microsoft or Apple have enabled on their platforms.
GitHub and Stackoverflow are interesting cases from a webfont perspective. They have the benefit that most of their users are repeat visitors that means they'll likely have the designers prefered fonts cached from a previous visit. They also both need to support EVERYTHING. Could you imagine the HN posts if they didn't? "Github doesn't support U+25C8! This crashed my Rust server, invalidated my identity, and made my grandparents cry!"
In that StackExchange post you linked to, they mentioned make their own branded web font. That's definitely what I would be advocating for if I were there. The case for Github making their own font is even stronger. Microsoft has a very good font team. Designing a family of brand fonts for GitHub would be a very cool project (How many brands care about their fixed width font as much as github?)
Personally, as a user, I'm not going to a website to appreciate the owner's artistic sensibilities. IMHO, system fonts are perfectly readable; the trade-offs involved in a site owner imposing custom web fonts don't seem to take into account my priorities as a user.
A site using web fonts doesn't force the web client to use them. The user agent should be perfectly capable of replacing the site's font choices with its own and not even downloading the web fonts if it's known ahead of time that the user doesn't want them.
The alternative isn't what you think it is.
You might hope if web fonts were banished, designers would use system fonts. But there was a time before web fonts, what that's not what they did. They'd do their typesetting in photoshop/Illustrator and then upload images. That's the world we'd be going back to.
You, personally, should be glad web fonts are a thing because it makes it easy for you to restyle them on your computer. If a world without web fonts that wouldn't be possible.
It's missing one of the biggest improvements: HTTP2 Push. It saves a lot of back and forth.
You can also limit how many variants you use. On my website, I dont have bold + italic text, to avoid loading a font. My secondary font is only loaded in one variant.
I also realised small performance gains by inlining my CSS (although HTTP2 Push negates the benefits). This only makes sense for smaller stylesheets though.
Even then, fonts are one of the last performance bottlenecks on my tiny and fast website. That's only visible on absurdly slow connections.
> It's missing one of the biggest improvements: HTTP2 Push. It saves a lot of back and forth.
Worth noting that Push has been removed from Chrome, which likely means it’ll eventually go away everywhere else it’s implemented.
> You can also limit how many variants you use. On my website, I dont have bold + italic text, to avoid loading a font. My secondary font is only loaded in one variant.
This is definitely good advice. On my site, I only load one font, used only for headings. Body text certainly can benefit from custom fonts too. But IMO if your headings stand out and the rest of your design is strong with good line spacing, it doesn’t hurt to try out common web fonts or a system font stack for the body text.
> I also realised small performance gains by inlining my CSS (although HTTP2 Push negates the benefits). This only makes sense for smaller stylesheets though.
This seems to generally be the trend, but when I built my site I decided to go the opposite direction and extract all of my styles into a single external CSS file for caching benefits. This turned out to have a negative impact on perceived load time—particularly blocking fonts, but also just some TTFP generally—so I manually inlined what felt like the most critical styles, which helped a lot. First load feels pretty much the same as inline on my connection, which isn’t especially fast, and subsequent loads get it cached.
I could probably improve it further with some page-specific splitting/inlining, but haven’t felt the need to prioritize that yet.
> I could probably improve it further with some page-specific splitting/inlining
My website(s) are very simple, so the CSS files are small. Even the larger pages are around 50 kilobytes plus images. That's why inlining is a no-brainer in my case.
My current site is quite young, just 3 blog posts and a resume so far. The base shared styles are definitely small, but the resume and one of the blog posts add quite a bit more weight there. Both will probably share more with other pages as I add content, which is another reason I’m not ready to figure out how I want to split up the styles.
And I’m probably going to port it to another SSG framework[1] when I get the time and energy, and I’ll probably change a fair bit of tooling in the process.
It never worked. But served its purpose well to sell HTTP2 which made it easier to sell HTTP3. People seem to always forget Google is an advertising company.
Agreed: disabling 3rd party fonts just makes pages look more native (by using fonts I've whitelisted) and load faster. The only regression is that some pages use icon fonts instead of SVGs. An often-cited justification is the small size of WOFF2 fonts, but the same can be achieved by using static Brotli compression on all assets.
Yeah, no. Until the standards give us more fonts with better metrics (like a guarantee that a default sans, serif and fixed-width fonts come from the same family), the default fonts will look quite crummy.
I wish there was some font cache that could be shared between all sites, so once you downloaded a font it would be available for all. But I guess due to copyright it will never happen.
Fonts are 20 kb each. Even on the slowest of mobile connections, they hardly make a difference. If you're waiting 30 seconds, fonts are not the bottleneck.
If you have a few fonts, referenced by an external css file, on a page that has a bunch of images, the delay is a couple of seconds on a mobile connection. It's not just the download time for 20kb, it's the servers response time (you _are_ hosting it yourself right?) × number of resources requested.
I'd rather just view the page with the default fonts rather than wait 5-6 secondsfor the minimally different sans serif font that you've chosen for one paragraph that blocks the entire page render.
You might be able to load the fonts quickly on their own but if they're requested by something else that's dynamically loaded the (serialized) round trips can add up fast, especially on high latency connections like satellite.
"But think of the satellite connections" isn't really a meaningful consideration in a world where we don't support IE and most websites are megabytes in side. Mine is fast enough for people stuck in the underground, which is a far more significant demographic for me.
Hypotheticals aside, the fonts load sufficiently fast in a single round trip (two if HTTP2 push isn't supported), and do not block rendering.
First, my default fonts look great because I chose them and my preferences are superior to everyone else's.
Second, I use Debian and I have a fonts.conf that's hundreds of lines long, including dozens of lines of hinting settings because I prefer that some fonts use hintfull and others use hintslight. I don't have hinting settings for every font that exists, only fonts I installed, so when a site uses a web font, there is no dedicated hinting setting for it in my fonts.conf, and so it almost always looks worse than my default font.
I typically embed the font into the CSS using base64 data URIs. Even typically large CSS files compress with gzip extremely well and if you have one style sheet to load your page will load the fonts and styles in one go very quickly.
I don’t know why more websites don’t do this. Even having one large CSS file with everything compressed is much much faster then the waterfall of more files/connections.
I recommend postcss-import that takes your file paths and embeds the files during build. Use responsibly.
> I don’t know why more websites don’t do this. Even having one large CSS file with everything compressed is much much faster then the waterfall of more files/connections.
I could make a similar argument to say not to use CSS files, just embed everything into the page.
Unless you have a ton of files, listing them all in the html will make them load just about as fast as a single file listed in the html.
I actually think there are cases for this. Say, you have a small amount of CSS and/or the user will in all probability just look at the one page on the site.
Webdevs usually forget that neither practically unlimited bandwidth nor quotas should be take for granted. A lot of people have slow internet connections, don't make 'em suffer.
More often than not, base64 encoding has a negative net-impact.
- base64 encoded strings are larger than the real file size.
- It blocks browser rendering. Browsers can still render a page while it's downloading the fonts. Not while it is downloading CSS.
- Makes cache busting hard. You will update CSS files more often than fonts. Fonts, served with right headers, can stay longer in browser cache.
- Base64 encoded strings don't compress well. I go as far as sorting the attributes/combined classes to increase the compressibility of the CSS, but base64 strings hardly compress.
You won't see FOIT/FOUT because the browser is outright blocking the rendering until the CSS is completely downloaded. That is arguably a worse outcome.
These are valid points, but in non-perf benchmark terms, what is the benefit to rendering before fonts load? I have never appreciated getting to read for a couple of seconds before the screen repaints and I lose where I was and just start over.
If your font I'd big enough that it's causing a "couple of seconds" then you should just use the system fallback font rather than leaving me staring at a blank screen
Web fonts with limited glyph sets are like 30kB before base64, it's certainly worth it to block for a few milliseconds more to prevent FOUC/FOIT altogether.
Simply because it's not very performant. base64 will make the file about 30% larger, and web fonts are already too big. It'll also block the rest of the CSS file which can delay layout calculations, and the font-display property won't work either.
I agree that one CSS file is often faster, but the thing you say about waterfall isn't true if you are using HTTP/2. You are better of serving multiple files for the fonts.
Seems less efficient and harder to maintain than preloading the optimally precompressed font file before the CSS statement as per step 3 of this guide. Not to mention this method preserves the flexibility offered in step 2 of the guide.
Brotli. Brotli. Brotli. Chomp 25 percent off the CSS. Use static compression so there is no gzip going on before the file is served. Combined with embedded fonts in the CSS, stripped to the glyphs could be the speediest. Woff2 has its own compression, would be good to have that uncompressed in the font and compressed in the Brotli.
Out of curiosity, how did your LCP in Chrome timeline [1] look like before/after inlining? If LCP is lower with inlining, then the approach works beyond doubt!
1: LCP – Largest Contentful Paint – a core web vital metric representing time for the visible viewport to be stable. This is better than the old "document ready" because document ready is technical, hundred other things like reflows can happen after document ready. Whereas LCP represents from a user perspective when the viewport is ready. When fonts create reflows, the viewport becomes unstable and LCP will be higher. Lower LCP = Better user-perceived loading time. https://web.dev/lcp/
One thing I’d really like to build, if I ever have the time/energy, is a static analysis tool that automatically determines an optimal subset based on actual usage. Subsetting arbitrarily based on say charset definitely helps, but it can go even further if you only use even a subset of that charset.
I think that using a Google Font means that Google sets a third-party cookie for each visitor. If you need to conform to the GDPR, this probably means that you need to request visitor permission before you load the font.
I totally agree with you, but if you ever did freelancing as a web developer, you'll see many clients cling to their corporate identity principles (including font selection) way stronger than you may think.
There is a dilemma when optimizing web sites and apps: Do you want stuff to show up on the screen before or after the font is loaded? So by not trying to optimize the font load, your site will render/load faster (because the browser starts rendering the site without the font, then replaces the "dummy" text with the actual font), and usually the web font has loaded just in time to show the correct font when the user starts reading.
84 comments
[ 4.4 ms ] story [ 152 ms ] threadIt's extra resources, time, and complexity spent on forcing something on the visitor that in most situations they don't want or care about.
(The "font-display" setting is also a setting that the user might want to change even if font downloading is enabled. My idea of "meta-CSS" would give you this and many other things for free. Meta-CSS would not inherently allow the timing to be adjusted, but it is a feature that can be added too if it is wanted.)
Another thing that I might want is to enable the document to specify its own fonts if it is SVG or PDF, but to disallow HTML documents from specifying their own fonts.
I very much doubt that's true for the average user, who will simply be using the browser's built-in default – which to an not inconsiderable extent is rather constrained by backwards compatibility concerns rather than being truly optimised for usage as "the only stylesheet you'll ever need".
Besides, even with a boring plain old homepage-and-definitively-not-a-web-app it's not too difficult to run into the limitations of what you can achieve without some custom styling even purely in terms of basic layouting and typography.
It's unfortunate Courier New is both so badly different from the regular fonts (and so bad at all, by the way) and also the default on Windows.
Using Courier New for code samples is not a great idea. I think it comes from the times when good monospace fonts did not yet exist. I always change this default, andvi wish browsers somehow stopped clinging to it.
Why not just let system designers choose the fonts their users are subjected to by default.
At least they seem to care more about accessibility than XYZ.coms marketing department.
* I don’t know there’s a config at all
* I know there’s a config, but I don’t know enough about fonts to make a good choice
* Most sites override my config anyways (unless I chose an even more aggressive config that breaks websites), so why would I care?
* The idea of some site specifying a font does not bother me, even if it’s a web font that will cause an extra 25kb of download.
For what it’s worth, I really like fonts and know my way around the Firefox config, but I honestly do not care enough to change the default font because of the last two items on that list.
* I know there's a config, but this is my work machine and corporate IT has blocked the browser prefs dialog via group policy
In that StackExchange post you linked to, they mentioned make their own branded web font. That's definitely what I would be advocating for if I were there. The case for Github making their own font is even stronger. Microsoft has a very good font team. Designing a family of brand fonts for GitHub would be a very cool project (How many brands care about their fixed width font as much as github?)
You, personally, should be glad web fonts are a thing because it makes it easy for you to restyle them on your computer. If a world without web fonts that wouldn't be possible.
> This is a good base because it lets website visitors start reading your content right away
They're already reading the content. The one job your website had has already been accomplished without the custom font.
As this guy[1] said, you first serve what's essential for your website's functionality, and then you stop.
[1] https://www.youtube.com/watch?v=iYpl0QVCr6U
You can also limit how many variants you use. On my website, I dont have bold + italic text, to avoid loading a font. My secondary font is only loaded in one variant.
I also realised small performance gains by inlining my CSS (although HTTP2 Push negates the benefits). This only makes sense for smaller stylesheets though.
Even then, fonts are one of the last performance bottlenecks on my tiny and fast website. That's only visible on absurdly slow connections.
Worth noting that Push has been removed from Chrome, which likely means it’ll eventually go away everywhere else it’s implemented.
> You can also limit how many variants you use. On my website, I dont have bold + italic text, to avoid loading a font. My secondary font is only loaded in one variant.
This is definitely good advice. On my site, I only load one font, used only for headings. Body text certainly can benefit from custom fonts too. But IMO if your headings stand out and the rest of your design is strong with good line spacing, it doesn’t hurt to try out common web fonts or a system font stack for the body text.
> I also realised small performance gains by inlining my CSS (although HTTP2 Push negates the benefits). This only makes sense for smaller stylesheets though.
This seems to generally be the trend, but when I built my site I decided to go the opposite direction and extract all of my styles into a single external CSS file for caching benefits. This turned out to have a negative impact on perceived load time—particularly blocking fonts, but also just some TTFP generally—so I manually inlined what felt like the most critical styles, which helped a lot. First load feels pretty much the same as inline on my connection, which isn’t especially fast, and subsequent loads get it cached.
I could probably improve it further with some page-specific splitting/inlining, but haven’t felt the need to prioritize that yet.
> I could probably improve it further with some page-specific splitting/inlining
My website(s) are very simple, so the CSS files are small. Even the larger pages are around 50 kilobytes plus images. That's why inlining is a no-brainer in my case.
[1] https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYL...
And I’m probably going to port it to another SSG framework[1] when I get the time and energy, and I’ll probably change a fair bit of tooling in the process.
1: https://astro.build/
there is no step two
I wish there was some font cache that could be shared between all sites, so once you downloaded a font it would be available for all. But I guess due to copyright it will never happen.
I'd rather just view the page with the default fonts rather than wait 5-6 secondsfor the minimally different sans serif font that you've chosen for one paragraph that blocks the entire page render.
Hypotheticals aside, the fonts load sufficiently fast in a single round trip (two if HTTP2 push isn't supported), and do not block rendering.
Second, I use Debian and I have a fonts.conf that's hundreds of lines long, including dozens of lines of hinting settings because I prefer that some fonts use hintfull and others use hintslight. I don't have hinting settings for every font that exists, only fonts I installed, so when a site uses a web font, there is no dedicated hinting setting for it in my fonts.conf, and so it almost always looks worse than my default font.
I don’t know why more websites don’t do this. Even having one large CSS file with everything compressed is much much faster then the waterfall of more files/connections.
I recommend postcss-import that takes your file paths and embeds the files during build. Use responsibly.
I could make a similar argument to say not to use CSS files, just embed everything into the page.
Unless you have a ton of files, listing them all in the html will make them load just about as fast as a single file listed in the html.
Then the poor user has to download heavier html on every page as the browse the site.
- base64 encoded strings are larger than the real file size.
- It blocks browser rendering. Browsers can still render a page while it's downloading the fonts. Not while it is downloading CSS.
- Makes cache busting hard. You will update CSS files more often than fonts. Fonts, served with right headers, can stay longer in browser cache.
- Base64 encoded strings don't compress well. I go as far as sorting the attributes/combined classes to increase the compressibility of the CSS, but base64 strings hardly compress.
You won't see FOIT/FOUT because the browser is outright blocking the rendering until the CSS is completely downloaded. That is arguably a worse outcome.
Simply because it's not very performant. base64 will make the file about 30% larger, and web fonts are already too big. It'll also block the rest of the CSS file which can delay layout calculations, and the font-display property won't work either.
1: LCP – Largest Contentful Paint – a core web vital metric representing time for the visible viewport to be stable. This is better than the old "document ready" because document ready is technical, hundred other things like reflows can happen after document ready. Whereas LCP represents from a user perspective when the viewport is ready. When fonts create reflows, the viewport becomes unstable and LCP will be higher. Lower LCP = Better user-perceived loading time. https://web.dev/lcp/
I’ve been using it for a few months on my personal statically generated site and it works surprisingly well.
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Fonts/V...
And frankly, it does make a difference.
Too bad those very expensive fonts never come with a decent web license and you end up going for a half-arsed substitute.
The problem aren’t necessarily fonts, but print-first design systems that don’t translate well to screens and interactivity.
The font of a website does not rate highly on my interest rating.