In the previous two blog posts in this series, Sasa wrote about the Frontend Web Development Quiz that we took as a team and about what we learned from it. This time we had a few but specific topics instead and I would like to pick out one and explain it a little further.
Font-display has been around for quite some time now so you might wonder why I write about it only now? The reason to look at it closer now is that support has improved recently and we should really start using it.
Font-display is a descriptor of the font-face property. Font-face specifies a custom font for our website and font-display as part of it specifies how those font files get loaded and displayed by browsers. Therefore it needs to be placed inside the font-face property, for example like this:
Syntax and specification
Swap is just one of the five values that the descriptor can have. Let’s have a look at all of them.
Auto is the default and initial value and if nothing gets set, the font display strategy is defined by the browser - meaning the browser decides what to do. In most of the cases, this means no text is shown at all until the font file is loaded. This is not the nicest behaviour, so let’s check out the other options we have.
Block gives the font a longer blocking period and an infinite swap period. This might be useful if your chosen web font is very important. Setting block will tell the browser that it should wait for a longer time (around 3 seconds for most browsers) to download your font. In this timeframe, no text will be displayed and if the font did not get loaded after that time the fallback is used. And then the infinite swap period takes place - meaning no matter how long the custom font additionally takes to be downloaded, the browser will swap it in any case with the fallback font once it’s fully loaded.
Swap gives the font only a very short block period and an infinite swap period. Similar to the behaviour of block just with a lot shorter blocking period. It even seems as if the fallback font gets displayed immediately and as soon as your custom font is fully loaded it gets swapped out. This can be annoying for users when they’re already reading your page and are halfway through a paragraph and suddenly get an ugly flash of unstyled and styled text.
Fallback gives the font an extremely short block period followed by a short swap period. Extremely short block period meaning the browser has a timespan of ~100ms to load the font-face. If it’s not available it draws a text in the fallback font and swaps it with the custom font later on. But also in the swapping period, the browser is pretty strict and only waits a limited time ~3s for the desired font to load. If it hasn’t loaded in that time, the browser will stick to the fallback font. In terms of UX it’s nice as the amount of flashing text gets reduced but visually speaking it’s a pity that even if your beautiful custom font would be downloaded at a later stage, the browser still sticks to the fallback.
The last value is optional and it gives the font an extremely short block period and no swap period. Here the browser has ~100ms to check if the custom font got downloaded or is already available. If not it uses the fallback font for the rest of the pages lifetime. The font can still be downloaded in the background and used for future page loads.
So which of the above should I use now? If showing your custom font is of high importance, then block or swap might be the right choice for you. One use case I see here are icon-fonts for instance. There’s no real fallback to your icon but I’d also suggest not to go with icon-fonts in the first place and use inline svgs instead =) If the site performance is sort of a big deal and custom fonts aren’t the most important thing then font-display: fallback gives you a nice user experience. To help you find out which value might work best for you, test your page with a throttled network connection and see how it feels with the different options.
Other blogs in this series