At Typekit, we’re always working on ways to serve web fonts more efficiently and to improve the performance of our service. To that end, we’re excited to announce some changes to our font serving infrastructure that have significantly improved the performance of all kits.

You don’t need to do anything to take advantage of these performance improvements; all existing kits should already be seeing the benefits. Read on to find out what has changed.

Long cache headers for font data

A kit is comprised of many different CSS files containing fonts for different browsers, and a single JavaScript file that determines which of those CSS files to add to the page. We’ve made some changes that have allowed us to dramatically increase the cache timeout on those CSS files from five minutes to one week.

The result of these longer cache times is that font data is loaded significantly faster on average. There are two reasons for this: first, a visitor who returns to your site is much more likely to load the fonts from her browser’s cache, rather than making a request to the network. Second, if the fonts are requested from the network, they are more likely to be available cached at an edge node in our content delivery network rather than requiring a round trip back to the origin server. In both cases, fonts load much faster.

New font serving infrastructure

So what changed about our font serving infrastructure that has allowed us to increase the cache times for these CSS files? To answer that question, we need to understand how kits were previously published, and the changes we’ve made recently.

Previously, a kit was published with its own individual CSS file for each browser. These CSS files have URLs that look like this:

http://use.typekit.net/k/abc1def-g.css

In this URL, abc1def is the Kit ID and g is an identifier for the type of fonts contained in the CSS file. When a Typekit user changed the fonts in her kit and republished, the font data in those CSS files would update, but the URL would stay the same. This meant that we had to keep cache times relatively short, so that a cached CSS file with the old fonts would quickly be replaced by the new one. It was a balancing act between speed of updates and the number of times a visitor’s browser had to check for new fonts.

Now, newly published and republished kits no longer use CSS files that are specific to the kit. Instead, the new CSS files have URLs like so:

http://use.typekit.net/c/3abb8a/myriad-pro:n4.NPV:F:2/d

These new URLs contain enough information to uniquely identify a CSS file that will always have the same content. If the font data changes in any way, the URL changes as well. Now when a Typekit user changes the fonts in her kit and republishes, the JavaScript is simply updated to load different font data from a new URL. Because the content at each of these unique URLs never changes, we can cache their content for a long time.

Improvements for older kits

We’ve also made the same performance improvements for existing kits that haven’t been republished of late. Since old kits will move to the new-style URLs as they are republished, we can safely increase the cache times on those old kits without interfering with development. All kits, regardless of when they were published, now have CSS files that will stay cached for one week.

Future performance work

We’re very pleased to launch these improvements, because we believe it will have a significant impact on performance for visitors to sites using Typekit. But we’re not finished. Going forward, we plan to increase the one week cache timeout even further. We’re also investigating ways to increase the cache timeout for the JavaScript files while improving publishing speed as well. Performance is important, and we’re going to keep looking for opportunities to serve fonts more efficiently and make your sites faster.

As always, if you have any questions about any of this, just drop a line to support@typekit.com.