Improve Web Font Performance in Stencil Themes with Font-display
If you’ve been following the BigCommerce Developer Changelog, you may have caught some recent news. In May, Google announced that Google Fonts now supports font-display, and BigCommerce responded by adding font-display to the {{getFontsCollection}} Handlebars helper.
We wanted to follow that announcement with an in-depth post on font-display, because this little property can have a big impact on page load times and performance. Keep reading to learn more about how font-display works and what it means for BigCommerce theme developers.
What’s Changed?
Previously, you needed to self-host Google Fonts in order to take advantage of font-display. With this update, Google is now the first web font provider to make the font-display descriptor available.
{{getFontsCollection}} is a Stencil Handlebars helper that generates a link tag for loading Google web font selections. For example:
<link href=”https://fonts.googleapis.com/css?family=Karla:400|Montserrat:400" rel=”stylesheet”>
Working alongside the Google update, we’ve now added support for font-display to {{getFontsCollection}}, which means developers can automatically take advantage of performance improvements. The default mode for the helper is display:swap, but you can also configure the font-display mode to a custom setting.
With font-display, this is the new output for {{getFontsCollection}}:
<link href=”https://fonts.googleapis.com/css?family=Karla:400|Montserrat:400&display=swap" rel=”stylesheet”>
What Does Font-Display Do?
Let’s back up a bit. The reason font-display matters is that fonts are a render blocking resource — they halt the page load until the font has fully downloaded, and font files tend to be heavy resources. When a visitor lands on a site for the first time, the browser downloads and caches custom fonts and other assets. That speeds up load times for subsequent visits, but we still want to optimize for the initial download, and that’s where font-display comes in.
Before font-display, the default behavior was to load an invisible placeholder for elements that use a custom font while the font finished downloading. That resulted in a user experience sometimes referred to as a ‘flash of invisible text’ or FOIT, and it was also a drag on page performance.
The font-display property lets you define strategies for rendering elements that use a custom font, based on whether the font has fully downloaded or not. It’s basically a method of hyper-optimizing the experience for first time site visitors, before custom fonts have been cached.
For example, the font-display: swap mode initially displays the fallback font (e.g. San-serif), while the custom font loads. This means that the viewer isn’t left looking at a blank spot momentarily while the custom font finishes downloading. While this has a positive effect on user experience, it also affects performance metrics like Time to First Meaningful Paint and Time to Interactive, or the time it takes for the viewer to make sense of the content being rendered and interact with it.
The following font-display modes are available to specify how the browser should handle the rendering of elements that use custom fonts while the font completes the initial download:
- Swap — Displays fallback font while the custom font completes download, then swaps to custom font
- Auto — Browser uses its default method to load fonts, usually block method
- Block — Loads blank placeholder while custom font downloads (this is the same as the browser behavior before font-display existed)
- Fallback — First hides the text for about 100 ms, then uses fallback text if the custom font is still downloading
- Optional — Similar to fallback in that there’s a short block period, but no swap period follows. If the network connection is poor and the custom font hasn’t finished downloading, this mode allows the browser to stick with the fallback font and not display the custom font at all.
Font display is supported in all modern browsers, but isn’t supported in IE11. Check Can I Use for more information on browser coverage.
Which mode should I choose?
It depends — you’ll want to think about which elements use the custom font and what the user experience will be like if the fallback font displays. If you’re building a text-heavy site and all body text is in a custom font that’s fairly similar to the fallback, it’s probably preferable to use ‘swap’ or ‘fallback’. The user might see a flash of unstyled text, but that’s likely to be a better experience than no text — especially if that text takes up the majority of the real estate on the site.
‘Block’ tends to be the least performant option because it increases the time it takes for the user to make sense of the page content and interact with it. However, you might want to use ‘block’ in the case that you’re using a heavily styled font that has no acceptable fallback. In that situation, swap would be a jarring experience for users.
Font-Display and Stencil
If you don’t specify a parameter when using the {{getFontsCollection}} helper, swap is the property that will be applied by default. Optionally, you can supply the following additional parameters to apply a different display mode:
{{getFontsCollection 'swap'}}
{{getFontsCollection 'auto'}}
{{getFontsCollection 'block'}}
{{getFontsCollection 'fallback'}}
{{getFontsCollection 'optional'}}To disable font-display, you can use the ‘auto’ mode to return to the old default behavior.
Visit the Stencil developer documentation for our full Handlebars Helper reference.
Conclusion
Font-display hands control back to developers to decide how to render elements that use a custom web font during the initial download period, and it provides modes that can improve performance metrics like Time to First Meaningful Paint and Time to Interactive.
We’re excited that Google has updated web fonts to include the font-display property — and to include that support in the {{getFontCollection}} helper.
You can learn more about the font-display property at the links below, and be sure to follow the BigCommerce Developer Changelog and the @BigCommerceDevs twitter handle for the latest platform updates!
