Speed Web font options
This article describes several methods of using web fonts and how they affect pagespeed. In general the methods are listed from the theoretically fastest to slowest and provide the following information about each technique:
- Good things (pros)
- Bad things (cons)
- An illustration of how it works on network
- A typical implementation example
- A link to a version of this page that is actually using the technique
- Brief notes about the technique
The fastest webfont option is to not use a web font at all. Let's start there.
1. No web font at all
Good things:
- Works everywhere on every device
- No added complexity
- No pagespeed consequences whatsoever
Bad things
- Limited font options
- May look plain
- May look unprofessional
How it works on network
The browser receives the HTML/CSS from the server. No additional network steps.
Typical implementation
Use CSS font-family, choose web safe fonts in order of preferences. The browser will choose the font to display the webpage from that list.
Example page where this method is used
Version of this page using no webfonts for testing and example of method usage
Notes about this method
This method is the fastest, simplest and most universal way to display fonts. No matter what other font method you use, this is the default fallback method for older devices and browsers so it is worth noting what your pages look like when it is used.
2. Inline font into HTML
Good things:
- No added network call to get font
- No reliance on third parties
- No flash of unstyled text (FOUT)
- Use any font you want
Bad things
- Makes initial html file larger
- Puts font into critical rendering path
- Only fast if you are already inlining CSS into HTML
- Only fast if you have extraordinarilty small CSS
- Only a reasonable option if page is using no more than one font
- Not supported by older browsers (uses .woff font files )
- Font loaded on every page view
How it works on network
The browser recieves only HTML file from the server. No additional network steps. HTML is larger by about 10k in optimized situations.
Typical implementation
Base64 encoded font is added to the inlined CSS within the HTML file.
Example page where this method is used
This page you are reading is using this method and is the example file for this method.
Notes about this method
This site uses this method. It is not recommended by many people, and will only work well with extremely optimized and simple pages. This method should not be confused with inlining font into your external CSS (which is the next method described).
There are several good reasons not to use this method. The main one is caching. This method means your font is probably loading on every page view, which seems ridiculous to most people, but is faster is certain conditions. This method will almost certainly make your HTML file over 14k, which is also not recommended.
Why do I use it for this site? It is the fastest way for my site. This will not be true for other sites. I can pull it off because my CSS is so small that it is already inlined, my webpages will still look good if it doesn't work, my users overwhelmingly use mondern browsers, and because I have designed this site to only make one initial call from the ground up.
Most experts specifically, expressly, and rightfully will say this method is a bad idea. However, the pages where they say it is a bad idea load slower than mine do.
3. Inline font into external CSS
Good things:
- No added network call to get font
- No reliance on third parties
- No flash of unstyled text (FOUT)
- Use any font you want
- Cached well
Bad things
- Puts font into critical rendering path
- Increases size of CSS file
- Only a reasonable option if page is using no more than one font
- Not supported by older browsers (uses .woff font files )
How it works
The browser recieves the HTML and CSS from the server. No additional network steps. CSS file is larger by about 10k in optimized situations.
Example page where this method is used
Version of this page using inline css fonts for testing and example of method usage
Notes about this method
This method allows for fast and cachable font rendering. I would call it a great solution for pages that only use one font that are optimized for speed already. This method puts the font directly into the CSS that your page is already loading.
Inlining font into CSS is not a good option if you are using more than one font or more than one font weight. It is also not a good solution for pages that only use the font sparingly.
I consider this an advanced way to render fonts, and as such, I would suggest you explore other options before trying this one.
4. Self hosted fonts
Good things:
- Support for most browsers and devices
- No reliance on third parties
- Use several different fonts and weights
- Modern and well documented method
- Caches extremely well
Bad things
- Adds network requests
- Flash of unstyled text (FOUT)
This is the go to, recommend and safe way to serve your own web fonts. Lets the browser choose the ideal type of font file used based on the user browser or device. Simple to implement and documented well.
How it works
The browser recieves the HTML and CSS from the server. The browser finds path to required font. Browser requests font from server. Server delivers the font file.
Typical implementation
src: url('webfont.eot'); /* IE9 Compat Modes */
src: url('webfont.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
url('webfont.woff') format('woff'), /* Modern Browsers */
url('webfont.ttf') format('truetype'), /* Safari, Android, iOS */
url('webfont.svg#svgFontName') format('svg'); /* Legacy iOS */ }
CSS instructions provide the paths to different font files. The browser uses this to choose what font to download and then does so.
Example page where this method is used
Version of this page using self hosted external fonts for testing and example of method usage
5. Use of third party fonts
Widely used third party font solutions are Google fonts and Typepad
Good things:
- Simple to implement
- Free (no cost) options availible
- Many font and stylistic choices
Bad things
- Typically the slowest option
- Can significantly hurt pagespeed
- Flash of unstyled text (FOUT)
- Causes additional requests to load page
- May act as a single point of failure for your webpage
Third party fonts are often the slowest option to display webfonts. This is particularly true for mobile.
Third party fonts require that your webpage load the fonts from another server than your own. This can cause problems if the other server is not availible, and can even keep your webpage from showing up at all.
Third party fonts are extremely easy to use, often just a copy and paste of of one line of code. This is the main reason the are used so much.
When using thrid party web fonts my main reccomendation is to use as few fonts as possible, ideally just one font at one weight.
How it works
The browser recieves the page from your server. The page makes a request to a third party server. The third party delivers a css file to browser. The page makes new request to third party server. The third party server delivers the appropriate font.
Typical implementation
Third party provides a snippet of code like the one above. It is placed in the head of your html file.
Example page where this method is used
Version of this page using third party external fonts for testing and example of method usage
Choosing a web font method
Each way of delivering web fonts has pros and cons. My rating of each method by different criteria would be...
safest:
- Use no web font
- Self hosted fonts
- Third party fonts
- Inlined CSS fonts
- Inlined HTML fonts
simplicity:
- Use no web font
- Third party fonts
- Self hosted fonts
- Inlined CSS fonts
- Inlined HTML fonts
widest support:
- Use no web font
- Self hosted fonts
- Third party fonts
- Inlined CSS fonts
- Inlined HTML fonts
pagespeed:
- Use no web font
- Inlined HTML fonts
- Inlined CSS fonts
- Self hosted fonts
- Third party fonts
by Patrick Sexton
Home Page Speed Web font options