Fast Web Fonts for Better Website Performance

Using a fast eCommerce API alone does not guarantee a fast experience for the user, especially if you use external fonts incorrectly. Besides a better user experience overall, optimizing page performance and designing loading fonts you use fast is necessary.

One of the most recent studies found that the median font file with an English-only subset of characters should be around 12K (source).

What does that mean for you? and how can you do that? Well, read on to find out how to reduce the font byte footprint up to 90% to improve site speed and FCP. And I'll share the best practices for font optimization.

With the evolution of web browsers, new features are coming every day, and today, I would like to talk about one that, although small, may impact the performance of the website/app.

I always strive to improve the performance of the website or application I’m working on. I recently came across a great article at Smashing Magazine about "Optimizing Google Fonts Performance" by  Danny Cooper. So, based on this, I ran some tests on my own to see the results and draw my own conclusions.

The first thing I did was use the browser console to see the sizes of each download and see how it would impact. I’ve used the Roboto font for the test since it’s one of the most used fonts ATM, with many variants, 12, to be more precise! Being them:

1. Thin
2. Thin Italic
3. Light
4. Light Italic
5. Regular
6. Regular Italic
7. Medium
8. Medium Italic
9. Bold
10. Bold Italic
11. Black
12. Black Italic

And the API that I’ll use for the test is the Google Fonts API.

All right, so let’s get started.

First, I’ve started by asking for the font family Roboto: 

fetch("https://fonts.googleapis.com/css?family=Roboto")

Which turn to be the normal font style with the weight of 400 for the following languages:

• latin 
• latin-ext 
• vietnamese 
• greek 
• greek-ext 
• cyrillic 
• Cyrillic-ext

The measurements I’ve got were:

Then, let's try all of the 12 variants.

fetch("https://fonts.googleapis.com/css?family=Roboto:100,100i,300,300i,400,400i,500,500i,700,700i,900,900i")

Now, let’s say I only need the variants regular (400) and the bold (700) because they will be the only ones that I’ll use:

fetch("https://fonts.googleapis.com/css?family=Roboto:400,700")

So, it’s possible to see the bundle sizes and the times to download them are decreasing! 

That’s awesome. However, that is one more thing that we can do. Let’s say I’ll use only the Roboto font for the title of the website/application. Then I could ask for those characters and reduce the bundle size and time to download even more:

fetch("https://fonts.googleapis.com/css?family=Roboto:700&text=xcompany")

So what is happening here? Let’s try to make things more clear. So, for each variant, I ask the API, and the response is something like this:

@font-face {  font-family: 'Roboto';  font-style: normal;  font-weight: 700;  src: local('Roboto Bold'), local('Roboto-Bold'), url(https://fonts.gstatic.com/l/font?kit=KFOlCnqEu92Fr1MmWUlvBh0_IsHAncsWGhbabilm&skey=c06e7213f788649e&v=v19) format('woff2');}

As you can see, a new HTTP request is coming with the font face, so the browser still needs to fire another request to get the font! And that’s why the time varies for each request, although the resource size is smaller.

Now, imagine that we need to fire this for each font variant. The requests will be sequential, meaning they will only be fulfilled after completing the previous one!

To speed up things more and don’t block every request, two things can be done.

This is a great feature, or at least for me, it was the wow factor because users will have some context to see while the specific font is being loaded.

This is all cool, but one could ask if it wouldn’t be better to keep the fonts I want and serve them myself. 

We can. Previously, I was doing it this way, but then I read more about it and realized I would have more work on my end, like keeping the fonts up-to-date, checking for new releases, and keeping several font formats for different browsers.

Why doing this while the browsers can do it for us?

The Google Fonts API at the time of font request will check out the user-agent to know the best font format that can be returned. 

Based on that, the API will send the highest compressed font format, which can save some bytes, whether it is a woff2, woff, eot or ttf format! And it will also provide the most up-to-date font.

The only thing that can go wrong is that the request is not fulfilled because of the internet connection (or lack of it), but the browsers keep fonts in the cache so that they can use them, or they will use the fallback since the font-display will swap!

It’s clear that considering the download of the Roboto font (weight 400) vs. (weight 700 and the needed text), we are facing a reduction of 88.13%! And even more when going with (weights 400 and 700), 94.2% reduction. As you can see, it significantly impacts frontend performance, improving your site speed and, specifically, first contentful paint (FCP).

In today’s speed-obsessed world, every byte matters.