In the web we browse today, in 2023, fonts have become almost as essential as images. It’s rare to come across a site that doesn’t use its own set of fonts, regardless of its activity.
And let’s face it: this has a negative impact on loading times. Let’s take a look at the mechanisms that make the use of externally hosted fonts costly, and how the process can be optimized to meet the expectations of web users.
Fonts, the web’s new form of expression
Fonts have become a fully-fledged form of expression in web design. They are used to convey a company’s visual identity and help reinforce its brand image.
Through its serif, kerning and line spacing, each typeface reflects a site’s values and informs users about its intent. That’s why a financial services company and a leisure company won’t generally use the same typefaces.
Fonts are a key element in a company’s visual communication strategy. While there’s already a wide choice among the 1,500 fonts hosted on Google Fonts, many brands are turning to more premium catalogs, such as Typekit, or adopting fonts purchased directly from their designer. Better still, some are designing their own webfonts to match their logo perfectly, as is the case with host Kinsta, among others.
Combined with the almost infinite number of modifications made possible by CSS, webfonts can be used to create a consistent visual environment with a site’s colors, images and other design elements. Drop shadows, reliefs and even animations make them an extremely powerful and versatile design element. Unfortunately, these undeniable assets come at a cost that every user pays when visiting your site.
A direct, tangible impact on performance metrics
The impact of fonts on performance is largely underestimated. Whether too numerous, poorly chosen or unoptimized, they can significantly affect User Experience and performance metrics, with Core Web Vitals leading the way.
LCP heavily impacted
The explanation lies in the resource prioritization mechanism built into browsers: to be able to display texts quickly, webfonts are called up with a very high priority. Downloading them therefore consumes critical bandwidth and competes with other key resources such as stylesheets, images or… other webfonts!
Largest Contentful Paint (LCP) is consequently very sensitive to the volume of font files called up. Several very common “errors” have a direct impact on LCP, either because the weight of fonts increases, or because their download is subject to latencies:
- Too many: we’re not talking about the number of different webfonts, but the number of font files required to display a page. Each font variation (from 100 to 900) and each potentially related italic version constitute a separate file (with the exception of variable fonts). It’s crucial to limit the number of files to a maximum of 4 or 5, all fonts included.
- Too heavy: font files can include a variable number of characters, known as “glyphs”. It’s not uncommon to see sites loading files that include subsets such as “Greek”, “Russian” or “Cyrilic”, even though they display texts in English or French.
- Inadequate format: Woff and Woff2 formats support over 98% of all browsers in use. These formats, designed specifically for webfonts, are self-sufficient and effectively replace older and/or specific formats such as eot (Internet Explorer), svg (Safari) and ttf. Too many sites persist in using the latter, with a major impact on the weight of downloaded resources.
- Remote hosting: using fonts hosted on Google Fonts or Typekit cdn generates significant latency. To download these resources, the browser has to connect to the remote server and perform a dns resolution, connection and SSL negotiation. This represents an additional delay ranging from 500 ms to one second.
- Query chains: to download the needed font files quickly, the browser must be able to detect them as quickly as possible on initial page load. However, @font-face declarations are often made within CSS files called from pages, delaying their discovery by several hundred milliseconds.
High risk of CLS
In addition to the problems inherent in font files themselves, webfonts can also be the source of significant Layout Shifts. The font-display: swap behavior, which allows users to start reading text before actual font files are downloaded, can lead to variations in the amount of space occupied on screen.
Generally minor on text paragraphs, horizontal or vertical shifts can be more significant on title elements: when a word moves to the next line on a large text, it quickly translates into several tens of pixels. The impact on User Experience is then quite problematic.
These movements are taken into account in Core Web Vitals as well as in the “Cumulative Layout Shift”, or CLS.
Effective optimization tools and techniques
As is often the case when it comes to web performance, some optimization techniques are just common sense: if fonts have an impact on loading times, their use should be reduced. Similarly, if there are lightweight formats specifically adapted to the web, simply use them. And if hosting them remotely generates latency, then simply host them locally (goodbye Google Fonts).
For many other issues, however, there are tools – some of them quite technical – to reduce the impact. Here are the three we work with on a daily basis.
Optimal webfont subsetting
Several tools can be used to reduce the size of font files that include superfluous glyphs:
- Font Subsetter from everythingfonts.com: online and very easy to use, it’s ideal for the least technical profiles and those in a hurry.
- Glyphnager, based on fonttools, offers many more possibilities, but must be installed locally and run from the command line.
These different tools share a common feature in their operation: you define what is to be retained, not what is to be deleted. To display texts in English or French, you’ll generally need to activate the two subsets “Basic Latin” and “Latin-1 Supplement”.
This technique can reduce the weight of font files by a factor of 2 up to 7, depending on what was initially loaded online. This can have a major impact on the LCP.
Defininition of optimized font-stacks
To avoid behaviors such as those illustrated above on the Courrier International website, it’s essential to define fallback fonts that are as close as possible visually to the final webfonts within the font-stack.
A visually close safe-font
The first step is to choose the most appropriate “safe font” from the nine available. These are fonts which can be used in all browsers, regardless of the operating system:
- Arial
- Verdana
- Tahoma
- Trebuchet MS
- Times New Roman
- Geogria
- Courrier New
- Brush Script MT
- Impact
An optimized direct fallback font
Despite the selection of a similar system font, the space occupied on the screen is rarely identical. The solution, to definitively eliminate any risk of Layout Shift when switching from one to the other, is to set up an optimized fallback font. This consists in generating a virtual font from a safe font, to make it even closer visually.
The good news is that there’s a tool that provides AI-generated optimal solutions for all Google Fonts: Perfect-ish Font Fallback. For other fonts, you’ll have to get your hands dirty with an online tool like Sreenspan.
In both cases, you will end up with CSS code that looks like this:
@font-face {
font-family: "Montserrat-fallback";
size-adjust: 113.38999999999997%;
ascent-override: 83%;
src: local("Arial");
}
body {
font-family: Montserrat, "Montserrat-fallback", Arial, sans-serif;
}Preloading the main police files
The third and final optimization we’re willing to share with you not only drastically reduces LCP on pages where it consists of text (title or paragraph), but also CLS for users with the fastest connections. It’s based on the Resource Hint “Preload”, which makes the browser download certain resources at a very early stage, even before they’re discovered.
If you’ve read the above correctly, this is the most appropriate solution for reducing the latency associated with request chains: instead of waiting for the browser to discover the font file it needs by itself, it’s served to it on a silver platter. Implementing preloads of this type is fairly straightforward with locally hosted fonts.
Be careful, however: only one file should be preloaded per weight variation, and only in its lightest, most modern version, ideally Woff2. Here’s an example of html code to integrate into the header:
<link rel="preload" as="font" href="https://agencewebperformance.fr/wp-content/themes/generateperf/fonts/inter-variable/inter-variable.woff2" crossorigin>A fast and responsive site
Fonts can significantly affect the performance of your website, but it is possible to optimize them to minimize their impact. By following best practices and using the right tools, you can ensure that your website will be fast and responsive for all users, regardless of the fonts you choose.
As part of our performance optimization services, we implement these best practices in addition to dozens of others. If you need professional support to improve your site’s performance, please do not hesitate to contact us.
