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.
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.
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 . This tool helps you do exactly that.
"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.