Getting the f out

28 April, 2019

The Flash of Unstyled Text (or FOUT) feels like one of those “it’s 2019, this is still a thing?” things — it’s been with us for as long as browsers have supported webfonts. Ideas on how to deal with it have moved around over the years, and there still isn’t a 100% consensus, near as I can tell. In trying to figure out how I should work with it as a developer, I’ve read articles and watched videos in several places around the web. I am not an expert! But I figured I would try to pull things together here in one spot in an attempt to wrap my head around the topic. I hope you’ll find it useful as well!

First — what is the FOUT?

Well, when we’re using web fonts on our sites — and many of us do, because we want things to look good — we link to them. We either host the font files ourselves along with our other site assets like images and HTML files, or we let a service like Google Fonts or Adobe Fonts do the hosting, and just make a request to have the files served on demand. If you’ve ever used Google Fonts, like me, you’ve probably just copied and pasted their HTML to link the font, which looks something like this:

<link href=”” rel=”stylesheet”>
Then we declare the font in our CSS like so:
body {
 font-family: “Merriweather”, Georgia, serif;

The CSS font stack goes from left to right, in order of preference. What we’re saying here is, our preferred choice is Merriweather, but if that’s not available, the browser will use our fallback, Georgia, which most users already have on their devices. Failing that, we ask the browser to just use any serif font that’s available. We can chain as many options together here as we like, though more than three (a preference, a fallback and a generic) feels like overkill.

The FOUT happens when our webpage has loaded and is ready to display, but the webfont hasn’t finished loading. First, the browser will wait for a length of time for the webfont to appear: IE and Edge won’t wait at all, Chrome, Firefox and recent versions of Safari wait three seconds, while older versions of Safari and mobile Safari will wait forever. During this period, they just won’t show any text at all — this is often called the Flash of Invisible Text, or FOIT. (Acronyms! Sheesh.)

If the webfont is still not ready after this wait, the browser will just go ahead and render the page using our specified fallback font. Then, once the webfont is ready, the browser adjusts our text to be displayed in our preferred font instead. Most English-language webfont files are small enough that they’re ready soon after the base HTML and CSS, so when this happens, it might only be for a moment — that’s why we call it a flash. (But bear in mind that each webfont is a separate file, each of which has to be loaded, each coming with their own FOIT/FOUT moment. So if your site uses Raleway regular, Raleway italic, and Raleway bold, that’s three webfonts to be loaded, even though they’re all part of the same type family. The more webfonts on your site, the more files have to be loaded, the more likely your users will see one or multiple FOITs, especially if they’re on a slow connection.)

Why should we care?

So if the FOIT and FOUT might only last for a moment, why bother fussing about it? For one, we’re web developers and designers: if you haven’t noticed, fussing over details is kind of our whole entire deal. More seriously — it’s a user experience issue at least. If the FOUT is the first thing our site visitors see, that’s not a great first impression. And it can be an accessibility issue as well, in more dramatic instances.

Two different fonts can have very different characteristics: the width of each character can be wider or narrower, the x-height (the distance from the baseline to the top of a lower-case x) can be taller or shorter, the ascenders and descenders (the tail of a lower-case d or y) can be taller or shorter, the line heights can be greater or lesser. This all means that when our default font changes to our preferred one, our site’s text can actually re-flow dramatically on longer passages of body copy, even if we’re going from one 20px serif to another.

If our site is text-heavy, and the user’s connection is slow enough, they may have already read several sentences of content when the text suddenly shifts around as the fonts change; if they have a cognitive impairment, that could be disorienting, but at the very least it’s quite annoying. (These effects can even result in giving the user the wrong information! See this great post by Zach Leatherman about the perils of the FOIT and The Mitt Romney Web Font Problem.).

So what do we do about it?

There’s a few options! We could, for instance, stop using webfonts altogether and build all our sites with Arial and Georgia like it was 1998. I mean, it’s not great, but it’s an option.

We could also use a combination of CSS and JS to hide all of our text until we’re sure the fonts have loaded. Basically, extending that Flash of Invisible Text period: choosing a longer FOIT instead of getting the FOUT. That’s an often-used strategy, but I come down on the side of not doing that. For one thing, if the webfont doesn’t load at all, your readers don’t see any text at all! You can certainly add a time-out to your script after five or six seconds, but five seconds is an eternity in UX terms — many people simply won’t wait that long for a site to load; users are more likely to stick around if they can see some visible progress happening, and the text is available in at least some form, even if imperfect. Content is king, as they say: quickly readable content is preferable to waiting for a webfont. (And I don’t say this lightly! I come from a print design background where I fussed over typographic minutiae all day long.)

I’m of the opinion that we should get our text in front of the reader as quickly as we can, even if it doesn’t look as polished as we’d prefer. If you’re with me on that, then we’re left with a third option: choosing the FOUT over the FOIT, and trying to minimize the disruption. That’s a two-part process.

First, we have to prevent that default browser behaviour of waiting for webfonts to load, which causes that Flash of Invisible Text. We do this by… declaring our font stack with the fallback first!

body {
 font-family: Georgia, serif;
}body.fonts-loaded {
 font-family: “Merriweather”, Georgia, serif;

By specifying the old-school ‘web-safe’ font first, our page renders with the fallback font immediately, without any FOIT waiting period. It already feels faster to our visitors! We instead assign our preferred webfont to a class. With a little JavaScript, we can load our webfont and once it’s ready to go, we can then apply that class where applicable so our readers see the font we prefer. Font Face Observer is a small JS library by Bram Stein which does just that.

That takes care of the first part: deliberately choosing the FOUT instead of the FOIT. The second part — minimizing the disruption it can cause — will take some typographic choices.

Remember above when we talked about fonts having different characteristics like character width, x-height, and so on? What we want to do now is choose a fallback font that’s similar-ish to our preferred webfont, and then tweak it with CSS so it’s as close as we can get. I say similar-ish, because we’re not looking for a design match here so much as matching the width characteristics; if our preferred webfont is a serif, then choose a serif for the fallback, but beyond that, we’re not looking at style, we’re looking at flow. We want a paragraph of text set in our fallback font to take up the same amount of space as when it’s set in the webfont, so that we can avoid the text reflowing and shifting around when the FOUT happens.

There’s a couple of handy resources we can use here. First, we can hop over to CSS Font Stack — this has a visual list of web-safe fonts, grouped by style (serif, sans-serif, monospace, etc) and what the installed base of each is. Looking there, we can see that our fallback font, Georgia, is installed on 99% of Windows machines and 97% of Macs, so that’s a safe choice. Nice. Next, let’s try to get it to flow the same as our webfont, Merriweather.

For that, we’ll use Font Style Matcher, written by Monica Dinculescu — this is a super-handy tool and a great idea. We can specify our fallback font and our webfont, see them side-by-side and even overlapped on top of each other. Here, we can see that even though our examples, Merriweather and Georgia, are both serif fonts set at 16px, Merriweather is taller and wider, so the line heights don’t match up and it takes up more space. By bumping up Georgia a couple of pixels, tweaking the line-height and letter-spacing, we can get it pretty darn close!

We can then copy that CSS to our site’s styles, and that’s it! We’ve got a much better user experience. The text appears sooner for the user, and when the webfont does load in, if there’s any delay, the disruption is much much smaller. And if the webfont never loads at all, that’s fine too — we’ve styled our fallback text to look as close as we can get, so the page degrades gracefully and all our visitors get the best experience we can give them.

This seems like a lot of work

Well, it’s some extra work, certainly, though I think it takes longer to explain than to do. But this is the gig, right? We’re developers and designers. We fuss over the details — we fuss over animation timing and having the border radius of things be just so and getting everything to line up nicely, so why not this too? Text is the bedrock of the web. The vast majority of content online is text, and heck, all the sites we build are literally made out of text files. It’s all words, and words matter. So it’s on us to make sure those words are as attractive, readable and functional as we can.

Resources and sources

I’m very much indebted to the smart people who wrote the tools, articles and posts below — be sure to read them for much more detail than I’ve provided here.

Font Style Matcher:

CSS Font Stack:

Font Face Observer:

“Type is Your Right”, by Helen V. Holmes:

“A Comprehensive Guide to Font Loading Strategies”, by Zach Leatherman:

“Front End Center: Crafting Webfont Fallbacks”, by Glen Maddern: