Webfont load

1. Only integrate fonts that are actually used
2. Loading fonts from your own server
3. Webfont load: Preloading fonts
4. Making fonts immediately visible in the rendering process
5. Caching fonts
6. Push fonts at the same time as HTML through HTTP/2 server push
7. Does the font size have an effect on SEO?

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.

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:

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.

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.

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.

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.

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.

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