How much of an impact does font loading have on loading times? What is the best web performance strategy to adopt when it comes to optimising font loading? Anthony, one of our web performance experts, lifts the lid on some or our in-house analysis and gives the low-down on FOUT, preloading and inlining.
NB: "fonts" here refer specifically to web fonts.
This presentation is based on both our own in-house research at Fasterize and on the work of web performance gurus Bram Stein and Zach Leatherman.
According to HTTP Archive statistics, web sites include 3 fonts on average (figure from April 2017). These fonts are around 100K in size.
We have also analysed a number of French e-commerce web sites ourselves and found that a larger number of fonts are loaded in some cases (5 or 6 per web site), but that these are smaller in size (around 50K).
How are fonts loaded?
Fonts are loaded after the HTTML and CSS sources.
When loading fonts, browsers may adopt one of two different behaviours.
- FOUT: Flash of Unstyled Text, whereby text is displayed in an unstyled font, and then finally rendered in the correct font.
- FOIT: Flash of Invisible Text, whereby the text is not displayed at all until the font is loaded. The text therefore remains hidden.
To offer the best possible user experience, we will avoid hidden text as much as possible. From this perspective, browsers have recently added timeouts when downloading fonts.
Thus, if a given font has not loaded within a given timeout period, a "fallback" font will be used instead to display the text.
What font loading strategy is it best to adopt?
1. "System fonts"
Over the past two years, we have seen major content platforms (such as Medium, WordPress and Github) start to use "system fonts", which are available for use on most operating systems.
This is a worthwhile strategy when styling is not of primary concern (e.g. when rendering dashboards).
2. Reduce file sizes
We recommend using WOFF2 to reduce your file sizes. WOFF2 is supported by a large number of browsers and can be used alongside a fallback option.
3. Use the CSS "Font-Display" property
This new CSS property allows you to determine how the browser should behave while fonts are loading:
- block: text will be hidden (equivalent to FOIT)
- swap: switches from the fallback font to the correct font
- fallback: equivalent to "swap" but with an additional timeout
- optional: allows the fallback font to remain in place during initial loading. The real font will be displayed once it has been cached.
While this optimisation is easy to implement and is low-maintenance, at present it is only supported by Chrome 60.
4. Font preloading
It is possible to use
link rel="preload" to pre-load fonts. This then means that fonts are loaded before the CSS is executed.
However, as with the previous strategy, preloading is not implemented by many browsers (only Chrome and Opera).
5. FOUT with class
The idea is to detect when a font is loaded and only apply it to your CSS once it has successfully loaded. Generally speaking, this means adding a class around the HTML element within the document.
Hidden text is therefore avoided. However, this optimisation is higher maintenance and difficult to automate.
6. Font inlining / preloading
This optimisation is slightly more advanced than those mentioned previously. The idea here is to display the text in the right font straight away, avoiding either hidden text or the use of a fallback font.
To achieve this, we generate a font containing basic characters only (letters A-Z, digits and punctuation). The file size is therefore smaller and can be inlined into your CSS file, which is loaded right at the start.
Other variants (italics, bold, etc) will then be loaded at a later stage.
This is the best strategy in terms of performance, but requires significant maintenance.
For more information on the pros and cons of each of these font optimisation strategies, slides are available just here >>