Fantastic front end performance, part 3 – Big performance wins by optimizing fonts – A Node.js holiday season, part 8

This is episode 8, out of a total 12, in the A Node.JS Holiday Season series from Mozilla’s Identity team. Today we’re talking even more front end performance!

We reduced Persona’s font footprint 85%, from 300 KB to 45 KB, using font subsetting. This post outlines exactly how we implemented these performance improvements, and gives you tools to do the same.

Introducing connect-fonts

connect-fonts is a Connect font-management middleware that improves @font-face performance by serving locale-specific subsetted font files, significantly reducing downloaded font size. It also generates locale/browser-specific @font-face CSS, and manages the CORS header required by Firefox and IE 9+. Subsetted fonts are served from a font pack–a directory tree of font subsets, plus a simple JSON config file. Some common open-source fonts are available in pregenerated font packs on npm, and creating your own font packs is straightforward.

(Feeling lost? We’ve put together a few references to good @font-face resources on the web.)

Static vs dynamic font loading

When you are just serving one big font to all your users, there’s not much involved in getting web fonts set up:

  • generate @font-face CSS and insert into your existing CSS
  • generate the full family of web fonts from your TTF or OTF file, then put them someplace the web server can access
  • add CORS headers to your web server if fonts are served from a separate domain, as Firefox and IE9+ enforce the same origin policy with fonts

These steps are pretty easy; the awesome FontSquirrel generator can generate all the missing font files and the @font-face CSS declaration for you. You’ve still got to sit down with Nginx or Apache docs to figure out how to add the CORS header, but that’s not too tough.

If you want to take advantage of font subsetting to hugely improve performance, things become more complex. You’ll have font files for each supported locale, and will need to dynamically modify the @font-face CSS declaration to point at the right URL. CORS management is still needed. This is the problem connect-fonts solves.

Font subsetting: overview

By default, font files contain lots of characters: the Latin character set familiar to English speakers; accents and accented characters added to the Latin charset for languages like French and German; additional alphabets like Cyrillic or Greek. Some fonts also contain lots of funny symbols, particularly if they support Unicode ( anyone?). Some fonts additionally support East Asian languages. Font files contain all of this so that they can ably serve as many audiences as possible. All this flexibility leads to large file sizes; Microsoft Arial Unicode, which has characters for every language and symbol in Unicode 2.1, weighs in at an unbelievable 22 megabytes.

In contrast, a typical web page only needs a font to do one specific job: display the page’s content, usually in just one language, and usually without exotic symbols. By reducing the served font file to just the subset we need, we can shave off a ton of page weight.

Performance gains from font subsetting

Let’s compare the size of the localized font files vs the full file size for some common fonts and a few locales. Even if you just serve an English-language site, you can shave off a ton of bytes by serving an English subset.

Smaller fonts mean faster load time and a shorter wait for styled text to appear on screen. This is particularly important if you want to use @font-face on mobile; if your users happen to be on a 2G network, saving 50KB can speed up load time by 2-3 seconds. Another consideration: mobile caches are small, and subsetted fonts have a far better chance of staying in cache.

Open Sans regular, size of full font (default) and several subsets (KB):

Chart comparing file sizes of Open Sans subsets. Full font, 104 KB. Cyrillic, 59 KB. Latin, 29 KB. German, 22 KB. English, 20 KB. French, 24 KB.

Same fonts, gzipped (KB):

Chart comparing file sizes of Open Sans subsets when gzipped. Full font, 63 KB. Cyrillic, 36 KB. Latin, 19 KB. German, 14 KB. English, 13 KB. French, 15 KB.

Even after gzipping, you can reduce font size 80% by using the English subset of Open Sans (13 KB), instead of the full font (63 KB). Consider that this is the reduction for just one font file–most sites use several. The potential is huge!

