Posted on Aug 15, 2013 by Jeff Zych

Performance comparison of serving fonts through Typekit vs Cloud.typography

On optimizely.com, we just switched our typeface from Proxima Nova (via Typekit), to Gotham (via Hoefler & Frere-Jones Cloud.typography). Gotham has long been what we used in Photoshop mocks, but we made the switch 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.

Typekit

To use Typekit, you must insert JS in the head of your page, like so:

<script type="text/javascript" src="//use.typekit.net/abc1def.js"></script>
<script type="text/javascript">try{Typekit.load();}catch(e){}</script>

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).

Cloud.typography

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.

Takeaways

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.

Additionally, Typekit taxes the user’s machine by executing Javascript to determine which fonts to load, whereas Cloud.typography does this on their servers. Although the JS is pretty minimal, it could impact older or more resource-constrained machines. Personally, I like that Cloud.typography moved this logic off of users’ machines and onto their servers.

Conclusion

In the end, both services are solid and the speed difference is minimal. I like Cloud.typography’s approach of only having a link to a CSS file instead of executing javascript, and the ability to host files yourself is nice. But which service you choose should ultimately come down to whichever fonts you like more.

Posted on Aug 2, 2013 by Jeff Zych

Everyone’s Reading This: Increase Conversions With Social Proof

Looking for a way to get users to engage with your product or service? Just tell them everyone else is doing it. Although we like to think of ourselves as independent beings who make our own decisions, studies show that touting popularity and ubiquity is a very effective form of persuasion.

This is known as social proof.

Generally, we don’t like to stand out from the crowd. Our lizard brains tell us it’s dangerous to deviate from the norm. In prehistoric times, deviating from the group meant getting attacked by predators. Predators are not much of a concern anymore, but studies show that sticking with the norm still persists and affects us in other ways. For example, one study tested the effectiveness of wording in persuading people to use less electricity. Four different placards were placed on the doors of residents, which informed them:

They could save $54 a month on their utility bill.
They could prevent the release of 262 pounds of greenhouse gases per month.
It’s the socially responsible thing to do.
77% of their neighbors already used fans instead of air conditioning, a decision described as “your community’s popular choice!”

The last group reduced energy consumption by 10% — the highest of any group. This means it was more effective than saving money, espousing benefits, or explaining it’s the “right” or “moral” thing to do.

You can use this same phenomenon to increase conversions on your site through A/B testing, whether that’s signing up for a service, donating money, or using a product feature.

Spillnow.com ran a test that demonstrates this phenomenon well. The site is a place for people to spill their guts on anything bothering them, and other users can respond with advice and encouragement. However, they had an issue with too many people venting and not enough users responding. In order to increase responders, they added this text to the “spill” form: “50% of people go on to be responders.” This simple piece of text increased the number of users who respond to other people’s spills by 27% (from 48% to 61%).

Another great example is Basecamp’s homepage, which has multiple types of social proof.

Screenshot of Basecamp's homepage

At the top of the page they say, “Last week 7,389 companies signed up for Basecamp to manage their projects. Today it’s your turn.” The main content features a woman saying she uses Basecamp (the picture also has the added benefits of making the statement more believable and trustworthy). And at the bottom, they say, “97% of customers recommend Basecamp. Find out why →”. These are all great ways to demonstrate that lots of people use your service and increase clickthrough.

And this is just the tip of the iceberg — there are many ways social proof can be used across your site. These are all quick, simple changes that can be added to just about any page using our A/B testing tool, without requiring design or engineering resources. If you’re looking for a way to get users to click your call to action, use a product feature, or engage with your site, then social proof is a great way to boost conversions.

Jeff Zych