Skip to main content
Dev Corner
Frontend Performance: Fast Web Fonts

Frontend Performance: Fast Web Fonts

Fonts are a crucial part of every app or website, and they can also play an essential role in the frontend performance.

Using a fast eCommerce API alone does not guarantee a fast experience for the user, especially if you are using external fonts the wrong way. Ensure that your fonts load fast so that your customers are experiencing a super fast eCommerce.

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.


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 that I’m working on. Recently, I came across a great article over at Smashing Magazine about "Optimizing Google Fonts Performance" by  Danny Cooper. So, based on it, I ran some tests on my own to see results and take my conclusions.

The first thing that I’ve done is that I used the browser console to see the sizes of each download and see how it will impact.

For the test, I’ve used the Roboto font since it’s one of the most used fonts, with a lot of 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.

The Tests

All right, so let’s get started.

First, I’ve started by asking for the font 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.


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:


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

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


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

@font-face {  font-family: 'Roboto';  font-style: normal;  font-weight: 700;  src: local('Roboto Bold'), local('Roboto-Bold'), url( format('woff2');}

And as you can see, there is a new HTTP request 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… And the request will be sequential, meaning they will only be fulfilled after the previous is completed!

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

DNS Prefetch and Preconnect

DNS prefetch and preconnect scripts that will allow the browser to start the connections with Google Fonts API as soon as the page begins to load!

<link rel="dns-prefetch" href="//">

And the 

<link rel="preconnect" href="" crossorigin>

This will allow the browser to start the additional necessary requests for each font variant at the same time as the first one starts, instead of waiting until the first request finishes to start the other ones!

@font-face descriptor (currently defined as font-display) that allows control over how a downloadable font renders before it is fully loaded.

Cool! Now that I’m getting the fonts from the Google Font API without blocking the requests, I only have to rely on the internet connection and hope that the requests will be fulfilled.

Question: While the browser is retrieving the font(s), will the user see something? Some text?

Well, maybe not but I can solve that with one thing: display=swap. All I need is to add this query parameter to the request and the modern browsers will swap the font to the system default while the specific font is being loaded!

Google Fonts API will return this:

@font-face {
  font-family: 'Roboto';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: local('Roboto'), local('Roboto-Regular'), url( format('woff2');
  unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;

See the font-display: swap? That is what will tell the browser to swap the font to the fallback while fetching the Roboto one.

Go to Can I Use and search for font-display, we’re presented with this description:

The font-display descriptor determines how a font face is displayed based on whether and when it is downloaded and ready to use.

And all the major browsers already supported it.

This is a great feature, or at least for me 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 wouldn’t be better to keep the fonts I want and serve them myself? 

We can. And previous I was doing it this way but then I read more about it and realise I would have more work on my end, like keep the fonts up-to-date, check for new releases and keep 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 what is the best font format that can send back. 

Based on that, the API will send the highest compressed format of the font which can save some bytes, whether 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 they can use them, or they will use the fallback since the font-display will swap!

Async Load Fonts

There is a trick that can be done to have the fonts being loaded asynchronously, to avoid chaining requests, as can be found in the Page Speed Insights from Google.

<link href="|Roboto:400,500,700,900&amp;display=swap" rel="stylesheet" media="print" onload="'all'">

It's simply having the link to the Google fonts API set to media "print" and change it as soon as the load finishes to "all" since we want the styles to be applied to the screen environment. That is done with the `onload="'all'"` the `onload` attribute that will be executed immediately after a page has been loaded resulting in no chaining requests!


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 (weight 400 and 700), 94.2% reduction. As you can see, it has a significant impact on frontend performance, improving your site speed and specifically first contentful paint (FCP).

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