Using connect-fonts, Mozilla Persona’s font footprint went from 300 KB to 45 KB, an 85% reduction. This equates to several seconds of download time on a typical 3G connection, and up to 10 seconds on a typical 2G connection.

Going further with optimizations

If you’re looking to tweak every last byte and HTTP request, connect-fonts can be configured to return generated CSS as a string instead of a separate file. Going even further, connect-fonts, by default, serves up the smallest possible @font-face declaration, omitting declarations for filetypes not accepted by a given browser.

Example: adding connect-fonts to an app

Suppose you’ve got a super simple express app that serves up the current time:

// app.js
const
ejs = require('ejs'),
express = require('express'),
fs = require('fs');

var app = express.createServer(),
  tpl = fs.readFileSync(__dirname, '/tpl.ejs', 'utf8');

app.get('/time', function(req, res) {
  var output = ejs.render(tpl, {
    currentTime: new Date()
  });
  res.send(output);
});

app.listen(8765, '127.0.0.1');

with a super simple template:

// tpl.ejs

the time is <%= currentTime %>.

Let’s walk through the process of adding connect-fonts to serve the Open Sans font, one of several ready-made font packs.

App changes

  1. Install via npm:

     $ npm install connect-fonts
     $ npm install connect-fonts-opensans
    
  2. Require the middleware:

     // app.js - updated to use connect-fonts
     const
     ejs = require('ejs'),
     express = require('express'),
     fs = require('fs'),
     // add requires:
     connect_fonts = require('connect-fonts'),
     opensans = require('connect-fonts-opensans');
    
     var app = express.createServer(),
       tpl = fs.readFileSync(__dirname, '/tpl.ejs', 'utf8');
    
  3. Initialize the middleware:

      // app.js continued
      // add this app.use call:
      app.use(connect_fonts.setup({
        fonts: [opensans],
        allow_origin: 'http://localhost:8765'
      })
    

    The arguments to connect_fonts.setup() include:

    • fonts: an array of fonts to enable,
    • allow_origin: the origin for which we serve fonts; connect-fonts uses this info to set the Access-Control-Allow-Origin header for browsers that need it (Firefox 3.5+, IE 9+)
    • ua (optional): a parameter listing the user-agents to which we’ll serve fonts. By default, connect-fonts uses UA sniffing to only serve browsers font formats they can parse, reducing CSS size. ua: 'all' overrides this to serve all fonts to all browsers.

  4. Inside your route, pass the user’s locale to the template:

     // app.js continued
     app.get('/time', function(req, res) {
       var output = ejs.render(tpl, {
         // pass the user's locale to the template
         userLocale: detectLocale(req),
         currentTime: new Date()
       });
       res.send(output);
     });
    
  5. Detect the user’s preferred language. Mozilla Persona uses i18n-abide, and locale is another swell option; both are available via npm. For the sake of keeping this example short, we’ll just grab the first two chars from the Accept-Language header:

     // oversimplified locale detection
     function detectLocale(req) {
       return req.headers['accept-language'].slice(0,2);
     }
    
     app.listen(8765, '127.0.0.1');
     // end of app.js
    

Template changes

Now we need to update the template. connect-fonts assumes routes are of the form

    /:locale/:font-list/fonts.css

for example,

    /fr/opensans-regular,opensans-italics/fonts.css

In our case, we’ll need to:

  1. add a stylesheet <link> to the template matching the route expected by connect-fonts:

     // tpl.ejs - updated to use connect-fonts
     
     
    
  2. Update the page style to use the new font, and we’re done!

     // tpl.ejs continued
     
     

    the time is <%= currentTime %>.

The CSS generated by connect-fonts is based on the user’s locale and browser. Here’s an example for the ‘en’ localized subset of Open Sans:

/* this is the output with the middleware's ua param set to 'all' */
@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 400;
  src: url('/fonts/en/opensans-regular.eot');
  src: local('Open Sans'),
       local('OpenSans'),
       url('/fonts/en/opensans-regular.eot#') format('embedded-opentype'),
       url('/fonts/en/opensans-regular.woff') format('woff'),
       url('/fonts/en/opensans-regular.ttf') format('truetype'),
       url('/fonts/en/opensans-regular.svg#Open Sans') format('svg');
}

