Drawbacks of Web Fonts and How to Mitigate

The use of web fonts is only justified if they significantly improve the user experience and/or the success of the website. I argue that web fonts (for text) are only warranted if they’re crucial for the branding of the website or associated products/companies. For a more balanced decision-making process, refer to this insightful blog post.

A common objection to system fonts is the variety of fonts used across different systems. However, with a good fallback strategy, these differences can be minimized. Modern Font Stacks provides an overview of similar fonts used across various systems. By selecting an appropriate @font-face descriptor (see Optimization 4.2), you can achieve nearly identical appearance across systems, although this requires additional effort upfront but saves work on disadvantages 2,3 and 4 discussed later.

Variable web fonts allow downloading multiple fonts of a family with a single request, reducing data load. Since variable web fonts are larger than normal ones, this is beneficial only if a variable font replaces at least two standard web fonts.

While still relatively new, this technology is supported by most browsers,⁴ and a significant portion of transmitted web fonts are variable,⁵ largely thanks to Google Fonts.

Allowing visitors to choose whether to load fonts can save additional data. For visitors with poor internet connections or those indicating a desire to save data⁶, we can forego web fonts. This optimization can also apply to other resources, making our website more inclusive.

window.navigator.connection⁷ provides information about the visitors’ connectivity in JS, including the saveData property.

If the web fonts are hosted on our own server (see Optimizations 2.1 and 4.2), they should be cached aggressively. Web fonts generally don’t change often, and if we’re concerned about future changes, we can include a hash of the font (e.g., as a GET parameter) in its URL.

If web fonts become visible only after user interaction or scrolling, we can implement a strategy to load them as needed (lazyloading). For scrolling scenarios, the IntersectionObserver API⁸ is an ideal choice to trigger the loading process.

In cases of user interaction, browsers default to not load fonts if they are only used inside elements that have display: none, because these elements are not part of the render tree.⁹ If you can’t use the display: none trick for some reason, you’d need to implement your own lazyload work-around since visibility: hidden and content-visibility: auto|hidden wont do the deed out of the box.

Font formats have become significantly more efficient over the years. Uncompressed formats like OTF or TTF are 2-3 times larger than WOFF (gzip compression) and WOFF2 (brotli compression), with WOFF2 being notably more compressed.¹⁰ It makes sense to use only WOFF2 compression, as browser support has been excellent for several years.¹¹

Web fonts typically cover all Unicode characters, far more than we typically need on our websites. Fortunately, web fonts can be divided into subsets, so we only declare the characters we need to be loaded. Determining the ranges needed on our website manually is challenging, but tools like subfont on GitHub can help determine and generate the required subsets at the page level.

One approach is to ask visitors for permission, possibly as part of the cookie notice. The feasibility of this solution for our given projects need to be assessed obviously. If a user only accepts necessary cookies, we must accept, in light of the aforementioned legal ruling, that no third-party web fonts will be loaded. The more stakeholders are involved in such projects the less likely it is, that this will be approved though.

We can host web fonts on our own servers. This avoids privacy issues and should bring performance benefits, as we don’t need to connect to another server and can initiate the download of fonts faster with link[rel=preload]. However, in practice, websites with self-hosted fonts don’t always perform better than those with Google Fonts.¹⁴

Why is this? Several reasons come to mind:

1. Some websites don’t use CDNs, so Google Fonts and the likes can be delivered faster to users (especially for an international audience).
2. Caching is not optimized adequately or is entirely forgotten. (Optimization 1.4)
3. Self-hosted fonts don’t offer subsets (ranges), so the largest file is always used. (Optimization 1.7)
4. Self-hosted fonts are set up once and then not further optimized, so they don’t use the most current formats. (Optimization 1.6)

Thus, it’s clear that when self-hosting, the other optimizations must be considered to achieve a performance boost.

I should mention that the above mentioned statistic of websites performing better on average when loading fonts from Google Fonts is from December 2020. Chrome had just removed the possibility to reuse cached resources that were loaded via another domain.¹⁵ Would be interesting to see if websites with third party web fonts still perform better.

The font-display¹⁶ descriptor lets us control what happens until the web fonts are loaded. If time to first text is your main priority, swap is the option of your choice. But let’s look at the specifics:

