The Typekit Blog

Update: As of January 30th, we’ve now reached 5 billion font views per month, up from 4 billion per month less than three months ago.

A year ago, we gave our first close look at the numbers behind Typekit’s web font service; since then, web fonts have moved from an exciting frontier to the mainstream, with adoptions across a range of sites (both large and small) and continued, exceptional growth.

Today, Typekit delivers nearly 4 billion font views per month. What’s more, font views have consistently doubled every four months for the past two years: an amazing rate that shows enthusiasm for web fonts is in no danger of waning.

Font views have doubled every four months for the past two years, reaching over 4 billion views this November.

And this traffic is global: over 100 countries serve more than 1 million font views each month, from Australia to India, South Africa, Brazil, and nearly everywhere in between.

Web fonts are truly global, with traffic across 239 countries and territories.

Moreover, web fonts are not merely the province of blogs and designer portfolios. Typekit’s Enterprise Plans serve fonts to really massive sites, including The New York Times, Wired, Zynga, The New Yorker, Gawker, and more. Together these sites serve more than 2 billion fonts per month—just over half of our total traffic.

And we’re still growing: bigger sites (and more of them) are on the horizon, as web fonts move from nice-to-have to can’t-live-without. We’re honored to have come this far, and excited for what the future brings. Here’s to a great new year.

It’s been just two weeks since we released favorites on the Typekit website, but one thing is already clear: you have great taste. Here, in descending order, are the most popular fonts from the Typekit library, based on the number of people who have marked them as a favorite.

#1: Adelle

#2: Futura PT

#3: Museo Slab

#4: Proxima Nova

#5: Museo Sans

#6: FF Meta Serif

#7: Freight Sans

#8: FF Meta

#9: Chaparral

#10: FF Tisa

#11: Myriad

#12: Museo

#13: Raleway

#14: League Gothic

#15: FacitWeb

#16: Jubilat

#17: Skolar

#18: Nimbus Sans

#19: Minion

#20: Franklin Gothic URW

#21: Atrament

#22: Adobe Garamond

#23: Brandon Grotesque

#24: Omnes

#25: FF Dagny

Today we’re pleased to release an oft-requested feature: favorites. Log in to your Typekit account, and you’ll see two new additions: “heart” buttons on every font, and a new tab called “My Favorites.”

Click the heart icon to favorite a font.

Favorite fonts are collected in the “My favorites” tab.

Favorites can be filtered and browsed just like all the fonts on Typekit, so you can quickly find the font you need. And as we continue to add more and more fonts, we’re also committed to working on tools to help you navigate the library.

You’ll need a Typekit account to save favorite fonts, but signing up is free and takes only a few seconds. So get started today!

Update: We’ve added a favorites link on the font detail pages, too.

Typekit’s Communications Director, Mandy Brown, interviews Christopher Slye from the Adobe Type Team about the past, present, and bright future of web fonts.

Mandy Brown: Hi Christopher! Tell me about what you do at Adobe.

Christopher Slye: Hi Mandy. In the last couple years, I’ve handled all kinds of work related to fonts on the web. Most of my previous years at Adobe were spent doing font production, so I have a technical and design background which has helped me understand and explain some of the issues — internally and from customers — that make web fonts so complicated. Over the years here I’ve also been involved in various font licensing issues, and of course that’s a big part of the web fonts equation as well.

So, like a lot of people on the Type team here, my work covers a fairly wide spectrum of tasks. I meet with product groups around Adobe to understand and help with their font needs. I evaluate new technology. I am Adobe’s representative in the Web Fonts (WOFF) Working Group, and I try to stay involved with Adobe’s related Standards efforts. I often field questions about licensing. I write the occasional blog post and I help with type marketing by creating graphics and ads once in a while. And of course I’ve been coordinating our web fonts partnerships. I don’t really do font production these days, but every so often I get to help by answering a question or offering an opinion about something. A lot of us have been around here a while, and we all have some accumulated knowledge that often comes in handy.

MB: You’ve witnessed a lot of change — both from within Adobe, and external to it — regarding fonts over the years. How do you feel about where we’re headed? What has surprised you? What are you still hoping for?

