DEV Community

Cover image for Improving web font performance: a case study
Armel
Armel

Posted on • Updated on • Originally published at netcentric.biz

Improving web font performance: a case study

On the 8th and 9th of November 2018, I had the chance to join the first edition of the performance.now() conference, focusing on today's most important web performance insights. Among the sixteen great talks, I took a great deal away from Zach Leatherman's presentation on Web Font Performance and I would encourage you to watch the full talk.

At Netcentric, where I am a Front-end Software Engineer and web performance guardian, I could immediately see areas in which I could begin to try out some of the tips mentioned to improve web font implementation. I'll illustrate a few points of analysis that could be useful for optimizing web font performance.

Insights for optimizing web font performance

Setup

I mainly used macOS 10 with Chrome 70 for my analysis, and always throttling the network to Fast 3G and CPU 4x slowdown.

Similar fonts

Let's start by simply loading the homepage of the website to see which files are being loaded:

Network tab

We are loading 5 font files, the .ttf and the CAC-Regular cannot be touched as they are very specific but I noticed that we have 3 fonts with quite a similar name:

  • CS-Light.woff2
  • CS-Regular.woff2
  • CS-Demi.woff2

I wondered how different they really are and if we really needed all of them, so I decided to compare them visually by placing one font on top of another. I chose to use the CS-Light font as a base font because it seemed easier to match with the other fonts. In our case, setting a lighter font-weight to the CS-Regular font didn't make any difference, so I could only apply a bolder font-weight.

So, I have the CS-Regular font in green, the one I want to replace, and the CS-Light in red and they don't really match.

We obviously have 2 different fonts

We obviously have 2 different fonts

The first word here looked acceptable, but then it gets pretty wild. However, I could see some similarities so I tried to get a closer match by playing a little with some CSS:

Adding a letter-spacing and a line-height to .cs-light

By playing with two CSS properties, letter-spacing and line-height, which are both well supported, I could actually get a better match:

Fonts overlay

This isn't perfect, but I was surprised at how close I could get and how similar those two fonts are.

I also wanted to make sure they still match even if I change the font-size:

Font-size: 1em

Font-size: 1em

Font-size: 3em

Font-size: 3em

I really liked the result. You can feel a slight difference, especially when the text is made a bit larger, but overall it looks similar.

Then, I wanted to also check the other font we have, called CS-Demi, to see if I could get similar results:

CS-Light cs CS-Demi
CS-Light cs CS-Demi

Again, it didn't really match in the first place. So, I went through the same process and played again with some CSS properties, also adding a font-weight property since this font was much bolder than the other one:

Also adding a font-weight property

In the end, I got a pretty decent result. It's not as good as the previous results, but it's still hard to tell the difference between these two fonts if you don't know exactly which is which:

Font-size: 2em
Font-size: 2em

So, now we can get a pretty similar result by loading only one file instead of three. Let's see what the gain could be:

344.7 KB of web fonts
344.7 KB of web fonts

We are loading 344.7 KB of web fonts separated in 5 file requests.

After getting rid of CS-Regular and CS-Demi, we now have only 197.7 KB of web fonts among 3 file requests, so that's a gain of 147.KB, which represents ~42.6% of the total weight of the fonts of the page. Not bad.

FOIT and FOUT

Another problem we've faced with websites is called Flash Of Invisible Text (FOIT) and also Flash Of Unstyled Text (FOUT). You can definitely see it visually when the network is a bit slower than usual. The Lighthouse audit has also been complaining about it:

The loading of web fonts are timing out (3,000ms)
The loading of web fonts are timing out (3,000ms)

Thanks to the font-display property, we can avoid a FOIT pretty easily, using the fallback value:

Font-display: fallback

As explained on the Google Developers' website:

fallback gives the font face an extremely small block period (100ms or less is recommended in most cases) and a short swap period (three seconds is recommended in most cases). In other words, the font face is rendered with a fallback at first if it's not loaded, but the font is swapped as soon as it loads. However, if too much time passes, the fallback will be used for the rest of the page's lifetime. fallback is a good candidate for things like body text where you'd like the user to start reading as soon as possible and don't want to disturb their experience by shifting text around as a new font loads in.

Be careful though: font-display is not fully supported yet!

Finally, after adding this property, we can fix our FOIT, at least on browsers supporting this feature:

FOIT is not a problem anymore
FOIT is not a problem anymore

However, our FOUT problem remained, so to fix this issue I took a look at the preload hint.

Preload

We need to prioritize our CS-Light request
We need to prioritize our CS-Light request

By examining the timing of the request of our CS-Light web font, I could see that it took almost 5 seconds to load, and it's also being loaded at the same time as the other fonts:

Before preload
Before preload

So I decided to preload the critical web font by simply adding 1 line on the head section (see preload specifications):

Preload the main font file

I could then see straight away that Chrome was loading the main font file before the other ones, and faster too:

Our critical font file has now a high priority
Our critical font file has now a high priority

Time to download the resource is divided by 2
Time to download the resource is divided by 2

Therefore, we started to download our critical web font resource after 1.45s instead of 5.33s, resulting in a gain of 72.8%. This meant it took 2.14s instead of 4.29s to download, meaning a gain of 50% regarding the length of time taken to download the content.

After all those optimizations, we could finally put everything together. We ended up with something that looked like this:

Next steps

There is still room for improvement regarding the optimization of the web fonts, and I'll continue to share the rest of the analysis. The next area to explore will be the possibility of subsetting fonts, since the website is being delivered in many languages.

Feel free to share your experience regarding web fonts optimization below or get in touch if you have any questions about these insights.

Top comments (1)

Collapse
 
vuild profile image
Vuild

Interesting.

Is there a way to merge font files? I only want to deliver one file.