Webfonts allow us to bring emotion, personality and tone to our sites - which can make them more successful.
However, the task of choosing a webfont and implementing it on your site should be approached cautiously. Webfonts have the potential to impact aspects of your sites such as accessibility and page speed. For example:
- Certain webfonts may reduce the readability of the site, for example for people with dyslexia, or low vision.
- Webfonts can negatively impact page performance (additional http requests and increased page weight) especially in markets of strategic importance for Springer Nature like China. This will in turn impact usage numbers.
Our recommendation is that you prioritise a system font over a webfont. System fonts are extensively tested, and incur no performance penalty.
If a webfont is needed then close collaboration between user experience, accessibility, and web performance specialists must be sought to ensure the choice is satisfactory from typographic, accessibility, and performance perspectives.
As a Frontend Developer, it's your role to provide technical guidance and feedback, not to choose the font.
We do not prescribe a particular implementation. Each team should determine which implementation is best suited for them. However, before selecting an implementation a team should be mindful of our working practices such as:
- Graded Browser Support
- Is the implementation supported by all "enhanced" browsers? If not, is there a good justification for selecting it anyway?
- Does the implementation work in conjunction with the Cut The Mustard technique?
- Progressive Enhancement
- This is not meant to force you to choose a non-js implementation, but rather for you to ensure you consider what will happen for users in varying circumstances from the beginning.
- Our Performance Goals
- What impact will the implementation have on the page performance of your site?
Here are some quick suggestions for techniques that may prove useful:
- FOIT means flash of invisible text. Text on the page is hidden while webfonts are loading, so users will see a page with images but no text. We only show the text when webfonts are loaded.
- FOUT means flash of unstyled text. When webfonts are loading, we show users a system font. When the webfont gets loaded, we change the text back to the desired webfont.
- FOFT means flash of faux text. Only load the roman character set initially and load the others later for less page render blocking. "Faux" refers to the fact the browser fakes italics and bold before those character sets have loaded.
We believe that FOIT should be avoided as it is the worst experience for the user.
We highly recommend reading Zach Leat's comprehensive guide to get a good understanding of the different techniques available. There is also a good follow-up article that summarises Zach's findings.
WOFF2 has the superior compression. However, unfortunately it does not cover all of our Enhanced browsers at the time of writing. Therefore consider serving both formats.
font-display is useful and has the benefit of being a technique that does not require JavaScript and is easy and straight forward to implement.
We recommend reading this comprehensive analysis of font-display values when deciding which value is best for you.
Consider using FontFaceObserver instead of the CSS Font Loader API, as the latter does not have support for all our Enhanced browsers.
If you have to load a font the conventional way using a <link> then consider using the preload technique to ensure the font is requested as early on in the page load process as possible.
<link rel="preload" href="HardingText-Regular-Web.woff2" as="font" type="font/woff2" crossorigin>
Some webfonts prevent you from self hosting because of their licensing so check that first. But if you can, consider self hosting a font. This will potentially reduce the possible points of failure or poor page performance, and it will open up more options to you in terms of possible font loading implementations.