… À 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 ».
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.
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.