CS: Well, I don’t know if the resurgence of interest in type and typography these days is truly unexpected, but the relative swiftness and force of it does surprise me. Many people have noticed by now that fonts on the web have caused a revival that is very much like what happened with desktop publishing in the late eighties. I was a young designer back then, and what I’m seeing today reminds me of how I felt when PostScript fonts emerged: the sudden availability of typographic variety and the technology to use it was thrilling. Everyone got on board, and it spawned a new generation of typophiles — the veteran type designers and other type professionals we have today. Now, it’s not that type is merely making a comeback — there’s a palpable typographic movement among web designers who are suddenly getting access to something they didn’t really have before.

So obviously I think that’s exciting! What I’m hoping for — as a designer, along with everyone else — is better integration of web fonts with the web and print workflow. It’s a problem everyone’s working on now, and the technical and legal barriers make it harder than it seems, but I know it will get better.

MB: You’ve worked closely with the Typekit team for over a year now. How has that collaboration affected your work?

CS: Probably in many little ways. Since Typekit is a shipping product, it has forced us to confront some practical realities about web fonts, such as choosing font formats and setting vertical metrics. Whereas we might have imagined a more ideal web font world, the Typekit team, from their hands-on experience, have given us many reminders about the limitations with all the browsers out there right now.

One thing it has certainly done is gotten me out of the office more, literally and figuratively. Anyone who works at a big company like Adobe can easily find they haven’t really left their office for several years! We can get our heads down on a big project and tune things out. One of Typekit’s strengths has always been its engagement with the type and design community, and that’s spilled over to its foundry partners — it brings us all a little closer together in a way. In addition to all the online efforts, Typekit has hosted all these events and gotten me mixed in with them and their users more than I might have been. Not only is that fun and interesting, but it has also given me something to bring back to the office. Everyone here has heard about web fonts and wants to understand them, and fielding those questions has kept me very busy. Aha, there’s your answer — the collaboration has made me very busy! [Laughing.]

So Typekit has been a great conduit to keep in touch with what’s happening out there, and now I’m much more involved with all kinds of different teams here at Adobe, and I can pass on what I’ve heard and learned. But the collaboration has also been such a personal pleasure. Everyone at Typekit is always available, very generous, and curious. It’s been a reminder that doing great work doesn’t have to be drudgery.

MB: Adobe has long had relationships with other foundries, but the Typekit acquisition brings new — and many independent — foundries into the fold. How do you see this benefiting them?

CS: I think they’ll have everything they’ve liked about being a Typekit partner; and on top of that they’ll be getting more exposure to all Adobe’s customers, and the opportunity to participate in the new features and functionality that are yet to come.

Since this is more about font integration than simply selling fonts, we’re aware that we are standing in between foundries and our customers more than we have previously been. What we really hope to do is give our users tools which make it easier to use type — seamlessly and consistently among our products — but we also want everyone to have the fonts they need. This means we hope to make things easy for any designer or foundry who wants to participate. The biggest benefit we can offer is the shortest line from them to everyone who is using Adobe products and services.

MB: And how do you feel about the future, now that Typekit and Adobe are under one roof? Where do you hope this takes us?

CS: I’ll bet my hopes are pretty much the same as everyone else’s. Around here I like to say that type is just about the closest thing we have to a common, indispensable element in nearly every Adobe product and service. It’s the most persuasive argument I can make for type’s importance today and in the future. New technologies and media have not really diminished its significance.

Typekit is coming in with a lot of concrete experience with web fonts, and a determination to do a lot more. The Adobe Creative Cloud presents many opportunities for type, and everyone at Adobe is curious to see what Typekit brings. I am already getting emails asking “When can I talk to the Typekit folks?” It won’t take long for everyone to get to know each other, and I know there are going to be some cool ideas coming out of those conversations. Adobe is full of incredibly smart, creative people — a huge accumulation of expertise spanning decades of technology — so we will have some tricks up our sleeve that will inspire the Typekit team, too. It’s going to be a lot of fun.

The bottom line is I want to see great, affordable fonts everywhere. I want font streaming to be seamless and comprehensive. Our customers have been asking for it, so we all know what we have to do.

Christopher Slye joined the Type Development group at Adobe Systems in 1997. Today, as Technical Product Manager for Type, he helps guide Adobe’s type-related technology and initiatives. You can follow the Adobe Type team at @adobetype.

Today, we’re excited to release the first of many improvements to the Typekit website. We set out to make it as fast as possible to browse thousands of fonts. Just a few clicks, in a few seconds, to get to what you want.

The new browsing interface.

