A small tool to compute your fluid typography clamp() instruction

… À partir du moment où vous avez identifié ce cas, je vous recommande fortement d’expérimenter la suppression de la version en gras « Bold 700 » et l’utilisation de la version « faux gras » avec la propriété CSS font-weight avec pour valeur bold ou 700.
…
Et n’en déplaise aux typographes, la différence visuelle est tellement légère par rapport à l’utilisation du poids d’une font web en plus, que cela justifie l’utilisation de ce « faux gras ».

As a web font loads, you can now adjust its scale, to normalize the document font sizes and prevent layout shift when switching between fonts.

Fine-tune your font files and optimise your loading strategy for maximum speed + minimum FOUT.

1. Use the most modern file formats
2. Use the font-display descriptor
3. Preload your font files
4. Subset your font files
5. Self-host your fonts

Chrome has stated their intent to make size-adjust available in Chrome 92 due for release on July 20th presumably indicating it’s almost there.

So, not quite ready yet, but looks like it’s coming in the very near future. In the meantime, have a play with the demo in Chrome Canary and see if it can go a bit closer to addressing your font loading woes and the CLS impact they cause.

An impressive article to explain how not to cause Layout Shifts and penalize your CLS.

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