How to Load Fonts in a Way That Fights FOUT and Makes Lighthouse Happy | Hacker News Reader

How to Load Fonts in a Way That Fights FOUT and Makes Lighthouse Happy

css-tricks.com

48 pointsblindm25 comments

This is probably a hot take, but I think custom fonts are self-serving for the web developer and for 99% of cases, not a benefit to the user. Most people who use Google Fonts hotlink to Google which means you're sending information about your users' IP and fingerprint, URL visited, and timestamp they went to your page to them. Even when done right, users just don't care or notice them, and would probably rather have a faster pageload, less bandwidth use, and no flicker (FOUT, as noted by the article).

I'm a fan of the native font stack approach [1] that Bootstrap now uses, and is used by Wordpress and Medium. The idea is to have a long font stack that opts for the operating system font (like Segue UI for Windows, San Francisco for Mac, Roboto for Android, etc.), which is modernly beautiful, loads instantly, and fits with the users' native application.

[1] https://css-tricks.com/snippets/css/system-font-stack/

Fonts do play a role with branding that isn't just for the designers. regular consumers also notice and feel the differences in different typefaces, although they might not be able to express that in words. I personally don't like Google and I have used the system default font stack, but it only fits some use cases.

On a personal site I added a custom font that weighs a whopping 11kb to give it a very different feel.

The native font stack is absolutely fantastic, at least it is in 2020. I used to think that a custom font is a must to have a "professional" website and to escape the bore of Time New Roman.

When I first used the native font stack for a new website I set up [1], I was surprised that it looks very nice on all devices! Without any additional network requests or CSS hacks to load the fonts.

1: https://devutils.app

I think for most language, the native font stack is fine. However, for some language (e.g. Thai), the native font stack is very hideous especially at large font size.

This is really thorough and nuanced work, and so many websites could benefit from this.

But oh my god, it’s so complex! I wish the platform (http/HTML/css) could support this natively without any need for javascript or tricks of any sort. Some of it looks like irreducible complexity: particularly “choosing a fallback font that closely matches the size and style of the eventual font”. The platform can’t do that for you. But surely a “sufficiently advanced” HTML/css will be just a little wiser and let you say, with one well placed keyword, “this is the font I want to use, but don’t wait for it, use it once it’s available and use this one in the meantime.”

(And I’m thinking that inlining the fonts as base64 encoded stuff might be more optimum and prevent stuff moving around. It’s such a tiny point, I don’t think engineers everywhere in the world should all have to spend effort on this.)

That's exactly what I was thinking while reading this. Whenever I see things like "apply the font style to a nbsp, to ensure the DOM loads it" I always wonder why web developers so often have to "trick" the browser. Why can't we flesh out the common use cases and come up with something clean that web developers and browser vendors can agree on?

As for using a fallback font that closely matches to minimize the impact of the switch over, how realistic is that? In the demo I felt the fallback font looked very different from the final font (in weight, style and size) and I'm wondering if it's because I'm on Android and the author chose fallbacks that only match on their OS?

As for using a fallback font that closely matches to minimize the impact of the switch over, how realistic is that?

It would a lot more realistic if browsers other than Firefox supported font-size-adjust, which allows the fallback font to mimic the metrics of your primary font.

Here's an article from 2010 that describes how it works: https://webdesignernotebook.com/css/the-little-known-font-si...

Or you could just load the font from your own site and avoid a pass through Google.

Here's a site of mine which loads some fonts.[1] See any loading delays?

It's junk-free. No trackers, no ads, no "Google Tag Manager".

[1] http://aetherltd.com/

Looks like it suffers from “Ensure text remains visible during webfont load“

By "loading delays" do you mean FOUT? I did see FOUT when I visited.

What you're seeing on http://aetherltd.com/ is FOIT (Flash of Invisible Text), not FOUT (Flash of Unstyled Text). The latter is specifically about text that has a different font than it should, up until the point of the proper font being available and downloaded. The former is that the text is not even visible until the font is available.

Ah yes, you're correct. Thanks.

This is mentioned in the article as well.

> It’s important to note that self-hosting the fonts might also help fix render-blocking issues

As long as your site is fast, you're good. Otherwise you might try and hope that the user has seen that font somewhere before on the internet and cached it.

Interestingly, your fonts loaded quickly, but I got wildly varying results when looking at your site - for example it took me six seconds to download your 8kb background jpg on one load.

Typophiles like Google's CDN because it can have way more nuanced conditions about what exact font to load

But you don't have to use it, and yes for some reason that seems to be a lost art.

Can you explain a bit more about what you mean by “way more nuanced conditions about what exact font to load”? I’ve tried both approaches recently and found using Google to be quicker and less work, but didn’t find it more nuanced or specific. What have I missed?

Google Webfonts looks at the useragent (and maybe more?) of the requester and serves different stylesheets depending on that, changing if to load WOFF or TTF fonts for example.

If you need to support browser that doesn't support woff2, Google Font do that for you automatically.

Furthermore, Google Font subsets their fonts so that if you only use English, the other parts of the font that contain Greek, etc. won't load (via unicode-range CSS)

I have disabled web fonts on desktop (Firefox settings) and mobile (Firefox Focus as content filter for Safari).

It looked strange for about thirty minutes. After that: I'm not going back.

Everything is faster, everything looks sane. The few sites where custom fonts are an integral part of the value? I'm willing to re-activate fonts for those. Happens almost never.

Only "problem" is that icon fonts are blocked (hamburger menus, thumbs up buttons), but I can live with that (and if it's too difficult to use, I may also re-activate fonts temporarily).

Lately I've just gone with inlining the font stylesheet into the page to avoid render blocking on the CSS; enable font-display: swap; so that text remains visible while the font itself is loading; and like the article suggests, choose a reasonable font fallback. No need for the preloading since the font request should get kicked off immediately. Can't use Google Fonts this way though since the font urls are unstable.

The system font stack is probably the best though.

FOUT still happens and it shifts the content. I thought this was going to offer some custom loading logic like “don’t switch the font unless it’s cached or the user isn’t looking.”

I was just dealing with this insanity a few weeks ago. I eventually settled on using a pre-load of my font in the head element and then immediately afterwards a built-in script element that loaded it into the font family.

And even after this it seemed really inconsistent whether it would wait to display the correct font or load the fallback font then visually hot swap in the correct one depending on the browser and the device used.

Dumb question time. Why isn't something like this just baked into the browser itself? Devs shouldn't have to jump through hoops and rely on convoluted hacks just do to something as simple as load a font.

[deleted]

> Imagine having to download a shitty webfont with megabytes before being able to read the website

This is exactly what the article is arguing against, that the content is the most important and it should show immediately, no matter if the font is yet available or not.

> Why not use font-display: swap instead?

That's again exactly what the article is advising people to do. Another action that the article suggests, boils down to "choose a default font that is similar to your custom one, to minimize the effect of FOUT", how does that decrease the value for the users?

I'm not sure if you either read the article then decided to write your comment pretending you didn't, or if you're just rehashing what the article just said for some other purpose.

Reply on news.ycombinator.com