To start, we completely revamped the tagging system, ditching the plethora of unorganized, and often confusing, tags, and replacing it with a much more robust system designed around font classifications (i.e., serif, monospaced, etc.) and properties (i.e., x-height, width, weight, etc.). This means the new tagging system is derived from the physical characteristics of the fonts themselves — a much more useful means for discovery.

Additionally, we’ve added two new categories of recommended fonts: headings and paragraphs. These categories are handpicked by Typekit’s staff and feature fonts that are both aesthetically and technically exceptional. (All of the paragraph fonts have been manually hinted, and many of the headline fonts are served with PostScript outlines.) If you’re looking for the best fonts in Typekit’s library, start here.

The look of the tags has also changed, trading text links for a visual presentation of each tag. This also aids in browsing fast, and it means you can successfully browse by font characteristics even if you are unfamiliar with the terminology. Helpful tips are tucked away for those looking for more information about the tags themselves.

A new visual design for the tags makes it easy to understand at a glance.

Helpful tips are just a click away.

We consulted with type designers and typographers on the new taxonomy, and our type team then reviewed and retagged every single font in the library. The result is a browsing experience that’s much more intuitive, and fast. Try it and see for yourself.

Under the hood, we’ve worked incredibly hard on performance, taking advantage of the capabilities of the latest browsers, while gracefully degrading in older ones. You can now see many more than nine fonts per page (an oft-heard request, and one we’re very happy to deliver on). In modern web browsers that support pushState (such as the latest versions of Chrome, Safari, and Firefox), we update the url as you browse, so you don’t have to wait for the entire page to reload. As you click around, the browser progressively loads only the necessary information. (In older browsers, we fall back to the standard behavior of links and reload the page each time.)

There’s a lot more to this new interface on the technical side. We’ll have more to share about the process of creating it in the coming weeks.

And there’s more coming down the line: better search, improved detail pages, favorites (at last!), and new ways to preview fonts — plus even more help finding the perfect font for your needs. Stay tuned!

Update: By popular request, we’ve added a size slider to the browsing pages, so you can now adjust the size of the fonts as you browse. Enjoy!

We’re proud to have been sponsors of Letter.2, the second Type Design Competition of the Association Typographique Internationale (ATypI). And we’re prouder still to see many fonts from Typekit’s library among the winners, including two designs from our resident type designer, Tim Ahrens.

Above, Lapture Italic; below, Herb, both designed by Tim Ahrens and among the winners of Letter.2.

Among the other winners are five fonts from Robert Slimbach, three of which are available on Typekit: Arno, Brioso, and Garamond Premier. Other winners include Jan Fromm, Jarno Lukarilla, Veronika Burian, Jean François Porchez, Gerard Unger, Alejandro Paul, and many more. Please join us in extending congratulations to all.

Update: The Typekit embed code is now relative to the protocol, so you no longer have to specify when the fonts should be served as SSL. Details are available in this blog post.

Until now, SSL support has only been available on Typekit’s Performance Plan and higher. But starting today, we’re making SSL support available to all plans — including the Free Plan.

Why the change? When we launched Typekit, SSL was primarily a requirement of ecommerce sites. Since then, the risks of insecure cookies have become clear, and SSL is now generally recommended for any site with a login: whether commerce is involved or not.

We’ve recently updated the Typekit website to use SSL at all times, and we want to make sure our customers are also able to do so without the burden of an additional fee. So today we’re making SSL available to everyone, regardless of your subscription level.

If you’re on the Free, Personal, or Portfolio Plan, you can now republish your kits to get SSL access. If you intend to use SSL, you’ll also need to update the embed code on your sites, from http:// to https://. (Users on the Performance Plan and higher already had SSL access, so there is no need for action on your part.)

If you have any questions about this change, please drop a line to support@typekit.com. We’ll get back to you right away.

Just a few moments ago, Adobe’s CTO Kevin Lynch took the stage at their annual MAX conference and explained the company’s Creative Cloud strategy. Part of that announcement is very big news for us: Typekit has been acquired by Adobe.

We are thrilled. There honestly is no better place for us to continue building our platform. But perhaps even more significantly, this represents a huge step forward in bringing fonts to the web.

Not very long ago, web fonts were a curious and controversial debate. When the four of us founded this company, nobody knew if it would even work. We set up shop in a former morgue, sketched out a plan, and nervously published our first blog post. The response was immediate and not completely positive, but we’d fired the starter’s pistol. The race was on.

