The performance cost of custom web fonts, and how to solve it

In the early days of web development (circa 1997), web design was limited to fonts that were available with the operating system, be that Windows, MacOS, or Linux. Couple that with limited crossover of font options between the operating systems, and most of the time, this resulted in all websites using four fonts: Arial, Helvetica, Verdana, and Times New Roman.

The year is 1997 and Microsoft releases Internet Explorer 4. Along with it, the first means for downloading custom fonts in a browser. The problem? A lack of industry standardisation resulted in near zero support from other browsers.

Whilst Internet Explorer 4 was the first browser to adopt custom fonts, it would be a long wait until 2011 where support for custom fonts was supported across the big four browsers; Internet Explorer, Chrome, Safari and Firefox.

Widespread support for custom fonts brought creative options that were simply not possible before in web development. From matching a brand’s font, to flourishes designed to entice and create interest, the options were endless. Whilst the benefits of custom fonts are evident to most, what wasn’t evident, measured, nor understood (for quite some time), were the impacts to UX, performance, and the environment.

The problem, though, was fonts could be quite large assets, some being several hundred kilobytes (this is still true today). Over the years, due to poor user experiences (caused by slow load times, or sometimes not loading at all), font loading strategies were developed to address symptoms, like Flash of Unstyled Text, and its various incarnations.

Before fonts have loaded on the left. After fonts have loaded on the right

As the speed of internet connections improved, less focus was placed upon optimising the amount of information transferred, and whilst that was shortsighted, it simply reflected the attitude of the time. When we now take into account that more and more devices are accessing the internet over a mobile connection, the importance of addressing the causes of issues, rather than masking the symptoms, becomes evident.

Custom web fonts are an essential part of most web design, but they come at a performance cost. This post looks at several methods for addressing both the causes and the symptoms.

Before we begin, I must mention font services

In the age of subscription services, it would be remiss of me to not talk about font hosting services. Fonts.com, Typekit, and Google Fonts all offer relatively pain free methods for embedding beautiful fonts in your website, but they do often have a negative impact on performance.

Embedded fonts from services are normally implemented with a JavaScript or CSS snippet that you place in your website code. These snippets then make requests to a third party, often for the font file. In this case, there is an extra connection required to be made to the third party that is not required when hosting the font file yourself. But this is the best case scenario when using font hosting services.

In most cases, when using a JavaScript snippet, the snippet will make several connections, often to verify that you have a valid licence to use the font. Eventually, the font file will be loaded, but not without introducing quite a lengthy delay to the font actually being loaded onto the site, ultimately resulting in a flash of unstyled text.

In addition to these performance issues, most font hosting services limit your ability to make manual optimisations, and as we shall see, there is huge potential to make your fonts more performant if you have full control.

Be smart in choosing custom fonts and weights

We believe that consistency and readability are vital to good design, and too many font changes can distract and ultimately confuse the reader. Make your choices carefully and consider how the typefaces you choose will be seen together.

Traditionally, long publications such as magazines and books can often support a greater variety of typefaces. Digital platforms however are best used with fewer typefaces. Be smart in choosing fonts that define you, your character and the impression you want to give to the user.

Custom fonts, as we know can easily add bloat to websites, so be smart in deciding only one or two weights. At Wholegrain, we love to use a beautiful, well crafted, easy to read font for the body, such as Inter UI or Karla; with title fonts we often allow ourselves to be more provocative and less restrained.

Convert fonts to the most efficient format

Arguably the easiest change that can be made, that has no downsides, is converting the font to the most modern and efficient format available in browsers, WOFF2. In short, lossless compression. During a talk Tom Greenwood and I gave at WordCamp Bristol this year titled “A study in green” (Video, Slides), we showed how in our case, we achieved a 60% reduction (298kb to 114kb) simply through loading a WOFF2 file over a TTF.

Using the web based tool fontsquirrel, and the basic setting (no subsetting of the font), we were able to achieve the following.

Format File Size Percentage of original file size
Original TTF 298kb 100%
WOFF 126kb 42%
WOFF2 77kb 25%

The results above were from tests on the Inter UI font, using the bold weight (used in our website). Whilst 298kb might seem a drop in the ocean when compared against the 2019 average page size just shy of 2MB, when compared against the full load of our home page of 200kb (fonts, images, etc), the balance shifts. The size of one incorrect format font file alone is time and a half our whole site!