If you don’t want to incur the cost of an extra HTTP request, you can use the connect_fonts.generate_css() method to return this CSS as a string, then insert it into your existing CSS files as part of a build/minification process.

That does it! Our little app is serving up stylish timestamps. This example code is available on github and npm if you want to play with it.

We’ve covered a pre-made font pack, but it’s easy to create your own font packs for paid fonts. There are instructions on the connect-fonts readme.

Wrapping up

Font subsetting can bring huge performance gains to sites that use web fonts; connect-fonts handles a lot of the complexity if you self-host fonts in an internationalized Connect app. If your site isn’t yet internationalized, you can still use connect-fonts to serve up your native subset, and it’ll still generate @font-face CSS and any necessary CORS headers for you, plus you’ll have a smooth upgrade path to internationalize later.

Future directions

Today, connect-fonts handles subsetting based on locale. What if it also stripped out font hinting for platforms that don’t need it (everything other than Windows)? What if it also optionally gzipped fonts and added far-future caching headers? There’s cool work yet to be done. If you’d like to contribute ideas or code, we’d love the help! Grab the source and dive in.

Previous articles in the series

This was part eight in a series with a total of 12 posts about Node.js. The previous ones are:

About Jared Hirsch

@6a68 hacks on Persona, tickles ivories, has sand in all his shoes.

More articles by Jared Hirsch…

About Robert Nyman [Editor emeritus]

Technical Evangelist & Editor of Mozilla Hacks. Gives talks & blogs about HTML5, JavaScript & the Open Web. Robert is a strong believer in HTML5 and the Open Web and has been working since 1999 with Front End development for the web - in Sweden and in New York City. He regularly also blogs at http://robertnyman.com and loves to travel and meet people.

More articles by Robert Nyman [Editor emeritus]…


4 comments

  1. Chris Lilley

    Do you subset kerning tables?

    Does this also remove glyphs that might be used by GSUB?

    Lastly, this assumes that users only speak one language and never read conent (even short quotes) in any language not covered by their ‘locale’?

    March 19th, 2013 at 19:02

    1. Jared Hirsch

      Hi Chris,

      Connect-fonts doesn’t generate subsets, it serves pre-subsetted fonts.

      So, you can customize fonts however you’d like, then turn those subsets into a *font pack* that connect-fonts can serve. It’s simple to do; there are instructions in the connect-fonts project readme on github.

      A font pack is basically a bunch of directories containing different subsets, plus a JSON config file that maps Accept-Language preferences to subsets. Connect-fonts intelligently goes down the list of languages in the Accept-Language header, and serves the best available match.

      As for the existing font packs, they were generated using the language subsetting features in the FontSquirrel generator, so you’d have to look there for specifics.

      March 20th, 2013 at 07:21

  2. Dan Milon

    Great post!

    Suppose you didn’t do this and served non-subsetted fonts, but also had far-future cache headers. Wouldn’t this be enough? The way I see it, this optimization covers the cold start period only. Am I missing something?

    March 20th, 2013 at 12:12

    1. Jared Hirsch

      Hey Dan!

      Yep, the gains here are for users with an unprimed cache.

      Mobile users have smaller caches and slower, possibly metered network connections, though, so arguably unprimed cache is a more significant factor there. (It’d be great to dig up some data to test that hypothesis.)

      An interesting question, in the primed cache case, is whether having a smaller font file shortens the FOUT time, simply because it’s less for the browser to parse. I imagine this is a second-order effect, but, again, would be great to spend some time investigating this across browsers.

      March 20th, 2013 at 15:14

Comments are closed for this article.