It seems odd to look back not even three years with a sense of nostalgia, but the environment in which we build the web has changed so much in so little time. At the end of 2008, HTML5 and CSS3 were becoming both viable and popular. Firefox, Safari, and Chrome were leapfrogging each other with amazing new capabilities, including the long-neglected @font-face spec. On the server side, a similarly important shift was happening: processing and storage could be rented by the hour and scaled at will. The so-called “cloud” was forming.

That was where we started. We asked ourselves what would happen at the intersection between web design and cloud computing. We quickly realized we could do two really interesting things. First, by serving hosted fonts, we could provide compatibility to all browsers and devices — both old and still to come — using the latest, most up-to-date best practices. Designers using our platform would no longer have to track browser hacks and bulletproof syntax. They could focus instead on creativity and expression.

Second, we could innovate on the business side as well. We could sell fonts as a service, and use a subscription model to eliminate Byzantine licensing and usage issues. We gave designers all-you-can-eat access to a library of font families, shared revenue with our partners, and carefully cultivated our business as it began to grow.

And grow it did. Few sites used web fonts when we got started; today, new sites seldom launch without them. Typekit now serves nearly three billion fonts per month on over one million different sites, including some of the most recognized brands on the web. We host the iconic typefaces of the New York Times, Vanity Fair, and the New Yorker, among others. We’re forging new ground with web-native companies like Zynga, Twitter, and the Gawker Network. And we’re making web fonts available to as broad an audience as possible, offering integration with platforms like About.me, WordPress.com, Posterous, and Behance. And that just scratches the surface: our blog is full of examples of the most innovative typography on the web today — all powered by Typekit.

Of course, none of this would have been possible without an amazing collection of typefaces, created by the most talented type designers in the world. They have gone out on the proverbial limb with us as we’ve repeatedly tried new things. For a craft that traces its roots back 600 years, reinventing itself at internet speed is significant.

If you’re one of our customers, this announcement means things will only get better. Typekit will remain a standalone product, as well as become a vital part of Adobe’s Creative Cloud. Our team will stay together, and we’re excited to start working on even easier ways to integrate web fonts into your workflow.

From the start, our vision has been to make the web more beautiful, readable, and fast. Joining Adobe will give us the opportunity to do that at an even larger scale. This news doesn’t mean we’ve crossed the finish line. Actually, we’ve really only just completed the first lap. The race to improve the web will only get faster. I hope you’re enjoying the ride.

You can find out more about the announcement in Adobe’s press release.

Tim Brown, Typekit’s Type Manager, interviews Nicole Dotin, typeface designer and partner at Process Type Foundry, on being a generalist, the wild web of web fonts, the future of type design, and more.

Tim Brown: Hi Nicole. Introduce yourself!

Nicole Dotin: Well, I’m a typeface designer and part owner of the Process Type Foundry. Although I started designing type in 2006 after attending the University of Reading, I’m only now finishing my first typeface which is set to be released this year. Before that, I taught typography and web design at the university level, I’ve worked as a web and graphic designer, and I even designed and sewed clothing for dogs (really!).

TB: A woman of many talents. Why do you wake up each morning and work on type, rather than something else? What is it about type that holds your interest?

ND: Of course, I love words and language, and as a designer I’m drawn to shaping their form. But at heart, I identify more with being a generalist than a specialist. I’m really lucky to have fallen into running a business that combines a subject I’m passionate about with a role where I get to do and be a lot of different things during the day. So, my interest in type is as relevant to keeping me engaged in the profession as is feeding my generalist tendencies. Maybe the acquisition of all my varied skills makes slightly more sense now!

TB: I think we can all appreciate balance in our work lives. And the “generalist” approach is quite familiar among web folks. Designers and developers come from many different backgrounds, bringing much varied expertise to their work. If a Jill-of-all-trades wants to hone her typographic skills, where would you suggest she start?

ND: It’s really difficult to recommend a single or typical starting point because we’re all unique, with our own interests and learning styles. A small part of my dissertation research at Reading was to examine the paths contemporary type designers took to educate themselves in their field. Did they learn on the job? were they self-taught? did they go to university? etc. Although quite a few of them started out as graphic designers, often at university, they all made their way to type design in different ways and ended up practicing professionally. The best starting point is often the one you choose for yourself.

TB: Let’s talk about these beautiful type specimens at processtypefoundry.com. When you have a new typeface to announce, how do you decide which aspects to promote?

