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.
Front-end Software Engineer
Feb 01, 2019
Insights for optimizing web font performance
I mainly used macOS 10 with Chrome 70 for my analysis, and always throttling the network to Fast 3G and CPU 4x slowdown.
Let’s start by simply loading the homepage of the website to see which files are being loaded:
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:
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
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:
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:
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
Again, it didn’t really match at 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:
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:
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
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)
Thanks to the font-display property, we can avoid a FOIT pretty easily, using the fallback value:
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.
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
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:
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.