The wide availability of web fonts has enabled sites to become typographical wonderlands, at the cost of increased page size and longer load times. Performance-focused developers already optimize their images and CSS; it makes sense that we should also optimize web fonts.

The good news is that doing is fairly easy: by creating your own custom font or supplying your web font hosting service with a simple variable value, you can load only the glyphs that you need for the text you have on the page, rather than the entire range of characters, numbers and symbols in the font, reducing page load times.

Font subsetting can be very effective, provided you keep two conditions in mind:

In order to use the most effective versions of this technique – loading a limited range of characters from the font – you should be certain that text rendered in that font will not change substantially in the future, as glyphs that aren’t explicitly loaded won’t display correctly.

If you are self-hosting the web font, you should ensure that non-WOFF fonts are gzipped first, which will save an average of 40 ~ 70% on file size, before turning your attention to gaining advantages from subsetting.

Subsetting Google Fonts

The most popular web font hosting provider has a number of options for subsets. The first is already built-in:
Default character set selection in Google fonts

By default, sites will download only the Latin character subset (uppercase and lowercase A – Z, numerals, and punctuation). The “extended” Latin character subset option should contain the additional characters used in other European languages: accented characters, umlauts, and the like, but the quality and extent of these characters as delivered by Google is often limited: you may, in some situations, want to host the font yourself to gain access to the complete character set.

This technique is perfect for webfonts used to render logos or set headlines, where the characters used will always be known in advance. Note that you can start to get into trouble if your text contains characters that are outside the stated range:

Result of text using a greater range of characters than a subset request

You can see that the “F”. “r”, “n” and “d” characters do not render correctly, as they weren’t specified in our original request.

If you want to go the completely opposite direction (and get a far larger file as a result) you can direct Google to provide the complete font, including kerning, ligatures and OpenType data, by requesting subset=all:

http://fonts.googleapis.com/css?family=Open+Sans&subset=all

Subsetting Typekit Fonts

It’s also possible to subset Typekit fonts, albeit in a more limited fashion: currently the feature is in beta, limited to users who opt into Typekit’s Early Access program, with subsetting restricted to language glyphs.

Most other font hosting services, such as fonts.com, offer variations of this technique; you should consult their documentation to find out more.

Subsetting Self-Hosted Web Fonts

You can also subset fonts from your own server by creating a custom font that contains only the glyphs you want.

It’s often (and understandably) assumed that the CSS unicode-range property subsets fonts. This is only partially true: under Unicode-range the entire font is still loaded, but only the characters in a set range are actually used. As such, it’s not a webfont optimization technique of the kind we’re discussing here, and doesn’t save on download time.

If you’re only using a few characters from a font, it may be worthwhile base-64 encoding the result, saving yourself a HTTP request; rendering the unique glyphs in SVG would also be an option.

Conclusion

Subsetting your fonts can be an extremely powerful and useful tool, but needs to be carefully considered and planned for. The demands of designers, content providers and translators should all be considered when choosing what text range to use in a font subset.