ND: Specimens are funny things because they balance two competing objectives. On the one hand, they’re very practical and try to show, in a relatively compact space, the range of weights, style variants, and special features of a family. This is pretty dry information, all and all. On the other hand, they’re pieces of marketing and have to show the face at its best, capture the imagination, and create desire.

So, when we choose which aspects of a face to promote, the practical side is extremely easy to satisfy — if the typeface has small caps, show the small caps. Creating desire, however, is obviously more complicated. Our approach has never been calculated in this respect, though. Certain elements get featured over others because they’re what made us excited about the typeface in the first place. You won’t get the hard sell at the Process Type Foundry because if we have to convince you, it’s most likely not the right choice of typeface for you to begin with.

TB: One of my favorite aspects of your web font specimens is the note on “Recommended Use” for each weight of every typeface. Tell me about that.

ND: We don’t normally give use recommendations for our fonts because designers are really good at figuring those out on their own. Web fonts are a special case, though. Fonts for print and the web both go through processes that make the final rendering or output of the font different. For example, printing a typeface on coated versus uncoated paper will give a different result — type on uncoated paper is a little softer around the edges than on coated. Same idea on the web: look at a website in both Firefox and Safari on a Mac simultaneously and you’ll notice the weight of the type appears slightly different between the two.

But in print, the environment is more controlled and better understood. You typically aren’t printing a single piece on both rough and smooth paper at the same time hoping they’ll match. The web, on the other hand, is kind of a mess when it comes to rendering type between all the different ways browsers and operating systems treat fonts, combined with the construction of the font itself to even the CSS used. Knowing the fonts will end up in a relatively harsh rendering environment, we want potential customers to have realistic expectations of how the fonts will perform, so we provide information on how we think they can best use them.

We sit down with each style in the family and determine the size where the rendering is stable. Sometimes, a font looks great spec’d at 12 pixels, but grim at 13, 14, and 15. If it looks good again at 16 and up, then that becomes the lowest recommended size. Of course, fonts still have use-limitations that have nothing to do with being on the web but become even more important to pay attention to in the web’s rougher rendering environment. A thin weight of a typeface, for example, set at a small size knocked out white on black is a challenge for print, but it’s even worse on the web. So, for some of our typefaces, particularly display fonts like Anchor or weights at the extremities like Capucine Black, the recommendations are partly about rendering but also about dispensing helpful typographic guidelines.

TB: The prospect of designing type for this young, rough, unpredictable medium, and working with web designers to get the best out of typefaces, seems both exhilarating and daunting. What’s your take on the future of web fonts?

ND: I must admit, the path to better typography in the digital realm isn’t entirely clear to me. What I am confident about, however, is that it will only get better if every stakeholder does his or her part to make it so. Even fonts designed specifically for screen environments, like Verdana and Georgia, still look unpleasant on certain OS and browser combinations. In my mind, these fonts are at about the height of the type design industry’s current capabilities designing for the screen. While their counters won’t fill in, their stem shapes will remain intact, and legibility will be high, they still won’t create a luscious reading experience in lesser rendering environments. So, the problem has to be attacked from all fronts — from the type designer, to web designers, browser makers, software developers, OS designers, creators of font production tools — everyone and anyone who has the desire and skill to improve our reading experience on screen.

For the type designer’s part, this presents an interesting challenge and conundrum. Typefaces can have long lives. Futura and Times New Roman are both roughly 80 years old, the Garamond model is hundreds of years old, and Helvetica is over 50 years old. Even a newer typeface like Proxima Sans (reworked to become Proxima Nova) was conceived in the very early 1990s. It’s almost 20 years old! So, how do you respond to the screen environment of today, knowing that in the future, all those constraints and limitations you designed around will most likely be completely irrelevant? Or, do you spend your valuable time making a technology-specific design knowing it probably has a short shelf life? These are tricky waters to navigate but add the pressure of designing a culturally relevant, useful, lasting typeface design into the mix? That is a more daunting prospect than tackling the screen by itself.

Nicole Dotin is typeface designer and partner of the Process Type Foundry.

Of the many questions we get at Typekit, perhaps the most frequent asks why we require JavaScript to serve fonts.

