Performance Comparison: Typekit vs. Cloud.typography
We just switched our typeface and webfont solution on optimizely.com, so I took this opportunity to compare the performance impact of our old service and our new service.
On optimizely.com, we just switched our typeface from Proxima Nova (via Typekit), to Gotham (via Hoefler & Frere-Jones Cloud.typography). We’ve used Gotham in Photoshop mocks for a long time now, but recently decided to make the switch on our site mostly because it just looks better. We’ve long known that Typekit can be a bottleneck to our page load, so I took this opportunity to compare the performance impact of each service.
Note: These are just some quick comparisons of the speeds based on my machine using optimizely.com. Your experience may vary.
To use Typekit, you must insert JS in the head of your page, like so:
It’s well known that script tags in the <head> of the document block page rendering. If the Typekit service is down, or slow, the page can take a significantly long time to render.
This script determines which fonts to serve to the user based on their OS and browser.
Based on a few pageloads on my Macbook Pro and looking through Chrome’s timeline, Typekit’s JS takes about 300ms to download and 900ms to download the actual fonts, for a total of about 1100ms. Additionally, the script sets a timeout fires until the fonts have loaded, consuming processing power (typically not an issue, but could potentially be significant on mobile). Finally, 410kb of fonts are downloaded (font size and download time both depends on the OS and browser).
To use Cloud.typography, you need to add a <link> tag in the <head> of your page, like so:
<link rel=“stylesheet” type=“text/css” href=“//Cloud.typography.com/1234567/123456/css/fonts.css”>
Unlike Typekit, Cloud.typography requires you to host the font files on your own servers (CDN, web server, etc.). Depending on your infrastructure, this could be a big advantage over Typekit. But Typekit also servers its fonts over a CDN, so this is unlikely to be much of a gamechanger, speed-wise.
When the page loads, one request is made to fonts.css. Their server then does some work to determine which CSS file to redirect to (based on OS and browser), and then sends back a response of 302 Moved Temporarily with the Location header set to the path of one of the CSS files you uploaded. Most fonts are encoded as data-uris in the stylesheets (unless you’re IE and need references to .eot files). This means there are 2 requests (for most browsers), and all the work of determining which fonts to return to the user is done on their servers (instead of on the user’s machine via JS with Typekit).
Based on a few pageloads in Chrome on my computer, the fonts took about 800ms to load (~200ms for fonts.css, and another 600ms for the CSS file with the actual fonts). The fonts are 251kb in Chrome, but are between 100 and 500kb depending on the OS and browser.
I also did some tests on webpagetest.org from various locations, and found in total the fonts take between 300ms (France and Russia) and 1000ms (Brazil and San Jose) to download (this includes the 302 response from fonts.css and downloading the CSS file from your servers). Unfortunately I don’t have this comparison data for Typekit.
On optimizely.com, Cloud.typography edges out Typekit for load times (about 800ms vs 1100ms on my computer, or about 27% faster). Part of this can be attributed to the obvious fact that the size of the fonts is smaller with Cloud.typography, which is largely because we’re serving fewer fonts to the user than we did with Typekit.
However, Typekit blocks rendering by having a <script> tag in the head of the document, whereas Cloud.typography uses a <link> tag that allows the page to continue rendering progressively.