Still using WebFontLoader to load (Google) Fonts? Don't!

To save you some time, let's jump to the answer: No, you should not be using the WebFontLoader library anymore.

I'm writing this article though, as I still see it being used when doing pagespeed audits. It's especially Webflow websites, but sometimes also custom solutions where I see WebFontLoader being used.

The purpose of WebFontLoader

Let's start with describing what WebFontLoader library does: it can be used to control the loading experience. Controlling the loading experience can be achieved in different steps:

• you embed the WebFontLoader library;
• Then tell it which fonts you want to use;
• WebFontLoader will download them;
• And once downloaded, it will add a class to your html document and apply the fonts.

That's quite cumbersome to just load fonts. But this has a purpose as once again, it is used to control the loading experience.

Mimic your custom font

As a developer, we can use those classes to change letter spacing or line height once the web font is done downloading. And without the font hiding delay that browsers would otherwise introduce by default. Although nowadays this can be solved using the CSS font-display property.

But let's focus on mutating font characteristics, to mimic the font characteristics of your preferred custom font. You could then do:

html:not(.wf-loaded) body {
letter-spacing: 0.01em;
line-height: 1.1;
font-family: Arial;
}

Additionally, it would then be wise to also choose a fallback font-family that's already close to the characteristics to the expected custom font.

Pagespeed bottlenecks of WebFontLoader

If anything should be put on a diet, it's JavaScript as CPU boundaries nowadays is one of the challenges. So, using JavaScript to improve font loading performance is a bit.. contradictory. It might even end up contributing to a bad FID or Google's new INP metric.

And it's almost always implemented in a parse and thus render blocking way. Anything and especially JavaScript that is parse and render blocking, is harmful towards the FCP and LCP metrics.

And in some cases, sites aren't using WebFontLoader the way it was meant to be used. So, they aren't actually changing any font characteristics. And as a result, the added benefit isn't really there, just the negative pagespeed impact.

So, in the end, if you're still using it: Stop using WebFontLoader and directly see your FCP and LCP improve. Do note that Core Web Vitals comes with a 28 day delay, so to see the immediate impact by exact percentages, you might want to use a Real User Monitoring solution.

Should you then not use JavaScript at all?

You could, and maybe you should. For example to group repaints when your design needs multiple fonts. Do note though that:

• you could try to limit the amount of fonts needed above the fold.
• you still don't need a whole (WebFontLoader) library, but could just use the native FontFace API instead.