Typekit is based on the standard CSS @font-face property. But using fonts on the web is about more than just the code we use. Just like video or audio, fonts pose challenges when you need them to work consistently and reliably across the entire ecosystem of browsers and devices. Fonts can also take time to download, and — unlike other kinds of rich media — browsers don’t provide any built-in way to detect when a font has loaded or, more importantly, when it has failed to load. That’s important to know so designers can plan for and apply fallback styles when fonts are unavailable. If a web font fails to load and there’s no fallback, web pages designed around the font can look different, even ugly, and sophisticated web app interfaces can break entirely.

We want to make using web fonts fast, reliable, and — most of all — easy. So to help address some of these challenges we wrap all of our kits in a lightweight JavaScript library that we call Kit JS, which does three things (in this order):

• It identifies the user’s browser, using fast, accurate, client-side detection methods.
• It loads the correct @font-face rules for that browser by injecting a link to it into the DOM.
• Finally, it observes the browser as it loads the fonts themselves, firing font events to provide better control over fallbacks and to help prevent problems like the dreaded flash of unstyled text (or FOUT).

In this post, I’d like to give you a brief introduction to Kit JS, explaining why it’s there and how it works. Let’s get started by first recapping what it is we’re talking about when we talk about “kits.”

Anatomy of a kit

A “kit” is a package of fonts and stylesheets intended for use on a single website or project. After signing up for Typekit, the first thing we ask you to do is create your first (empty) kit, and copy its two-line JavaScript snippet into the <head> of your HTML document:

Each kit is easily installed by copying and pasting two lines of Javascript into the <head> of your document.

As I mentioned, a kit is comprised of fonts and stylesheets. Specifically, it consists of:

• Font files for each variation (i.e. weight or style) in your kit, such as Nimbus Sans Extended Light Italic, in every format we support: EOT (for Internet Explorer 8 or earlier), raw TrueType or PostScript fonts (for Safari, iOS, and Android), and WOFF (for everyone else).
• An @font-face stylesheet covering all of the variations in your kit, for each of the OS/browser combinations we support. For browsers that support it, we embed the actual raw font data directly in the CSS, which helps performance by reducing the number of external requests needed to render the page.
• The kit JS file itself, which ties everything together by handling the actual font loading process.

When you publish a kit, all of these items are copied from our library or generated from your kit settings and published as static files to our content delivery network (CDN). A CDN is a network of web servers placed in several regions around the world, each containing a local, cached copy of the kit so users in that region can download kits more quickly.

When a user visits a web page using Typekit fonts, their browser first loads and executes the kit JS file linked from the JavaScript embed code. Then, it detects the user’s browser, and, for IE users, whether or not the browser is in standards or quirks mode. Finally, it kicks off the browser’s default CSS font loading behavior and monitors the process as fonts load, firing font events at each stage along the way. Let’s look at each of these steps.

Fast, scalable browser detection

Because different browsers each support different font formats, it’s necessary for developers to perform some kind of content negotiation to give each browser only the fonts and CSS it can handle. For web fonts, this can be done in one of three ways: using just css, using server-side browser detection, or using client-side browser detection with JavaScript.

Using just CSS

The “bulletproof” @font-face technique uses one stylesheet to link to every available font format, but is written in such a way that each browser will only load the formats it can use. As Chris Coyier wrote back in 2009, “the whole reason that web standards exist is so that we don’t have to write specific code for specific environments.” The bulletproof method is viewed as a web standards-friendly compromise: while it does incorporate some browser-specific hacks, it saves you from having to write, and serve, a different stylesheet for each browser.

The biggest drawback to this method is that it can be brittle: the very same hacks that make it possible to target specific browsers using just CSS may stop working as the browser landscape changes, forcing developers to continually monitor and update their code for regressions that could prevent fonts from loading. This has already happened several times since 2009, and likely will continue to happen for as long as new browsers are being developed.

Using this method you also have less control over which browsers you’re targeting. In one sense this is a feature, not a bug. The bulletproof method isn’t about targeting specific browsers, but rather providing browsers with content in a variety of formats from which they can use whichever is most appropriate. However, when it comes to fonts, the file format is just one part of the story. As we’ve written in the past, every font file contains vector outlines in either TrueType or PostScript format. TrueType outlines are more broadly supported, but some fonts render dramatically better on certain platforms with PostScript outlines. The bulletproof method is effective at delivering fonts in the right file format, but it has no reliable way of delivering different outline formats. For that, you have to use browser detection.

Using server-side browser detection

