Webfont load

What to consider when optimizing the performance of fonts for website operators
published on: 09.09.2022

Disclaimer: This article contains screenshots from the tool webpagetest.org.
We conducted the tests with the following settings:

  • Server location Germany
  • Speed Fast 3G
  • Device: Motorola G4

We chose this configuration because Google's Page Speed Insights uses a similar configuration.
All speed values mentioned in the article are a result of the above settings.
 

Website operators who integrate fonts into their website in an uncontrolled manner can harm the performance of their website, as this example screenshot from webpagetest.org clearly shows. After the initial connection to the website is established, the example website loads fonts en masse.

In total, the website loads 44 fonts. Before any other resources are loaded. 13 seconds pass.
After 13 seconds loading time, that's what the user sees.

According to SEMRush in the article "What Is a Good Page Load Time for SEO - How Fast Is Fast Enough?", it is not possible to make a general statement about what a good page load time actually is. Rather, the term "good page load" is based on an individual perception that depends on the user and his or her specific needs when visiting a website. Therefore, optimisation should not only be based on speed, but also on user signals such as the engagement rate and the bounce rate. 
However, the article gives a loading time between 1-2 seconds as a guideline.
The example shown above indicates that the goal of a satisfied user had largely been missed. 

We note on the subject of web font load: fonts are often large files that take a while to load. The number of fonts and the way they are integrated has a great influence on website performance. What should website operators  look out for?
This article aims to share some font best practices that help foster good loading times.
 

1. Only integrate fonts that are actually used

We have clarified the question of what fonts actually are in the article "Google Fonts GDPR compliance - What website operators have to consider".

The above example shows, as already mentioned, 44 fonts are loaded when the web page is called up. If we now want to check how many of them are actually in use, the picture looks like this:

What fonts are implemented, but are actually not in use? webpagetest.org gives us this information.

None of the 44 fonts are actually relevant for loading the page. So, the page could actually do without all these fonts and thus save 13 seconds of loading. 

 

If you would like to know how to recognise which fonts on a page are actually in use with the help of webpagetest.org, you can find that out by running an analysis and then, after clicking on a run, going to the section “Opportunities & Experiments”. The corresponding note appears here under "Is it quick?" if there are any abnormalities.

Quickly summarising our findings so far: with regard to webfont load, a page should only ever load the fonts that are actually being used. 

2. Loading fonts from your own server

Loading fonts locally from your own server has a far-reaching effect on page loading times. Depending on how fonts are integrated locally, the effect on web performance can be very positive, or it can have negative effects. The recommendations mentioned in this article are intended to help achieve the best possible performance results with font integration.

In addition, website operators are also on the legally safe side with regard to the German Data Protection Law (DSGVO) if fonts from Google are integrated on their own website.
 
The difference in loading times is defined by the time it takes to establish a connection to external resources. In this example, from the discovery of the font, until the Browser is about to receive the first byte from the Google server, 1254 ms pass. The remaining 609 ms to the 1863 ms shown in the screenshot contain the first byte and download time.
With this request only the CSS file of the font is loaded with the font-face rule.

The CSS-file of the font is being loaded.

For the download of the actual font, a new connection to the gstatic server is necessary, which takes 1150 ms in our example. DNS lookup (green bar), connection and SSL negotiation (orange and pink connection) are a little pulled apart in the present example, because the resources can be addressed early, here by the DNS prefetch command and the link relation type preconnect hints.

Connection to the gstatic-Server

Fonts that are loaded locally via the website do not require an additional connection setup and therefore save some time in this regard.
The time saved for web performance could be between 600 and 800 ms, depending on the integration of the local font.
Let’s summarize: it is advisable to integrate fonts locally on your own website, not only for GDPR reasons, but also for a better web performance.

3. Webfont load: Preloading fonts

Fonts that already play an important role above the fold should be preloaded. 
The following example shows how loading a font later than required can lead to a layout shift. 

Layout shift caused by the loading of a font.

Such reload appearances can be avoided, if the font in question is given a preload tag, i.e. <link rel="preload" as="font">. This will load the font with higher priority. Given that the font is loaded well before the FCP, one can achieve that the user sees the final layout immediately and no longer notices an annoying layout shift.
Google describes in detail in its documentation under "preload your webfont resources" what options are available for this. 

4. Making fonts immediately visible in the rendering process

Even if you use the preload tag, you still can't be sure that the browser will load the font fast enough. The browser knows that it should load the resource preferentially, but the order of the resources to be loaded is still not certain. In terms of fonts, this can briefly lead to a white screen for users. SEO managers may have noticed the message "Avoid invisible text during font loading" in this context during web performance optimization. 

Page Speed Insights warning to ensure that fonts are always visible during web font load,

To prevent this, Google suggests two options. 
 
In the first option, a system font is displayed until the actual font can be loaded. This option is based on the CSS instruction font-display, which is not equally supported by all browsers: More information on this can be found in the Google guide under "Use font display".

The second option is similar to the first option. The difference here is that the browser is instructed manually (by a JavaScript instruction for example) to load system fonts until the actual fonts can be loaded. The advantage of this is that it can be carried out across all browsers. More information on this can also be found in the Google Guide under "Wait to use custom fonts until they are loaded".

5. Caching fonts

In order to not need to fully load fonts from scratch any time a user re-visits a website, there is the option of caching fonts and defining an "expiry date”, i.e. a period of time for how long a font is to be cached. This saves the loading time of the fonts when the website is visited repeatedly.

More information on font caching can be found in this article by Google "Proper caching is a must".

6. Push fonts at the same time as HTML through HTTP/2 server push

Another step that can be taken to deliver fonts as quickly as possible is HTTP/2 server push. 
The HTTP/2 server push allows non-HTML assets such as fonts to be transmitted together with an HTML document.
This differs from the traditional way of delivering HTTP requests, where the HTML document must be parsed before subsequent requests can be made to retrieve fonts and other assets. 

After the HTML document is parsed, fonts are being loaded.

Again, with this it is possible to gain good performance results. If you want to know whether server push is an option for your website, you can find out more in the guide about "HTTP2 server push".

7. Does the font size have an effect on SEO?

"Does font size affect seo?", John Müller was asked via Twitter 2020. The answer is clear: "Font size has no effect on SEO."
https://twitter.com/JohnMu/status/1265191575723925504
 

John Muller on Twitter about fonts.

Photo credits:

Teaser photo: Pexels, photo from mali maeder: https://www.pexels.com/de-de/foto/selektive-fokusfotografie-von-hustle-and-bust-text-54257/

Lisa Fellinger
Former Team Lead Data

Lisa was team lead of the data management team until November 2023 and before that team lead SEO.