We’ve noticed a recent focus on web performance in blog posts, tweets, and support tickets, so we thought it would be a good time to revisit Typekit embed codes. There are two recommended ways to embed Typekit on your web page:

  • Basic embed code (default)
  • Advanced embed code

The embed codes can be found by launching the Kit Editor and selecting “Embed Code” in the upper right corner. The basic embed code is displayed by default; use the “Show advanced” link to switch to the asynchronous version.


The basic embed code is recommended for most customers. The advanced embed code is for people who wish make their sites more resilient by loading resources asynchronously. This also requires some extra work to avoid the Flash Of Unstyled Text (FOUT) by modifying your CSS.

Default versus Advanced embed code

The default embed code blocks rendering of the page until the kit JavaScript has finished loading. We recommend this method because it will immediately insert @font-face rules into your page through a stylesheet (which, depending on your browser, may contain embedded fonts.) If the browser detects a @font-face rule but the font file isn’t available yet, it hides the text by default. This allows you to easily embed fonts in your page while giving you basic control over the FOUT. Our global Content Distribution Network (CDN) ensures speedy delivery of the kit JavaScript and fonts, so the default embed code will work well for most users.

The benefit of the advanced embed code is that it won’t keep the page from rendering while the kit JavaScript is loading. The downside to this is that the browser can decide to start rendering your site before the fonts are available. Font events will not be available if the browser decides to start rendering the page before the kit JavaScript has loaded. This is also the reason we recommend putting the embed code in your head and not at the end of your body. This ensures the code is loaded asynchronously while still being able to control the FOUT.

Common misconceptions

It is important that you only pick one of these methods. Using both at the same time will degrade the performance of your website. If you are using other font services together with Typekit, we recommended you use the open source Web Font Loader library instead of the Typekit embed code.

There is also a common misunderstanding that if you wish to use JavaScript font events, you’ll need to load your kit using the Web Font Loader. In fact, the Typekit JavaScript includes its own version of the Web Font Loader code and gives you the same access to font events. The advantage of using the Web Font Loader over the basic or advanced embed code is that it allows you to load fonts from more than one font service at the same time.

Using Typekit with “optimising” server modules and CDNs

We’ve noticed an increased usage of “optimising” server modules and CDNs, such as PageSpeed, CloudFlare Optimizer and Yottaa Site Optimizer, that attempt to automatically load JavaScript asynchronously by rewriting your web pages and JavaScript on the fly. We recommend exempting the Typekit embed code from these CDNs and proxies, as they will usually make it more difficult to reliably control the FOUT. By trying to modify the page to load the kit JavaScript asynchronously, these changes actually delay the kit’s ability to set the wf-loading class, which means your page can start rendering without fonts and without font events to control the FOUT. You should exclude the kit JavaScript from automatic changes if you are concerned about the FOUT appearing on your pages.

If you have any questions about how to embed Typekit on your website, don’t hesitate to contact Typekit support at support@typekit.com.

Today’s guest post was written by Jordan Moore, a writer and web designer based in Northern Ireland.

Recently, I was working on a project where the font kit was starting to get rather heavy due to the number of fonts we had painstakingly chosen to reflect the voice and tone of the brand. The kit was weighing in at around 300–400kb, which was a massive handicap on our target page weight before we had even added a single piece of content.

This realisation forced me to rethink my approach to the typography in the project, especially for users on poor connections—who we generally assume to be mobile users. My next plan was to use web fonts only as typographical flourishes, and the default system fonts would provide a stable baseline for the bulk of the typography. Headings would be web fonts served from Typekit to retain the link with the brand identity.

This was before I discovered that relying on default system fonts in responsive design is a fool’s game.

Modern web design has, without a doubt, become more complex when compared to the environment in which we started out as web designers—particularly in regard to typography. Before the introduction of web fonts, and the added challenge of the varied device landscape we face today, we relied on a select few system fonts to either display common typefaces across different platforms, or to fall back to the nearest common font in the font stack. System fonts in the past were the foundation from which we built our typographic decisions, but today’s device landscape is a wildly diverse space and requires a more nuanced approach. Our desire to present a smooth, consistent aesthetic across devices must be balanced with the principles of responsive web design for an optimal user experience.

I learned through my own experience that a font stack based on system fonts is no longer as safe as it was before the mobile device boom. Where system fonts in the major mobile operating systems are concerned, there is barely any consistency at all. For example, the Android operating system only comes packaged with 4 system fonts — none of which appear on iOS or Windows Phone, and those two platforms only share a handful of fonts between themselves. In the process of creating a compatibility table of shared default fonts across these systems for my own reference, what I ended up with was actually more like an incompatibility table. There is no safe native typographic foundation on today’s web.

Fortunately, web fonts do provide consistent typography across major mobile and desktop operating systems, but they come with the caveat that good typography isn’t free in regard to page loading cost.

Web fonts are like any other asset when it comes to responsive design: they carry a variable weight that changes depending on the number of fonts you use. A heavier page weight results in a longer page load due to the time it takes the browser to download the assets, and as a maker for the web it makes sense to shoot for the lowest common denominator in terms of performance matters like page weight.