• Often the default value results in the block behaviour, which waits up to three seconds (Chrome, Firefox) for the specified web font to arrive before displaying any text. This results in “Flashes of Invisible Text” (FOIT) and should be avoided as it delays text display and can cause layout shifts, the worst of both worlds.
• swap eliminates this waiting period and immediately shows text with the fallback font, to be replaced by the web font once available. This results in “Flashes of Unstyled Text” (FOUT) and should therefore be used cautiously (see Optimization 4.1).
• optional waits very briefly (up to 100ms) for the specified web font to become available, using the fallback font if the wait is over. Here too, there’s a risk of FOIT and resulting layout shifts unless appropriate precautions are taken (Optimization 4.2). The browser may decide to not download a font or give the download a low priority depending on the likelihood the web font would arrive in time.
• fallback is quite similar to optional. It waits very briefly (up to 100ms) for the specified web font to become available, using the fallback font if the wait is over. If the web font becomes available within ~3 seconds, the fonts are swapped. Unfortunately, this can result in both FOIT and FOUT.

Our goal is to make our content available as quickly as possible, which might tempt us to use a link[rel=preload] for all web fonts and initiate connections to external domains as swiftly as possible via link[rel=preconnect]. However, caution is required! External domains not part of our network should only be connected to after obtaining consent (see Optimization 2.1), which already makes preconnect less viable. On the other hand, preloading makes a lot of sense for self-hosted fonts, even if they are optional (see Optimization 4.2). Nonetheless, this should be limited to essential web fonts (see Optimization 1.5), as excessive preloading can delay the display of other crucial resources. It’s better to reserve additional preloads for LCP (background) images or similar.

If @font-face declarations for self-hosted web fonts are in an external CSS file, it is particularly effective to preload these fonts. The situation becomes more complex with web fonts from third-party providers that specify @font-face rules in their external CSS files, as the exact font URLs to be loaded might not be permanent.

Another factor to consider with preloading is that we cannot specify a unicode-range (see Optimization 1.7).¹⁷ Therefore, we need to do our homework when subsetting fonts and determine which ranges are required for our site and cannot leave this management solely to the browser.

Clearly, we aim to select fallback fonts that closely resemble our web fonts. However, without intervention, the differences between the fonts can be significant enough to cause layout shifts, such as when text occupies a varying number of lines. To mitigate this risk, we can apply the following descriptors to our fallback fonts:¹⁸

• The most critical descriptor is size-adjust, which allows for adjusting the size of a font without changing the ‘font-size’. This is particularly useful when the web font and fallback font differ in size.
• Using ascent-override, descent-override, and line-gap-override, we can vertically align and outline the fonts.

The website screenspan.net provides guidance on the best values for these descriptors based on different scenarios.

While this approach entails additional work, especially if we need to adjust multiple fallback fonts, the effort is worthwhile for a smoother rendering process.

If Web Fonts only offer a slight improvement and the website functions well without them, optional fonts present an excellent alternative. In this scenario, Web Fonts are used on the website only if they are available quickly enough (within a maximum of 100ms after they are supposed to render, see Optimization 3.1). Otherwise, the fallback font is used.

This approach is particularly effective for self-hosted fonts because, in combination with preloading, we can ensure that no layout shift occurs due to FOIT.¹⁹

With repeated visits to the website, the optional Web Font will be used if visitors haven’t disabled their cache and if we’ve done our homework regarding self-hosted fonts (Optimization 1.4).

In a test conducted at my previous employer, we found that only 30% of visitors saw the fallback font at least once. This test was carried out on a website that had around 10,000 predominantly Italian visitors during the test period and was hosted on a server in Italy (without CDN). These numbers may vary depending on the project, but for us, this result was satisfactory enough to completely shift from Optimization 4.1 to 4.2 for this project. (Later, we completely abandoned web fonts on this project due to consistent user signals, indicating that web fonts were not a critical component in this case, see Optimization 1.1).

One downside of optional fonts is that all stakeholders must be comfortable with the trade-off. Do designers like the idea that their favored font is not visible to all visitors on all page loads? Do all employees, regardless of their technical understanding, grasp why the website may look different after a refresh compared to the initial load?