How to make sure web fonts don’t slow your site down (much)

This is a short introduction to web fonts and how you can minimise their impact on your site’s performance.

How it used to be

Long, long ago, most website text looked pretty much the same.

This is because we all had to use one of a very small number of fonts. For example, for sans-serif fonts, we’d often specify Arial or Helvetica. For serif fonts, it would be Times New Roman or Times. There were other “web safe” choices – but not many. The reason is that we were restricted to whatever the end user had installed on their system. So we’d ask for the font we wanted, as long as it was a reasonably common one, then specify a series of fall-backs, with “serif” or “sans-serif” (i.e. the default serif or sans-serif font on the user’s computer) as the last resort.

This meant we couldn’t guarantee how a web page would display. Carefully crafted designs could break if end users didn’t have the right fonts installed. It wasn’t great for brand consistency either. Style guides, meticulously followed for leaflets, brochures and ads, had to be torn up when it came to the web. Imagery or Flash could be used instead of text to get around the issue, but this was far from ideal.

The @font-face rule

Then CSS3 came along, introducing the @font-face rule. This meant that you could finally use fonts that were not installed on the visitor’s computer.

It was great news for design, branding and consistency, and generally offered a richer experience to people browsing the web.

However, it was a bit of a backward step for performance.

If you weren’t using a font that someone already had on their machine, they would have to download it from somewhere else. And more things to download generally means a slower website.

The effect manifests itself in one of two ways, depending on the browser and the chosen implementation (more on this later).

One possibility is that no text is displayed while the end user waits for the font to load. The other is that there is a “flash of unstyled text”, where the text is shown immediately, but initially using a fallback font. Once the font has loaded, the properly styled text can be shown.

Neither of these is ideal – one leaves visitors staring at a largely blank screen, while the other can be very distracting, especially if the chosen font is very different from the fallback.

How to get the best of both worlds

Unfortunately, there’s no getting around the performance impact of downloading extra fonts. However, there are steps you can take to minimise that impact.

Don’t load what you don’t need

When you load a font, quite often you’re loading a lot of characters that you’re never going to use. For example, you might not need glyphs, or characters in the Cyrillic or Greek alphabets. Selecting only the characters you really need is known as subsetting, and it can offer significant savings in terms of file size.

There are a couple of ways to do this.

One is to do it manually – literally to delete any unwanted characters from the font file and resave it – not a particularly simple or quick process and therefore not one you will want to do all that often (there are online services such as Font Squirrel that can help you with this). You also have to take into account any legal restrictions on editing the file.

It’s much easier if, like a lot of people, you use Google Web Fonts. In this case, you can simply add the subset you want to the end of the URL supplied. For example:

This is especially useful if you need only a few characters (perhaps the company name always has to appear in a particular font). Here, you just add “&text=” followed by the characters you need. For example, if your company were called “Mycompanyname”, you would add the following. Open+Sans&text=Mycompane

Note that you just need the characters you’re going to use (take out any repeats – it won’t do any harm if you include them, but you don’t need them).

Compress text files

You can also make significant savings by compressing text files on the server (often with something called Gzip, which can reduce the transmitted file size by up to around 70 per cent).

This technique can be used for text formats such as OTF or TTF, but you don’t need to do it for WOFF files, since these are already compressed.

Is it worth Base64 encoding fonts?

When someone visits a web page for the first time, their browser won’t start downloading any fonts until it discovers that it needs them. This sounds very reasonable, but it can delay the point at which text gets displayed.

One alternative is to embed your fonts in a style sheet using Base64 encoding (a way to turn a binary file into a chunk of text, often used to embed images into text files). This means the browser can start loading the fonts earlier. However, it also means it has to wait for them to finish loading before it can start to display anything to the end user. This is because the browser needs all the style sheets before it can start rendering the page.

Base64 encoding is therefore something to consider if you regard your fonts as absolutely critical to the page. Otherwise, you may be better off regarding fonts as a progressive enhancement – something to defer until after visitors have useful content in front of them.


Fortunately, while fonts can be a thorny issue, they’re chiefly a problem when someone visits your site for the first time. Hopefully, as they progress through your site, or come back for a later visit, they will have the font cached. If you’re using a popular, externally hosted font (from Google Web Fonts, for example), they might even have it cached before they get to your site. If you’re hosting your own font files, you should make sure you give them long cache lifetimes.

Taking control

Different browsers deal with fonts in different ways. For example, Safari won’t display text until the right font has loaded. Chrome and Firefox will wait a few seconds before giving up and using the fallback font. Internet Explorer will show the text immediately, using the fallback font, then re-render it once the font has loaded.

This behaviour is based on browsers’ best guesses about how important your fonts are to the user experience. Since your best guess is probably better than theirs, why not take control and deliver a uniform experience across browsers? Currently, the easiest way to do this is with JavaScript, but there is a proposal to build this kind of control into the CSS specification.

Do you really need that special font anyway?

When it first became possible to use web fonts, it seemed like everyone wanted to do it, just because they could. But it’s worth auditing your fonts to make sure that you’re not loading something that effectively adds no value.

Web fonts can make a website more engaging, interesting and brand-consistent – but there is always a performance cost. It’s therefore important to use them wisely!

This article was originally published on on 22 May 2015.

Leave a Reply

Your email address will not be published. Required fields are marked *