The reduction in size is no magic trick, simply the result of paying attention and taking action. On MacOS, our tool of choice to generate font files is fontplop. Free, open source, well supported, and does the job to perfection. What more can you ask for? If web based tools are more your style, the webfont generator from fontsquirrel does the exact same job.

Subset fonts to only include characters needed

Now that we have carefully chosen our custom fonts and their respective weights and styles, we can discuss what we need from each of those fonts. Font files are normally very comprehensive, and what we mean by this, is that they contain characters for lots of languages. In most cases, these characters are never used.

Using a character map viewer, we are able to see the character map for Inter UI Bold. Coming with 2192 characters, with support for 39 languages, Inter UI Bold is a very comprehensive font file. But with comprehensiveness, comes size.

Format Characters Languages Size Percentage
Original TTF 2192 39 298kb 100%
Subset TTF 98 2 12kb 4%
Subset WOFF2 98 2 7kb 2.3%

Subsetting fonts is the process of removing characters from the font, with the objective of only keeping what we need when writing content on the site. In essence, lossy optimisation. After subsetting Inter UI Bold, and converting it to a WOFF2 file, we achieved a file of 7kb, 2.3% the size of the original TTF.

Once again, no magic trick, just clever optimisation to achieve the best result and reduce the impact on performance, UX and the environment. Our favourite tool for subsetting fonts is Font Subsetter from Everything Fonts.

Being lossy optimisation, it’s important to take care and make sure that there are no missing characters that you actually need on your website.

Deal with the symptoms: implement a font loading strategy

So far we have worked on fixing the causes of the problem, which is what we should always do! But that doesn’t mean it’s the only thing we should do. When using custom web fonts, the browser will always be burdened with downloading an extra asset, and in most cases, multiple assets. Fortunately, browsers are clever and don’t just download every font specified in the styling of the site, they check if the font is used on the page first.

Controlling the chaos

The main symptom we have to concern ourselves with when loading custom fonts, is what happens before the font file loads? And what happens when the font file does load? For a very long time there wasn’t a standards compliant way to control this exact behaviour. There were less than perfect methods of control with varying degrees of support, but arguably they introduced more complexity than was worth. Finally, in early 2018, we received widespread support for a standards compliant method, the font-display property.

The font-display property supports five different values, each describing a different method of behaviour for different scenarios. In short though, it allows fine control over whether a fallback font is used immediately, and whether or not after a period of time (and the custom font has loaded) what should happen. Font-display finally allowed us to control the chaos.

Improving the odds

For the most important custom web fonts, we can improve the chance of the font file being loaded within a short period of time by telling the browser to preload the font file. As mentioned earlier, browsers wait until they see that the font is required before loading it, but this means that it could take some time before the request is made, but with preloading, we instruct the browser to load it immediately.

Be careful though to only preload assets that are explicitly required for the page, otherwise we will be wasting network resources, resulting in a longer page load.

Bonus round: avoid the problems altogether

Arguably the most effective, but least relevant to the conversation of reducing the impact of custom web fonts, is simply to not use them at all. When crafting the design for your brand and website, it is important to weigh up the costs of each component, and web fonts are no different. If you find the cost outweighs the benefit, then the choice is simple, and you are in good company: Rights 4 Children, GitHub, Booking.com, Medium. All use system fonts, all performant, and all beautiful and engaging in their own way.

System fonts are not nearly as complicated as they used to be. Crafting the font stack to ensure the right system font is loaded into each device, operating system and browser – all a tedious, lengthy testing process – now have open source, supported libraries where the hard work is done.

You can have custom web fonts, without the downsides

Custom web fonts made creative expression with typography in a browser possible. No other feature has had as big an impact to design possibilities. In that sense, we should relish the opportunity. But that doesn’t mean we throw consideration to the wind. Here is a summary of the key things to consider when using custom web fonts:

  • Be smart, adding only what is needed to achieve that perfect design.
  • At a minimum, use a WOFF2 font file to get the smallest size as there are literally no downsides.
  • Subset your fonts to include only the characters that are required. This could be to remove all but a few characters (as a font file correctly prepared can be smaller than a graphic), or just limited to a specific language.
  • Implement a strategy for how typography behaves. Be it an all or nothing approach until the font is loaded or a carefully selected fallback.
  • Give the browser the best chance at getting fonts right by preloading required fonts.

By following the above steps, you can use custom web fonts to create beautiful web experiences without bloating and slowing down websites.

Get our latest articles about a positive web straight to your inbox

We promise no spam, just good content