In the web we navigate today, in 2023, fonts have become almost as essential as images. It is rare to come across a site that does not use its own font sets, regardless of its activity.
However, let's be clear: this negatively impacts loading times. Let's look at the mechanisms that make using self-hosted fonts costly, and how it's possible to optimize the process to meet user expectations.
Fonts, the web's new form of expression
Fonts have become a form of expression in their own right in web design. They are used to convey a company's visual identity and help strengthen its brand image.
Through its serifs, kerning, or line spacing, each font reflects a site's values and informs users about its intentions. This is why a financial services company and a leisure company will not generally opt for the same typography.
Fonts are a key element of a company's visual communication strategy. While there is already a wide selection among the 1500 fonts hosted on Google Fonts, many brands turn to more premium catalogs, such as Typekit, or adopt fonts purchased directly from their designer. Even better, some design their own webfonts to align perfectly with their logo, like the host Kinsta, among others.
Combined with the near-infinite modifications made possible by CSS, webfonts can be used to create a visual environment consistent 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 advantages come at a cost that every user pays when visiting your site.
A direct and tangible impact on performance metrics
The impact of fonts on performance is greatly underestimated. Too many, poorly chosen, or unoptimized fonts can considerably penalize the User Experience and performance metrics, with Core Web Vitals at the forefront.
LCP heavily impacted
The explanation comes from the resource prioritization mechanism built into browsers: to be able to display text quickly, webfonts are called with a very high priority. Their download thus consumes critical bandwidth and competes with other key resources such as stylesheets, images, or… other webfonts!
The Largest Contentful Paint (LCP) is therefore very sensitive to the volume of font files called. Several very common "errors" directly impact the LCP, either because the font weight increases, or because their download is subject to latency:
- Too many: this refers not to the number of different webfonts but to the number of font files needed to display a page. Each weight variation (from 100 to 900) and each italic version that potentially goes with it constitutes a separate file (with the exception of variable fonts). It is crucial to limit the number of files to 4 or 5 maximum, across all fonts.
- Too heavy: font files can include a variable number of characters, called "glyphs". However, it is common to see sites loading files that include subsets like "Greek", "Russian" or even "Cyrilic" when they display text in French or English.
- Unsuitable format: with Woff and Woff2 formats, it is possible to support over 98% of browsers in use. These formats, designed specifically for webfonts, are thus self-sufficient and effectively replace older and/or specific formats like eot (Internet Explorer), svg (Safari), and ttf. Too many sites continue to use the latter, with a major impact on the weight of downloaded resources.
- Remote hosting: using fonts hosted on Google Fonts or Typekit CDNs generates significant latency. To download these resources, the browser must indeed connect to the remote server and perform a DNS resolution, a connection, and then an SSL negotiation. This represents an additional delay of 500 ms to one second.
- Query strings: to quickly download the necessary font files, the browser must be able to detect them as quickly as possible when pages initially load. However, very often, @font-face declarations are made within CSS files called from the pages, delaying their discovery by several hundred milliseconds.
High CLS risks
Beyond the issues inherent to font files themselves, webfonts can cause significant Layout Shifts. The font-display: swap behavior, which allows users to start reading text before font files are downloaded, can indeed lead to variations in space occupation.
Generally minor on text paragraphs, horizontal or vertical shifts can be more significant on heading elements: when a word moves to the next line on large text, this quickly represents several tens of pixels. The impact on User Experience is then problematic.
These movements are taken into account within the Core Web Vitals as "Cumulative Layout Shift," or CLS.
Is your site as fast as your visitors expect?
Effective optimization tools and techniques
As is often the case with web performance, some optimization techniques are a matter of common sense: if fonts impact loading times, their use should be reduced. Similarly, if there are lightweight formats specifically adapted for the web, they should simply be used. And if their remote hosting generates latency, they should simply be hosted locally (goodbye Google Fonts, then).
For many other issues, however, there are tools, sometimes quite technical, to reduce their impact. Here are the three we use daily.
Optimal subsetting of webfonts
Several tools can reduce the weight of font files that include unnecessary glyphs:
- Font Subsetter from everythingfonts.com: online and very easy to use, it is ideal for less technical and more hurried users.
- Glyphnager, based on fonttools, which offers many more possibilities but must be installed locally and configured via command line.
These different tools share a common point in their operation: you define what should be kept, not what should be deleted. To display texts in French or English, it will generally be enough to activate the two subsets "Basic Latin" and "Latin-1 Supplement".
This technique makes it possible to reduce the weight of font files by a factor of 2 to 7, depending on what was initially uploaded. The impact on LCP can therefore be significant.
Defining optimized font stacks
To avoid behaviors like those illustrated above on the Courrier International website, it is essential to define fallback fonts that are as visually close as possible to the final webfonts within the font stack.
A visually close safe font
The best practice is, first, to choose the most relevant "safe font" from the nine available. These are fonts available in all browsers, regardless of the operating system:
- Arial
- Verdana
- Tahoma
- Trebuchet MS
- Times New Roman
- Georgia
- Courier New
- Brush Script MT
- Impact
An optimized direct fallback font
Despite selecting a close system font, it is rare for the screen space occupied to be identical. The solution, to definitively eliminate any risk of Layout Shift when switching from one to the other, is to implement an optimized fallback font. This involves generating a virtual font, from a safe font, to make it even more visually similar.
The good news is that there is a tool offering optimal solutions generated via AI for all Google Fonts: Perfect-ish Font Fallback. For other fonts, you will have to roll up your sleeves by relying on an online tool like the one from Sreenspan.
In both cases, you will ultimately get 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 key font files
The third and final optimization we are sharing with you drastically reduces LCP on pages where it consists of text (title or paragraph), but also CLS for users with the fastest connections. It relies on the "Preload" Resource Hint, which forces the browser to download certain resources very early, even before they are discovered.
If you have read the above carefully, this is the most relevant solution for reducing latency related to request chains: instead of waiting for the browser to discover the font file it needs on its own, we serve it on a silver platter. Implementing preloads of this type is quite simple with locally hosted fonts.
Be careful, however: we only preload one file per weight variation, and only in its lightest and most modern version, ideally Woff2. Here is an example of HTML code to include in 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 website
Fonts can significantly affect your website's performance, but they can be optimized to minimize their impact. By following best practices and using the right tools, you can ensure your website is 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, we invite you to contact us.
