Optimising web fonts - Part 3: Loading strategies
Mid-last week Google announced that it is giving folks a bit more time to get ready for the Core Web Vitals (page experience) update. I think they really meant to say, "we're still working on finalising Core Web Vitals (especially CLS), so we need to delay things". Anyway, the new timeframe is from mid-June to August. The changes will be rolled out gradually and will take full effect at the end of August.
With that out of the way, let's get onto the final part of our web font optimisation series. This week we'll look at loading strategies that can get custom fonts appearing on your site faster. This is an important part of reducing/eliminating layout shifts during page load.
I'm going to sound like a broken record here, but the most optimal font loading strategy is to use system fonts on your site. There's no network or download latency involved, so fonts will appear almost instantly.
Now that the mandatory 'use system fonts' comment is done, let's return to the real world where brands require custom, creative typefaces to be used on their websites. How do we make web fonts load faster so that they're not negatively impacting the overall page experience? It can get really complicated, but here are some of the easier wins.
- Reduce the file size (covered in Part 2 of this series)
- Host files on your own domain.
preloadto download font files earlier.
Self-host font files
The easiest way to use a web font is to find it on Google Fonts (or another font repository). You'll be given a code snippet to paste into your site's code. That's all well and good, but there are a couple of downsides that come with using fonts hosted on external domains:
- There are multiple network requests (including TCP/SSL handshakes) that need to be made to get stylesheets and font files.
- Chrome & Safari prevent cross-site resource caching, so there are no performance gains from using a common online third-party source for assets.
Hosting resources like fonts on your own domain can help speed up the request time for assets since there's no need to initiate new TCP/SSL connections each time.
Effectively is the keyword in the title of this section. Preload is extremely handy in prompting the browser to download certain assets earlier than it otherwise might. However, if everything is a priority, then nothing is.
preload in general back in Issue 10, but how could we apply it specifically to web fonts? Here are a few general things to keep in mind:
- Try to preload only one web font (if you're not preloading much else you could push it to two - try it, measure the results, and act accordingly).
- If you're using WOFF2 then preload that file.
- When it comes to deciding what font to pick, there are a few ways to go about this:
- Pick the first font that appears in your CSS
@font-facestack. This is a good rule of thumb.
- If you have a large title visible when the page loads, consider preloading this instead. The title element would most likely be a Largest Contentful Paint (LCP) candidate, so having the font file ready for it can help with your LCP Core Web Vitals score.
- If fonts are causing layout shifts as your page loads, then try to identify the culprit & preload that font to minimise its impact on your Cumulative Layout Shift (CLS) Core Web Vitals score.
- Pick the first font that appears in your CSS
crossoriginattribute is required when preloading web fonts, even if they're hosted on your own domain. Just add
crossoriginto the end of the preload link tag.
The preload tag you'd place in the head of your HTML page should end up looking something like this:
<link rel="preload" href="webfont.woff2" as="font" type="font/woff2" crossorigin>
The word effectively is a bit less important here.
font-display is a CSS property you can add to the
@font-face blocks of your code to tell the browser how to handle that displaying content before a web font is fully downloaded.
There are four options for
font-display but we're only going to concentrate on two of them.
swap you're telling the browser to show text immediately using the first available fallback font, and then swap in the web font when it's downloaded.
- You'll show textual content early, even if the font hasn't loaded. Better for LCP.
- Swapping in the web font after it has been downloaded is a very common cause for layout shift (poor CLS scores). If you're going to use this approach, then take the time to match your fallback fonts as closely as possible to your web font - this reduces the visual disturbance caused when the fallback font gets replaced. Font Style Matcher is a very good tool for this.
optional you instruct the browser to hide text for 100ms and then load the web font only if it's available. If it's not ready, then the browser will use a fallback font instead for that page view.
- No layout shift (better for CLS), and only a very small hit to LCP scores.
- Even if the web font is not ready within the 100ms window initially, the browser will still download & cache it (assuming cache headers are properly set). This means that the next page a user visits (or the next time they come back to your site), the web font will be ready to use right away.
- If you're especially picky about the typography of your site, then choose fallback fonts carefully when using this approach. There's a strong chance any visitor to your site will have at least one page experience rendered with a fallback font.
The above factors should get you well on the way to better font loading performance on your website. If you want to dive deeper into the weeds of font optimisation, you can read Zach Leatherman's A Comprehensive Guide to Font Loading Strategies.
- Part 1 & 2 of this series for some reference.
- A Comprehensive Guide to Font Loading Strategies - As the name suggests, a deep dive into the many and varied font loading approaches available to web developers. Recommended reading that adds to what we've covered in this series.
How to Convince Your Boss to Care About Speed
You might care about web performance, but getting it on your boss' list of priorities can be a challenge. The team over at Calibre have some tips to help you persuade the leaders in your company to put more attention on website Performance.
Get the FLoC Out
Jeremy Keith's take on FLoC. This is a well thought out article that looks at Google's latest move to counter the demise of third-party cookies for data collection. I've opted-out out of FLoC for both my personal website and the Optimised site.
The next issue of Optimised will be in your inbox on May 14th. The website has an archive of all previous emails. It's a good place to recap on anything we've covered, and also handy to share with friends or colleagues.
As always if you've got any feedback or specific topics you want to be covered then just reply to this email.
Keep safe, stay well.