If there’s connection one thing I’d like readers to take away from this post it’s that font-display: swap is a very good option for users with a fast internet. But its infinite swap period could be frustrating for users on very slow and unstable connections. If you have users viewing your site under these conditions (I’m pretty certain you will at some point in time), then it may be worth considering font-display: fallback or even font-display: optional. Both have a short swap period (or no swap period), meaning once the fallback font is rendered and the 3 second timeout is exceeded, the font won’t change for the rest of the page lifecycle.

Let’s talk about eliminating font stylesheets as a render-blocking resource, and walk through an optimal setup that not only makes Lighthouse happy, but also overcomes the dreaded flash of unstyled text (FOUT) that usually comes with loading fonts. We’ll do all that with vanilla HTML, CSS, and JavaScript, so it can be applied to any tech stack.

Because it takes time to set up a connection with the Google Fonts domains, and because that connection is needed before the render-blocking CSS can be downloaded, it can delay rendering metrics like Largest Contentful Paint.

Variable fonts reduce the overall combined file size and automatically reduce the number of network requests by simply being a variable font.
Even if you consider the slightly larger file sizes, when combined with improved font compression formats like WOFF2, font subsetting and font loading techniques like font-display: swap; we end up in a situation where we can still get smaller overall font file sizes as well as a significant increase in stylistic opportunity.

And there you have it, a way to change the font-display settings of a page when using WebPageTest. No need to manually update the code to see what effect the property has on a pages perceived performance.

Yes it's better to self-host as the performance gains are substantial […] However, Google Fonts is not just a repository of hundreds of free fonts - it is also a clever delivery mechanism […] There is some complexity involved in this (which Google Fonts handles for you) but with WOFF2-only being a realistic option now, and good support of most techniques with inbuilt fallbacks, this is easier than it used to be.

The crossorigin attribute, when used with rel="preconnect", doesn't describe where the target origin is but rather what kind of assets will be downloaded from that origin. If the assets use CORS, crossorigin is needed. If CORS won't be used, crossorigin should be omitted. If both types of assets will be present, two resource hints are necessary.

Browsers don't always behave as we would want or expect them to, but we do have tools at our disposal to steer that behaviour towards the result we want.

If you're using a web font, you're bound to see a flash of unstyled text (or FOUC), between the initial render of your websafe font and the webfont that you've chosen. This usually results in a jarring shift in layout, due to sizing discrepancies between the two fonts. To minimize this discrepancy, you can try to match the fallback font and the intended webfont’s x-heights and widths [1]. This tool helps you do exactly that.

Google Fonts are easy to implement, but they can have a big impact on your page load times. Let’s explore how we can load them in the most optimal way.

This is a small explainer that I built for a talk on web fonts and performance. […] For example, if you're rendering the main body text on a site, you should use font-display:optional.

Given the issues I outlined earlier, should we even consider preloading fonts?

I suspect even with Chrome’s current sub-optimal behaviour there’s a case for preloading one or maybe two critical fonts.

But don’t take my word for it, test it for yourself as your traffic mix e.g. Safari vs Chrome, the choice of server and your page make up will influence the outcome:

Yes because :

1. Group Repaints (better performances)
2. Adapt to User Preferences (a11y and UX)
3. Adapt to User Context (better performances, UX)
4. Using Third Party Hosts for fonts

"Web performance is an intricate topic but well worth the effort. Cutting down initial network requests through progressive enhancement and lazy loading is useful to make initial rendering as fast as possible. Showing basic content first, and then loading enhancements like fonts, media, and scripts later, brings the user experience in harmony with aesthetic designs and business goals."

Web fonts are awesome. They make your sans-serifs slabby, your headers special and your website look gorgeous. But fonts are a resource, and downloading resources always comes as a cost — if you don’t load web fonts efficiently, what you get instead are phantom underlines, blank pages, and user rage. Let’s talk about ways to avoid this, and what new platform features are here to help us deliver pretty (but also!) fast experiences to everyone.

Web fonts are difficult to get right. An often overlooked and disruptive piece of web performance, web fonts can slow down your site and leave your visitors confused and agitated. No one wants agitated visitors. In this talk we’ll discuss useful methods to render web fonts quickly and without disruption so that visitors can do what should be a simple task—read the text. After all, web fonts are not rocket science.

subfont – a command line tool to statically analyse your page in order to generate the most optimal web font subsets, then inject them into your page. Now listed on Perf Tooling.