Best practices for fonts with respect to Core Web Vitals

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.

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

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.

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-display can take one of five values:

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.

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.