Optimizing Web Fonts for Performance: the State of the Art

This article is part of a series created in partnership with SiteGround. Thank you for supporting the partners who make SitePoint possible.

67% of webpages now use custom fonts. However, popularity and widespread adoption didn't come without some performance and user experience-related issues.

In this article, I'll go through what's not so good about the way web fonts are commonly used and loaded, as well as point you to well-tested workarounds and future standards-based solutions.

Why Custom Web Fonts?

Users come to your website for content. Therefore, great typography is crucial on the web: readability, legibility and well-crafted typographic design are a must for brand recognition and the success of your message.

The best way to achieve beautiful typography is by loading custom web fonts — that is, font files that are not already installed on users' devices.

Since browser support of the CSS @font-face rule has become widespread, using custom web fonts in websites has increased by leaps and bounds. However, fonts can have a heavy file size and loading extra resources on your website doesn't come without some negative impact on performance.

Since file size can certainly be an issue, paying attention to how custom web fonts are loaded comes to the forefront.

What Is the Flash of Invisible Text (FOIT) All About?

The most common way of using a custom web font is to specify the fonts used inside a CSS @font-face declaration and leave the browser to its default behavior. This is not ideal. Since information about fonts is located in the CSS, by default browsers delay the loading of fonts until the CSS is parsed. That's not all. As Zach Leatherman has made abundantly clear, to trigger a font download, a number of conditions must be met besides a valid @font-face declaration:

• A HTML node that uses the same font-family specified inside @font-face
• In Webkit and Blink browsers, that node must not be empty
• In browsers that support the unicode range descriptor inside @font-face, the content must also match the specified unicode range

If all the points above are satisfied, the browser starts downloading the font. This means that the browser needs to have parsed not only the CSS code but also a website's text content before it can trigger a font's download. However, it's just when the font starts loading that web users are likely to experience the dreaded Flash Of Invisible Text, or FOIT for short.

[caption id="attachment_152717" align="aligncenter" width="700"] FOIT: Page at http://ift.tt/y1O1NW while fonts are loading on Firefox v.52. Text is invisible.[/caption]

[caption id="attachment_152718" align="aligncenter" width="700"] FOIT: Page at http://ift.tt/y1O1NW after fonts have been loaded on Firefox v.52. Text has become visible.[/caption]

In other words, as soon as browsers start downloading a font, all text becomes invisible. So users look at a screen with no text for some time, which under sub-par network conditions can feel like forever. Furthermore, the way different browsers handle FOIT also varies:

• Blink and Firefox browsers tackle FOIT by introducing a 3 second-timeout: the text disappears for three seconds during font loading. If the font hasn't loaded within this time frame, the website displays a fallback font, which is subsequently replaced with the custom font once this is fully loaded. This behavior gives rise to what is known as FOUT (another acronym): Flash Of Unstyled Text.
• Safari, the default Android Browser and Blackberry don't use a timeout but display no text until the custom font is loaded. If anything goes wrong and the font doesn't get loaded, users are left with invisible text on the screen
• IE/Edge browsers don't hide text, but display the fallback font right away, which seems to be a better design decision by Microsoft.

Although having a sudden change in typeface when reading text on a website is not the best user experience, staring at a blank screen while the font is loading sounds much worse. Ideally, a working approach should overcome both FOUT and FOIT. However, although it's an open issue, there is some consensus among a number of experts that FOUT is way better than FOIT.

Tackling the issues related to fonts loading involves working both on optimizing the file size and taking control of the default browser behavior so as to eliminate FOIT and minimizing the jarring impact of FOUT.

Let's look closer into each task one at a time.

Continue reading %Optimizing Web Fonts for Performance: the State of the Art%

by Maria Antonietta Perna via SitePoint