Suggestion: Offer a non-render blocking way of loading Google Fonts?

[tunetheweb]

As discussed in a blog post I wrote and in a subsequent Twitter conversation there is a noticable performance impact to using Google Fonts hosted on the Google Fonts domain. Should Google Fonts offer a non-render blocking way of loading to address that?

The use of the recently supported font-display: swap offers a good performance gain, to not block rendering or FOIT while waiting for the fonts themselves to download, but it still depends on the Google Fonts CSS being downloaded to see that font-display: swap instruction.

As an example, a typical waterfall of a site using Google Font is shown below:

As can be seen the initial render (green line) cannot happen until the Google Fonts CSS has been downloaded on line 4 after 4.0 seconds, as CSS is render-blocking. So you can see that, even though we are using font-display: swap, there is still that performance hit due to the time taken to set up the TCP/HTTPS connection to Google Fonts, and then download the CSS. As we are using font-display: swap the Google Fonts CSS doesn't really need to be render-blocking, and the site could have loaded after 2.9 seconds when the main CSS is loaded (or after 2.2 seconds if the styles were inlined into the HTML).

I can think of two ways of supporting this:

1. Add an async option to <link rel="stylesheet" ...> commands. This does not currently exist so would presumably need to go to the CSS Working Group and then be implemented by browsers. Not sure if Google Fonts could help push this as they would be a perfect use case for this?

2. Offer a JavaScript method of loading Google Fonts, with async on the <script> tag, which then injects the <link rel="stylesheet" ...> into the document only after the CSS has been downloaded. This would also need a <noscript> fallback to load the CSS in the usual way. Examples of such scripts exist but an officially supported Google Fonts version would be better.

Of course people can always self-host to avoid this (as discussed in my blog post) but that can be more complicated to set up if you want the full benefits of the performance enhancements that Google Fonts does for you by browser feature detection (also discussed in my blog post), so I thought I'd open this issue to ask if it should be option to do this while still loading from Google Fonts domain?

[davelab6]

Thanks for posting this. Just a few personal comments:

For 1, Perhaps w3c/csswg-drafts#1603 (comment) is relevant, but I think adjusting <link> would be for the HTML WG, not the CSS WG.

For 2, many years ago, Google Fonts recommended this js loader - https://github.com/typekit/webfontloader - but it was removed as CSS itself advanced; there's a newer polyfill approach at https://github.com/bramstein/fontfaceobserver

[tunetheweb]

For 1, Perhaps w3c/csswg-drafts#1603 (comment) is relevant, but I think adjusting <link> would be for the HTML WG, not the CSS WG.

Looks to me like w3c/csswg-drafts#1603 (comment) is in regards to links defined in the CSS (e.g. images), but here's it's the link to the CSS file itself we want to make async, so not the same. As you say, maybe one for HTML WG. Can't say I know enough about either to know where to ask for this to be honest.

For 2, many years ago, Google Fonts recommended this js loader - https://github.com/typekit/webfontloader - but it was removed as CSS itself advanced;

And that's exactly why an official Google Fonts supported JS script would be preferably to depending on third party ones that might be dropped by those maintainers 😊

there's a newer polyfill approach at https://github.com/bramstein/fontfaceobserver

From a (very quick) look at that, this would depend on defining the font face, then using this to update your CSS to add a class to use that font only after it's been downloaded. This means defining all your CSS classes twice. Which isn't quite what I was suggesting (download the CSS asynchronously via JavaScript, and once that has completed inject the <link rel="stylesheet" ...> reference into the page), so no changes are required from what is done currently (except use a JS link instead of a CSS link) as is as easy to use as currently. Again this is why a Google Fonts supported version would be better.

[briantully]

Thank you @bazzadp for writing up the excellent blog post and raising this issue!

[tunetheweb]

FYI, I’m hearing rumours that an async attribute might be being proposed for style sheets which would solve this nicely...

[tunetheweb]

Interesting discussions on an alternative way of doing this here: https://twitter.com/scottjehl/status/1263951701188530177?s=20

Though takes a bit extra to support CSP and no-JS fallbacks: https://twitter.com/tunetheweb/status/1264117342738493440?s=20

[scottjehl]

+1 to offering a non-render-blocking embed. That said, I would prefer to see @font-face options instead of async CSS or Script loading approaches listed above. It would be amazing if the embed options offered a @font-face rules that could be placed in an existing site stylesheet or in a style block, to be able to use google fonts without introducing the render block. Thank you!

[Cheglok]

+1