As the name would imply, browser detection is a kind of content negotiation where different content is served to different users based on information about the browser software they’re using — such as its name, version number, and operating system. It’s frequently executed on a web server, by using the user agent string sent along with every request to identify the browser, then running a simple algorithm to identify and send back the appropriate content. For example, upon receiving a request from someone using Internet Explorer 8, a server set up for this kind of content negotiation would see IE8’s user agent string and decide to send back a stylesheet with fonts in EOT format.

All hosted web font services, including us, use some form of browser detection because it’s more reliable, especially for supporting legacy browsers whose requirements are unlikely to change.

Server-side browser detection has been done on the web for years — in fact, the ability to serve different content to different applications is one reason why the web even has user agent strings. But for our purposes it has several drawbacks, perhaps the biggest of which is that it’s relatively slow. Our font-serving network currently handles about 2,000 requests per second, and running an identifying algorithm on each one of those is very hard to do without affecting performance.

Any time a web browser requests content from a server there is always some delay — or latency — between the moment when a browser submits the request and when the server actually starts sending back a response (that is, the file your browser asked for). During that period browsers are just waiting, and users are left with either a half-rendered page or nothing at all. For web sites to feel fast, latency needs to be as small as possible.

This screenshot from Safari’s Web Inspector shows the effect of latency on page speed. The lighter-shaded segments on the left side of each bar represent latency — time the browser spent waiting for the server to respond to a request — while the darker segments are actual downloading time. The blue bar at the top is the web page itself. In this case, Safari spent 977ms just waiting for the page to begin loading before it could request, load, or display any content.

With regard to serving fonts, there are three main sources of latency:

• Waiting for requests to travel over the network. Servers that are further away will take longer to receive or respond to requests.
• Waiting for a server to perform any tasks it needs to perform before sending the response. This can include authentication, referrer checking, server-side browser detection, or setting up an encrypted connection for SSL-enabled sites.
• Waiting for other users’ requests to finish. If a server is under heavy load, new incoming requests can be put on hold until older requests have been processed.

If you can, imagine a web server as a coffee shop where none of the customers know what they want and the barista has to ask a bunch of questions to help them decide. That’s what server-side detection is like. Browsers request something very generic, like coffee.css, and it’s up to the server to figure out what kind of coffee they need. This is fine as long as the shop isn’t crowded. But when there’s a line, having to go through this negotiation process for every customer will slow things down and frustrate everyone.

Client-side browser detection in JavaScript

But if every customer in line can come in already knowing exactly what they want — not just coffee.css, but black-coffee-with-two-sugars.css — the line moves more quickly. Kit JS allows us to do just that by performing content negotiation on the client side — in the browser itself — which has a number of advantages, not the least of which is speed. Using JavaScript, we can ask each user’s device to identify itself before requesting fonts, then have it only request fonts it can use. Our servers spend less time serving each request, which frees them up to serve more requests quickly, so users can spend time interacting with pages instead of waiting in line for content.

The CSS-based “bulletproof” method also works on the client side, and can have the same speed and scalability advantages. But as I’ve explained, its brittleness makes it harder to work with over time, while JavaScript-based browser detection is more stable. Also, since each browser only receives fonts and styles it can read, there’s no risk of “cross-contamination”: an optimization or hack for one browser is unable to cause problems in another browser, something that can happen with the CSS-only “bulletproof” targeting. As a result, bugs can be traced and isolated to a particular browser faster and more easily.

Another benefit of moving complex logic into the client is CDN compatibility. Publishing kits to a CDN helps us combat latency by pushing kit data to local “edge” servers in various regions around the world. Because many CDN providers have minimal or no support for server-side browser detection, using JavaScript is the only way we can provide a high level of cross-browser support and also take advantage of a CDN’s speed and scale. As a result we’re able to scale our service more easily, and — as a side benefit — offer features for our enterprise customers like the ability to integrate Typekit with their existing CDNs.

Document mode targeting for IE users

Client-side detection is also more accurate. Using JavaScript, we can inspect the browser’s environment to cover scenarios where the standard user agent string is incomplete or misleading.

A great example of this is document mode targeting for newer versions of Internet Explorer. To maintain backward compatibility with older websites that may depend on rendering quirks specific to older versions of IE, newer IEs have the ability to switch into different “document modes” which mimic those older versions’ rendering behavior. In other words, if IE9 detects a web site that’s not compatible with its regular “standards” mode, it will enter a “quirks” mode where it will still identify itself as IE9 in its user agent string but behave as if it were IE7.

