Best practices for fonts with respect to Core Web Vitals
1. Quick read
This article addresses recommended practices for font performance. Web fonts affect performance in a variety of ways:
Text rendering is delayed: Browsers often delay text rendering if a web font has not been loaded. In many cases, this causes First Contentful Paint to be delayed (FCP). In certain cases, this causes Largest Contentful Paint to be delayed (LCP).
Changes to the layout: The practice of switching fonts has the potential to create layout changes. When a web font and its fallback font take up different amounts of space on the page, this causes layout changes.
This article is divided into three sections: font loading, font delivery, and font rendering. Each section describes how that particular component of the font lifecycle works and provides recommended practices.
2. Font loading
Before delving into font loading best practices, it’s necessary to understand how
@font-face works and how it affects font loading.
The @font-face declaration is required when working with any web font. It defines the name that will be used to refer to the font and identifies the location of the matching font file, at a minimum.
@font-face {
font-family: “Open Sans”;
src: url(“/fonts/OpenSans-Regular-webfont.woff2”) format(“woff2”);
}
A frequent misperception is that when a @font-face declaration is encountered, a font is requested; however, this is not the case. The @font-face declaration does not initiate font download on its own. Instead, a font is downloaded only if it is referenced by styling on the page. As an example, consider the following:
@font-face {
font-family: “Open Sans”;
src: url(“/fonts/OpenSans-Regular-webfont.woff2”) format(“woff2”);
}
h1 {
font-family: “Open Sans”
}
In other words, in the above example, Open Sans would be downloaded only if the page had an <h1> element.
As a result, while considering font optimization, it’s critical to consider stylesheets with font files. Changing the contents or delivery of stylesheets can have a major influence on when fonts appear. Similarly, eliminating unnecessary CSS and splitting stylesheets helps minimize the number of fonts loaded by a page.
Best practices
Fonts are generally valuable resources since, without them, the user may be unable to view website content. As a result, best practices for font loading usually focus on ensuring that fonts are loaded as soon as possible. Fonts loaded from third-party sites should be handled with caution, as obtaining these font files necessitates separate connection setups.
If you’re not sure if your page’s fonts are being requested on time, look at the Timing tab in Chrome DevTools’ Network panel for more details.
a. Inline font declarations (To be written by the developer)
b. Preconnect to critical third-party origins
If your site loads fonts from a third-party site, you should utilize the
preconnect resource hint to create an early connection with the third-party origin. Resource suggestions should be put in the document’s.
c. Avoid using preload to load fonts
Using the
preload resource hint to load fonts should be avoided in general. Although
preload is quite efficient at making fonts discoverable early in the page load process, it depletes browser resources that could otherwise be used to load other resources.
In most cases, inlining font declarations and modifying stylesheets is a better solution. These changes are a step closer to resolving the underlying cause of late-discovered typefaces, rather than simply offering a workaround.
Furthermore, utilizing preload as a font-loading technique should be used with caution because it bypasses some of the browser’s built-in content negotiation mechanisms. preload, for example, disregards unicode-range declarations and should only be used to load a single font format if used wisely.
3. Font delivery
Quicker font delivery results in faster text rendering. Furthermore, if a font is provided early enough, it can assist to prevent layout changes caused by font swapping.
Best practices
a. Using self-hosted fonts
On paper, using a self-hosted font should provide superior speed because it eliminates the need for a third-party connection setup. In practice, however, the speed differences between these two choices are less clear: for example, the
Web Almanac discovered that sites using third-party fonts rendered quicker than fonts using first-party fonts.
If you’re thinking about utilizing self-hosted fonts, make sure your site is using a Content Delivery Network (CDN) and HTTP/2. It is far less probable that self-hosted fonts will perform better if these technologies are not used.
It is suggested that if you use a self-hosted font, you additionally apply some of the font file optimizations that third-party font suppliers normally offer automatically, such as font subsetting and WOFF2 compression. The amount of effort necessary to implement these optimizations will vary depending on the languages supported by your site. Be careful that optimizing fonts for
CJK languages might be extremely difficult.
WOFF2: WOFF2 is the most recent contemporary font, with the broadest browser compatibility and the greatest compression. WOFF2 compresses 30 percent better than WOFF since it employs Brotli.
b. Use fewer web fonts
The quickest font to deliver is one that was not requested in the first place. System fonts and variable fonts are two approaches to reducing the number of web fonts needed on your site.
A system typeface is the default font used by a user’s device’s user interface. System fonts are generally different depending on the operating system and version. The font does not need to be downloaded because it is already installed. System fonts are especially useful for body text.
To utilize the system font in your CSS, use the font-family system-ui
font-family: system-ui
The concept behind
variable fonts is that a single variable font can be used to replace numerous font files. Variable fonts function by defining a “default” font style and supplying “axes” for manipulating the font. A variable font with a
Weight axis, for example, might be used to implement lettering that would previously need different fonts for light, regular, bold, and extra bold.
Switching to variable fonts will not help everyone. Because variable fonts have several styles, their file sizes are generally greater than those of individual non-variable fonts that only contain one style. Sites that utilize (and need to employ) a range of font styles and weights will benefit the most from adopting variable fonts.
4. Font rendering
When a browser encounters a web font that has not yet loaded, it is confronted with a dilemma: should it delay rendering text until the web font has arrived? Should it, on the other hand, render the text in a fallback font until the web font arrives?
This situation is handled differently by various browsers. If the related web font does not load, Chromium-based and Firefox browsers will stop text rendering for up to 3 seconds; Safari will block text rendering forever.
The font-display property can be used to control this behavior. This decision can have serious consequences: font-display has the potential to affect LCP, FCP, and layout stability.
Best practices
a. Choose an appropriate font-display strategy
When the linked web font does not load,
font-display instructs the browser on how to proceed with text rendering. It is defined per font-face.
@font-face {
font-family: Roboto,
src: url(/fonts/roboto.woff) format(‘woff’),
font-display: swap;
}
Font-display can take one of five values:
Value
Block Period
Swap period
Auto
Varies by browser
Varies by browser
Block period:When the browser requests a web font, the block period begins. If the web font is not accessible during the block time, the font is displayed in an invisible fallback font, and the text is not visible to the user. If the font is not available at the end of the block period, the fallback font will be used.
Swap period:The exchange period follows the block period. The web font will be “swapped” in if it becomes available during the swap time.
Recommendation
Font-display techniques represent many viewpoints on the tradeoff between performance and aesthetics. These are the two techniques that will be most useful for the majority of sites:
If performance is a top priority:
Use font-display: optional. This is the most “performant” approach: text render is delayed for no more than 100ms, and no font-swap-related layout changes are guaranteed.
If displaying text in a web font is a top priority:
Use font-display: swap, but make sure the font is sent early enough to avoid a layout change.
Skip to content