Web fonts, how to optimize them to improve performances
We are back to talk about technical SEO and, more in general, about suggestions to enhance the site’s performances and particularly speed: today our focus is a spot on web fonts, a factor that risks to be overlooked and that instead has a heavy impact not only on loading time, but also on usability and readability of contents.
What are web fonts
Web fonts are typographical characters external to the default ones, that every site can decide to add from external libraries (such as Google Fonts) to variate page settings. The system’s fonts are basic, have no impact whatsoever on pages’ loading speed and are compatible with the largest number of browsers, operative systems and softwares ( infact, they are also called web-safe fonts), while web fonts are far more complex.
Google’s definition of web font
To keep tracks through this complex topic we rely on Google’s Ilya Grigorik, that created a clear complete and structured guide to web fonts’ optimization. Let’s start from the definition, then: “a web font is a collection of glyphs, each one representing a vectorial form that describes a letter or symbol”.
Here also lies a secondary but very important info: characters are different and have similarly different weights, because the size of every particular file font are determined by “the complexity of the vectorial paths of each glyph” and by “the total number of glyphs”.
Every font family consists in a series of stylistic variations (to normal writing, the bold highlighting or the cursive one) and different thickness to each style; subsequentially, each style could include very differently-shaped glyphs, that – for instance – involve different spacings, sizes or shapes.
The Googler quotes specifically the OpenSans example, one of the most popular fonts out there, that “contains 897 glyphs, including latin, greek and cyrillic characters”.
How to choose a web font
To effectively assess which web font to choose, then, we have to gather every useful info and also consider the supported sets of characters, fundamental aspect if we own a multilingual site: “to locate a page’s contents in more than one language, you should use a kind of font that would be able to grant a cohesive look and experience to users”, suggests Google.
Even in this case we have a practical example: Google’s Noto family font aims to support every single language in the world, but the total size of the pack – including all languages – “amounts to a ZIP file of more than 130 MB total”.
The importance of web fonts and typography
If they are so hard to manage, why choose to install custom web fonts? Again, Google answers: “Web fonts are pivotal to obtain a good design, user experience and optimal performances”, and that really is something, we would say.
These characters represent the real core of typography, a.k.a the pages and site’s graphic setting, that is a fundamental aspect for design, branding, readability and accessibility: typography must be adapted to site’s contents, must respect its tone and voice, be legible and functional, capable to adapt to context and to give the user enough attention.
And even what apparently is just a detail could make a difference: “web fonts allow to gain all of this and more”, says Grigorik. With this system “text is selectable, researchable, zoomable and high-DPI compatible, providing a coherent and concise rendering, with a multiple and scalable resolution easily adaptable to every kind of format, size or monitor resolution”.
How to optimize web fonts
Google’s guide reassure us on one further aspect: “on the contrary of one’s belief, using a web font does not necessarily delay the page’s rendering nor has a negative impact on any other performance”. This means that is safely possible to integrate web fonts on our site, with all the right optimizations, and actually benefit from their potential.
Do not be afraid to use web fonts, but put extra care in reducing error chances: “a thoughtless application could cause avoidable delays and excessively heavy downloads”, and that is why “in order to use web fonts you need to carefully plan it so that typography would not undermine performances”.
Interventions to reduce rendering problems
The final goal of every technical work is to “help the browser” improving “both the fonts and the way they are retrieved and used inside our pages”, and that is a critical phase in the whole performance strategy. Asw we were saying, each font represents an additional resource and in some cases they could end blocking the text’s rendering, ma when we work under optimized circumstances, setting a reasoned loading and page application strategy, is it actually possible to reduce total sizes and enhance rendering times.
Five pieces of advice on web font optimization
Google’s guide highlights 5 kinds of optimization on a site’s typographical characters, here is a checklist:
- Verify and limit your font’s usage. First suggestion is pretty simple and just an invitation on not over-using fonts on your pages while reducing the number of variations used for each character. This will allow you to provide your users a quick and consistent experience.
- Group your fonts in subsets. Let’s get technical: “many fonts can be grouped in subsets or multiple unicode-range, so to only use glyphs specifically requested by a page”, and generally a best practice would suggest to create script-based subset (such as latin, cyrillic and so on). Already from this precaution alone one can reduce file sizes and increment the resource’s download speed, but we still need to pay attention on fonts’ re-use parameters: for instance, explains Grigorik, it should be better “for each page not to download a different character set, just a leyered one”.
- Optimize the fonts’ format to each browser. Every font should be provided in WOFF2, WOFF, EOT and TTF formats, compressing with the help of GZIP the EOT and TTF formats, that are not naturally compressed.
- Specify the ideal policies of validation and caching. Fonts are rarely updated statistical resources: to guarantee an efficient re-use between different pages one needs to make the servers include a long-lasting max-age timestamp and a revalidation token.
- Use FontLoading API to optimize the critical rendering path. The last piece of advice is very important: the default lazy loading could lead to a delay in text rendering, that can only be avoided with Font Loading API for specific fonts, by indicating a customized timeout and rendering strategy based on the different page contents.
The real problem of the critical rendering path
We know for sure that page rendering can be a problematic factor for the website – and we also know that Google assignes a specific render budget to each indexed or indexed-to-be website – and fonts could make things overly-complicated: the browser needs to decide how to manage the process in order to provide the user a text with its customized font long before the character will actually appears on page.
The so-called critical rendering path begins when the browser requires the HTML document and translates the given data to build the page: it is fundamental that at this point the needed fonts would already be available, otherwise the machine will design both the layout and the other onscreen contents without entering any text pixel, keeping on waiting for external fonts.
Avoid invisible text during loadings
That is why we should avoid any flash of invisible text during loading time, and try to immediately show the content to the users through a default font, a.k.a the flash of unstyled text. A second Googler, Katie Hempenius, presents us two kind of ways to reach our goal: a simple though not universally browser-supported way and a second more complex but globally accepted one.
- Using font-display. First method include using an API to specify the characters’ visualization strategy: the swap option says to the browser that the text used by this font must be immediately shown with a system’s character. Whenever the customized one will finally be ready, the default character will be replaced.
As we were saying earlier, it is quite a simple approach but not one universally supported by every browser: for instance, Chrome and Firefox will respond the same way (hidden text up to 3 seconds; if not ready, resource to a system font until the specific one actually is and then swap characters), while Edge uses a system font up until the original one is ready and Safari conceals the text up until the character is ready.
- Wait for customized fonts’ loading time. Second strategy presents a more technical intervention, divided in three sub-steps:
- Do not use a customized character at the begin of the starting page’s loading, so that the browser can immediately show the text using a system font.
- Detect when your customized font is actually loaded (with a couple lines of JavaScript code, thanks to FontFaceObserver library).
- Update the page’s style in order to use your preferred character.
To implement these actions one must perform the CSS refactoring so to not use the custom font since the loading of the starting page, then add a script to the page that could detect when the font is ready and finally update the page’s style. To verify if the text is visible or not during webfont’s loading you could use Google’s Lighthouse tool.
