In this article, we will explore how preloading fonts can improve Core Web Vitals. We’ll look at how font loading impacts performance metrics like Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS), and how preloading fonts correctly ensures that text appears faster.
How do web fonts impact Core Web Vitals?
To understand how fonts load, let’s take a look at a typical request waterfall. In this request waterfall, we have highlighted the font request chain:
- The HTML request finishes
- Then the CSS request which references the font begins
- Once the CSS request completes, the font request can finally begin
- Once the fonts is loaded text on the page renders using the web font
In this case, the request chain causes a delay and the font request finishes at 4.54 seconds.
Font rendering late in the page load can cause a Flash of Unstyled Text (FOUT). As the font finally replaces the unstyled text, a layout shift may occur. Worsening the page’s CLS score.
In the filmstrip below we can see a layout shift caused by a FOUT. Once the font renders, the <h1> element forces the main image to move up the page and occupy the empty space.
Although FOUT is not ideal, the worst case scenario is text not displaying at all. This is known as invisible text, the text will only appear for the visitor once the web font loads.
How to optimize web fonts with preloading
Preloading is a technique that tells the browser to fetch important resources early in the loading process. This helps improve performance by ensuring critical assets are available sooner, reducing delays in rendering and directly combatting the FOUT and invisible text issues we outlined before.
Below we can see a typical font request chain, where the font request begins once the CSS request completes.
On this page, the LCP element is <h2> text which is invisible till the font loads. To ensure that the font request is discovered sooner, we can preload the font by adding the following link tag to the HTML head:
<link
rel="preload"
href="https://fonts.gstatic.com/s/opensans/v40/memvYaGs126MiZpBA-UvWbX2vVnXBbObj2OVTS-mu0SC55I.woff2"
as="font"
type="font/woff"
crossorigin="anonymous"
/>
After preloading the font request, the font is no longer dependent on the CSS request. The font request is discovered sooner and made in parallel with the render-blocking CSS requests. The LCP score has improved from 1.82 seconds to 1.24 seconds.
Don’t preload too many fonts
Only the most important requests should be preloaded. This is to avoid bandwidth competition between requests, eliminating the benefits of preloading. If too many requests are preloaded, then a recommendation will appear in the lab test result.
In this example, we can see 38 preloaded fonts. This is causing lots of bandwidth competition between not only the font requests, but also render-blocking requests. With so much bandwidth competition, the page is unable to render quickly, causing the FCP and LCP scores to be negatively impacted.
After running an experiment to remove these preloads, we can see that the CSS request now finishes 2 seconds sooner as there is less bandwidth competition. With the page able to render sooner, the LCP score consequently improves.
This example demonstrates the importance of carefully selecting which requests should be preloaded to minimize bandwidth competition. As both the FCP and LCP scores have improved by over 2 seconds, allowing the visitor to view the page content faster.
What fonts should I preload on my website?
The previous example highlighted the effect of excessively preloading fonts, so which fonts should be preloaded?
Any important fonts used above the fold should be preloaded. Such as nav, headings and any main content text.
Consider the fonts that are used most often. If you use a wide selection of fonts, preload the fonts that are used frequently throughout the page, rather than a font that is exclusively used for a single section.
Preload Google Fonts
The default Google Fonts embed code looks contains two preconnect hints, but no preloads:
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link
href="https://fonts.googleapis.com/css2?family=Roboto:ital,wght@0,100..900;1,100..900&display=swap"
rel="stylesheet"
/>
That's because Google supports multiple font formats other than WOFF 2. If an older browser loads the page it will be served EOT or WOFF fonts. In those cases preloading the WOFF2 format would be useless.
However, WOFF 2 now has more than 97% browser support. That means preloading fonts in this format will benefit the vast majority of users.
How to preload Google Fonts
First, identifying what WOFF 2 file is loaded on your website. You can use a free website speed testing tool or Chrome DevTools.
Then add the preload hint to your website code:
<link
rel="preload"
href="https://fonts.gstatic.com/s/roboto/v47/KFO5CnqEu92Fr1Mu53ZEC9_Vu3r1gIhOszmkBnkaSTbQWg.woff2"
as="font"
crossorigin="anonymous"
/>
Fonts can be split into different character subsets with the unicode-range CSS property. If your website uses non-latin characters you may need to load multiple WOFF 2 files.
Continuously test your website speed
It is common for fonts to change and for the preloads to become outdated over time. That means you could be loading both the old fonts and the new ones, causing Core Web Vitals regressions! When preloading fonts on your website, ongoing monitoring is essential to catch any regressions as they happen.
Start your free 14-day trial and start optimizing today.
Monitor Page Speed & Core Web Vitals
DebugBear monitoring includes:
- In-depth Page Speed Reports
- Automated Recommendations
- Real User Analytics Data