“Loading only the necessary” is a mantra for responsive designers. For responsive projects, we want to keep the page light in anticipation of the next user coming from one of any number of devices, and on a completely unpredictable connection speed.

If we think of web fonts as assets on the page—like images or any other asset—then we can use media queries to load different assets for different displays. For example, we can load high definition images for retina displays; why not do something similar for web fonts?

I applied this thinking to my own project by producing two separate font kits: a “full” font kit containing all the typographical styles I originally intended to use, and a “light” kit containing fewer fonts (and, consequently, weighing significantly less). I loaded the kits via JavaScript depending on the width of the user’s screen, with the value based on the smallest breakpoint. Smaller screens received the lighter kit and subsequently took less of a bandwidth hit; larger screens received the full kit, and enjoyed the complete spread of selected typographic styles.

I am loading the “full” kit when screens meet or exceed one of the larger breakpoints, on the assumption that such a screen is a larger device—like a laptop or desktop—and more likely to be on a faster internet connection than a smaller device. Many techniques in responsive web design require developing assumptions like this for the purposes of decision-making. It sounds like a lot of parameters, but this is how we work with other assets—such as images—in the meantime until other methods like the Network Information API become available to us to make more informed decisions. In this case, the decision resulted in a much more reasonable page loading experience, specifically for devices on poorer connections.

If multiple kits aren’t an option, then I would suggest revisiting your approach to typography based on responsive principles. Aim for the lowest common denominator serving only the necessary assets. Establish your font kit by adding fonts and families only when you need them—this works best when you are working in the browser with real content. By evaluating which font assets are necessary with a mobile-first mindset, you’ll be less inclined to bloat a font kit with unnecessary typographical assets that will lead to an underperforming page.

I have a real passion for responsive typography, specifically for mobile. These small, incredibly powerful little devices provide immediate intimacy, and what I love most about them is that their beautiful high density displays allow web fonts to really sing. From a typographic design context, responsive design allows us to have fine control over our typography, using media queries to create different typographic rules to address different screen properties where appropriate.

Responsive web design has allowed us as web designers to become more flexible and embrace the inherent fluidity of the web and the diversity of devices that access it. We don’t have to sacrifice beautiful typography for the sake of developing a page that performs smoothly across multiple devices; indeed, responsive design and typographic design go hand-in-hand.


Jordan Moore profile

Jordan Moore is a Web designer and front end developer from Bangor, Northern Ireland. He is a responsive web design enthusiast with a passion for typography and frequently tweets as @jordanmoore

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:


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:


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.

We’re constantly working behind the scenes to improve performance across our font network. Most of these changes are, by design, invisible to you or your visitors. But today we’re releasing some small but meaningful changes to our recommended embed code that will make font serving even better.

To benefit from these improvements, you need only update your sites to use the new embed code. Note that doing so is completely optional: all sites using the prior embed code will continue to work. But the new embed code offers a few performance improvements which we think you’ll appreciate.

Protocol relative URLs

Without further ado, here’s what the new embed code looks like:

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

The first change you’ll notice is that we’re now recommending “protocol-relative” URLs for our JavaScript link. Previously this was an absolute link, including the protocol (“http” or “https”); this caused headaches for sites with both secure and insecure sections.

The new link is relative to the protocol: if the page is being served over HTTP, then the JavaScript and fonts will load over HTTP; if the page is served over HTTPS, then the JavaScript and fonts will be, too. The new embed code works in all of our supported browsers, and is an easy way to ensure your fonts are always served over the best protocol for the current page.

New domain

The second change is that we’ve made all kits available at use.typekit.net in addition to use.typekit.com. These hostnames run on the same infrastructure and behave identically. The only difference is that the new domain does not have any cookies set on it, as recommended by both Google and Yahoo performance best practices.

Our font network has never set cookies or relied on cookies. However, use.typekit.com shares a domain name with our blog and website, both of which use cookies for functionality and analytics. If someone has recently visited typekit.com, and then visits a site with an embed code pointing to use.typekit.com, then extra cookies would be sent with any requests for fonts. By offering our fonts on a second domain name, we can avoid this unnecessary data being sent.

Official asynchronous embed code

Previously on this blog, Sean discussed a variety of approaches to loading Typekit fonts asynchronously. The upside of asynchronous loading is that, if a request for a kit is slow for any reason, it won’t block the rendering of the rest of the page. The downside is that it requires writing custom CSS to hide the flash of unstyled text that can occur while fonts are loading. That said, these patterns have been working very well for sites that need this capability, so we’re now including an option to generate the asynchronous embed code directly in the kit editor.

New advanced embed code in the kit editor

Select “advanced” to use the asynchronous embed code. You will need to write custom CSS to hide the flash of unstyled text.

Using the new embed code

You can find the new recommended embed code in the Kit Editor. There is no need to republish your kits to use the new embed code; simply copy and paste the new embed code into your sites.

As always, if you have any questions about this, please reach out to support@typekit.com and we’ll get back to you right away.