This is relevant because older versions of Internet Explorer have several quirks that directly impact font loading and rendering, such as the inability to recognize more than four variations at a time of a single @font-face family. Or worse: if you inadvertently send a WOFF file to IE9 in quirks mode, the font will fail to render at all. In order to best serve fonts to IE9 in quirks mode, we need to be able to detect it and enable features like variation-specific family names. But at the same time, we also want to be able to identify when IE9 is in standards mode, so users can take advantage of its better standards compliance and WOFF support.

The current document mode isn’t referenced anywhere in the IE9 user agent string. JavaScript is the only way to detect it, and by detecting it we can deliver the right fonts reliably to every IE9 user.

Font loading, with font events

Having figured out which fonts to ask for, it’s time for Kit JS to load those fonts. The process for this is pretty simple.

First, the JavaScript constructs a stylesheet URL for the current kit, browser, and OS using the kit ID and information gathered by the browser matcher. These URLs correspond to one of the CSS stylesheet files that were uploaded to our servers when you published your kit. The JS loader then constructs an HTML link tag referencing that URL, and inserts that tag into the web page immediately following the Typekit embed code. You can see the generated link tag for yourself on any site that uses Typekit by using Firebug or the Safari/Chrome Web Inspector to view the web page DOM after fonts have loaded:

<script type="text/javascript" src="http://use.typekit.com/XXXXXXX.js"></script>
<style type="text/css">
.tk-ff-meta-serif-web-pro{font-family:ff-meta-serif-web-pro,serif;}.tkff-dagny-web-pro{font-family:ff-dagny-web-pro,sans-serif;}
</style>
<link rel="stylesheet" href="http://use.typekit.com/k/XXXXXXX-b.css?ZZZZZZZ">

Here’s an example of the HTML markup our Kit JS inserts into a page that uses Typekit. “XXXXXXX” refers to the unique kit ID, while “ZZZZZZZ” is a cache identifier we use to uniquely identify different published versions of a kit. When you re-publish a kit, this value changes, prompting browsers to re-download the stylesheet.

At this point, your browser has requested and started to load the CSS stylesheet containing your @font-face declarations. The next step is to begin loading the fonts themselves, which ordinarily will happen after the stylesheet has finished loading, as soon as the browser tries to render text that’s been styled with a web font.

Browsers don’t provide any built-in method for detecting when fonts have been loaded or made active on the page, but it would be nice to have this information so we can adjust for differences in font metrics between fallback fonts and web fonts, or prevent an ugly flash of unstyled text. To help work around this limitation, every kit includes our open-source WebFont Loader JavaScript library, which monitors the loading of each individual font variation in your kit, firing font events to let you know how the loading process is going. It works a little bit like this:

• First, the loader fires the “loading” font event, to indicate the process has started. Each time an event is “fired,” the loader sets or changes a CSS class name on the <html> element corresponding to the name of event. So for the “loading” event, if you inspected your page in Firebug or the Safari/Chrome Web Inspector, you’d see the <html> tag has the class name wf-loading. You can also attach JavaScript callbacks to any font event, to be called when that event is fired.
• Next, the loader inserts an invisible HTML <span> element into the page for each font variation being loaded. Each <span> is styled with one font variation as well as a special fallback font stack, with metrics different enough from the web font that loading fonts will cause the span’s width to change. Our JavaScript observes the page and watches for this width change to occur, and when it does, the loader fires an “active” font event for that variation. It subsequently removes the span element from the page. If a font variation doesn’t load within five seconds, it’s marked as inactive and the appropriate font event is fired.
• Finally, once the loader has tested every variation in the kit, and as long as at least one variation has loaded, the “active” font event is fired for the whole kit. At this point the process is complete, and all fonts that have loaded should now be displayed on your page.

Wrapping up

Web fonts can be tricky things to work with, even beyond issues of browser support and compatibility, or dealing with fallbacks. Hosting font files and delivering them to browsers in a standards-compliant way is important, but it’s just one aspect of a bigger problem. For designers, now that browsers are capable of real typography, getting great fonts into the browser should be the easy part. The real work is in using those fonts to solve typographic problems and make beautiful web sites. The reason we wrap our kits in JavaScript isn’t about browser compatibility, scalability, or preventing the FOUT: it’s to provide a complete, consistent, reliable solution for working with web type — one that any web designer can add to their site with just two lines of code.