Google Fonts are hugely popular. More than 42.8 million websites download them. The Google Fonts library contains 1,023 free fonts and APIs for embedding them via CSS. It would seem very convenient.
Many articles have noted the cost of multiple API requests. The advice to host fonts on your own has been given for many years. Even Google itself gave this advice at the 2018 Google I / O conference in a talk on web performance.
So why do so many people still download fonts through the Google Fonts API? Well, there was the last argument – caching. Like, thanks to the common CDN, the user does not need to download the font again from each site. However, in October 2020, this argument stopped working. Now Google Fonts are no longer cached!
Your hosting is faster
By its nature, Google Fonts, even with all the optimizations, cannot load faster to the client than from the native hosting.
Optimized loading of Google Fonts with preconnect option (hint for browser to pre-connect to fonts.gstatic.com domain to speed up connection establishment in the future):
This is because Google always requests a stylesheet from the server. It loads anyway. And then the @ font-face declaration tells the browser to use the local (cached) version of the font, if available. At least it was like this before. But lately, Google has removed the local () function from @ font-face in Google Fonts! That is, Google Fonts can no longer be read locally when using the API.
Additional latency occurs due to additional requests to the Google server.
Download from fonts.gstatic.com with preconnect option
Loading from your hosting with the preload option
As you can see, in the second case, there are no requests to fonts.gstatic.com, which immediately reduces the page load time. This is the best option.
Hosting Google Fonts in the site directory
Mario Ranftl has created a very useful google-webfonts-helper. Here you can select specific fonts from the Google Fonts library, the desired character sets, weights, see browser support – and get the CSS code and the files themselves. That is, you can transfer the necessary fonts to your hosting in a couple of mouse clicks.
Choosing a font, character sets, and styles. The more styles we choose, the more download volume for the client.
Different font families have different levels of elaboration. For example, only 118 out of 1023 fonts on Google Fonts support Cyrillic. Not all fonts support the full set of weights.
And we get the CSS code to insert. Option to support the maximum number of browsers, including outdated ones:
Option to support modern browsers only:
As you can see, the local () function has been preserved here, in contrast to the official Google styles.
The default directory for fonts is ../fonts/.
Modern browsers need WOFF and WOFF2 files, while older browsers also need TTF, EOT, and SVG formats. For example, one of the options is to abandon the “outdated” formats, give only WOFF and WOFF2, and if the client has an old browser, the page will be displayed in the system font, without downloading unnecessary files.
In the Google Fonts library, fonts are optimized, there are minimal resources. So for your hosting, it is better to take files from this source.
Load optimization
Just placing the files on your server is not enough. You need to ensure that the fonts are loaded in advance and not after the CSS has been parsed and the CSSOM is generated. This is done via the preload prompt.
It should be borne in mind that in this case, the browser will download the resources without fail, regardless of whether it later needs them or not.
The last argument
So, the only argument in favor of Google Fonts was a fast and reliable cached content delivery network (CDN). Google owns points of presence with all major providers around the world.
Popular fonts like Open Sans and Roboto are used on many sites. The idea was that the user only needs to visit one such site – the resources are loaded once and stored in the browser cache so that when they visit another site, they will not be downloaded again.
But now it doesn’t work anymore. Since Chrome 86, which was released in October 2020, cross-site resources like fonts no longer share a common CDN due to the partitioned browser cache.
The Google blog explains the meaning of this feature, which is implemented to protect against cross-site tracking. That is, for privacy. Unfortunately, this meant sacrificing performance.
When requesting resources from a CDN, the corresponding resource URL (of the same font) was previously used as the cache key. Thus, if two different sites requested a picture or font from the same URL, then this resource was not downloaded twice.
For a long time, this mechanism worked well in terms of performance. However, recent ideas have appeared on how to exploit it to the detriment of people. It turned out that by the response of the browser, one can determine that the browser either 1) downloads the resource again, or 2) the resource is already in the cache. Accordingly, in a fairly advanced attack, one can understand which sites this browser has visited in the past. And the researchers have proven that the history of visited sites/pages can be used to identify the identity of the user with a high degree of reliability, even if the browser is running in incognito mode, JavaScript is blocked and cookies are deleted. That is, the history of visited pages is also a suitable option for fingerprinting.
In addition to fingerprinting, cross-site tracking becomes possible, that is, tracking users with a unique ID on all sites that participate in this system.
In such a situation, Google had no choice but to sacrifice performance – and prohibit shared caching of resources in the browser, including fonts.
The new implementation uses not only the resource URL as the cache key but the new Network Isolation Key composite parameter. It consists of three parts: the top-level domain, the domain of the current frame, and the resource URL.
Thus, when visiting a new site, the same font will be downloaded again from the same URL.
The split cache has been in Safari since 2013. The rest have pulled up just now:
- Chrome: since version 86 (October 2020)
- Safari: since 2013
- Firefox: planned to be implemented
- Edge: probably coming soon
- Opera: probably coming soon
- Brave: probably coming soon
- Vivaldi: probably coming soon
Following Chrome, the developers of Firefox are also planning to implement the shared cache, and then, with a high degree of probability, other browsers based on Chromium.
Thus, the browser will always download Google Fonts again for each site. The last argument for using a shared cache is no longer valid.
Comments