G-Type is a digital font foundry and experienced type design studio founded by Nick Cooke in 1999. The company has built a reputation for both its high quality retail font collection and the various custom projects undertaken for leading brands and organisations around the world. Time for a change: Typekit has become Adobe Fonts. Today we’re changing our name from Typekit to Adobe Fonts, with the goal of incorporating our service more fully into Creative Cloud and reaching the broader Adobe audience in new ways. That means we’ll be posting over on the Adobe blog network from here on out.

Update: We now offer an official asynchronous embed code through the Kit Editor, so you no longer have to create your own. Details are available in this blog post.

The standard Typekit embed code has many advantages. It’s simple, compact, very easy to implement, and automatically helps to prevent the flash of unstyled text (or FOUT). These advantages make it the right choice for the vast majority of sites.

The asynchronous loading patterns that we’ll discuss in this post provide a useful alternative in situations where you must eliminate any possibility that a problem loading the kit could interfere with loading the rest of the page. Asynchronous patterns are longer, more difficult to implement, and require extra work to avoid the FOUT. But these approaches ensure that your page won’t wait for the kit in the unlikely event that something goes wrong somewhere between the font network and the user.

In fact, we use the font events asynchronous pattern described below on the Typekit status blog to ensure that our users can reliably read about our system status, even during a font network outage or degradation.

Standard Typekit embed code

Before discussing asynchronous loading patterns, let’s take a detailed look at what happens when using the standard Typekit embed code. This will help to frame the differences between the standard embed code and asynchronous patterns.

When a web browser parses and renders a web page, a tag will block the rendering of elements and the execution of scripts further down the page. This is because web browsers use a single-threaded model when executing JavaScript. The script that’s executing could use document.write() to alter the page, or trigger a redirect to go to a different page entirely. Because the browser doesn’t know what executing the script will do, it waits until the script is done loading and executing before moving on. Modern browsers continue downloading other resources on the page while the script is executing, while older browsers put a hold on that too.

Typekit’s standard embed code is just a simple pair of tags. The first is an external tag that loads the kit JavaScript from our content delivery network (or CDN). The second tag is a piece of inline JavaScript that actually kicks off font loading using the kit.

This standard embed code takes advantage of the fact that tags block further rendering of the page to help prevent the FOUT. While the Typekit script is loading, rendering of the page is blocked, so text won’t start to render with fallback fonts. Once the script has finished loading and executing, the FOUT can be controlled with font events, as we’ve discussed in a previous post.

Normally, this works great, but the downside of this approach becomes apparent in the rare event that the Typekit script takes too long to load. What was once a desirable delay in rendering to hide the FOUT becomes a serious problem when the script takes longer than a few seconds to load. The page will fail to render as long as the request for the kit fails to return a response. We labor tirelessly to make sure that this never happens, working with our CDN partner to ensure that kits are delivered in a reliable and timely manner around the world. Unfortunately, it’s impossible to forsee and prevent every outage, network problem, and user configuration issue.

If this failure mode, however unlikely, is an unacceptable risk for your project, you should consider using one of the following asynchronous patterns instead. Asynchronous patterns don’t block rendering of the page while the fonts load, which means that the FOUT must be dealt with via other means.

Standard asynchronous pattern

This first pattern is the most basic. It’s based on patterns written about by web performance experts like Steve Souders and used in other JavaScript embed codes like Google Analytics.

This pattern uses a single inline tag to dynamically add a new script element to the page, which loads the kit without blocking further rendering. An event listener is attached that calls Typekit.load() once the script has finished loading.

How to use it:

• Place this snippet at the top of the so the download starts as soon as possible.
• Edit the highlighted config object and replace the default with your own Kit ID.
• You can add JavaScript font event callbacks to the config object.

Advantages:

• Loads the kit asynchronously (doesn’t block further page rendering while it loads).

Disadvantages:

• Adds more bytes to your html page than the standard Typekit embed code.
• Causes an initial FOUT in all browsers that can’t be controlled or hidden with font events.

Font events asynchronous pattern

When using the standard asynchronous pattern, the inability to hide the initial FOUT with font events while the kit JavaScript loads is a serious drawback that might be a dealbreaker. This next pattern builds on the standard pattern, but adds the ability to control the initial FOUT with font events.

This pattern uses the same basic approach as the standard pattern, but adds additional JavaScript that provides basic font event CSS class name support before the kit has even loaded. When the script first executes, the wf-loading font event class name is immediately added to the element. After a configurable timeout, if the script hasn’t yet loaded, wf-loading is replaced with wf-inactive. When the fonts finish loading, wf-inactive will be replaced with wf-active. You can use these class names to hide the initial FOUT by setting visibility: hidden on elements with Typekit fonts while the wf-loading class name is present. For example:

How to use it

• Place this snippet at the top of the so the download starts as soon as possible.
• Edit the highlighted config object and replace the default with your own Kit ID.
• Edit the highlighted config object to adjust the number of milliseconds to wait before switching from wf-loading to wf-inactive while loading the script.
• You can add JavaScript font event callbacks to the config object.

Advantages

• Loads the kit asynchronously (doesn’t block further page rendering while it loads).
• Provides font events that allow you to control the initial FOUT while the script loads.

Disadvantages

• Adds more bytes to your html page than both the standard Typekit embed code and the standard asynchronous pattern.
• Requires writing additional CSS to hide the initial FOUT in all browsers (as opposed to the standard Typekit embed code, where FOUT is hidden automatically in all but Firefox).

Other patterns

The two patterns discussed above represent the best options we’ve found for loading Typekit fonts asynchronously. We’ve explored a few other patterns as well, but won’t go into detail on them here. They have additional drawbacks and compatibility issues, but they might be useful in certain circumstances.

Standard and font events asynchronous patterns with jQuery

If you’re already using jQuery on your page, you can use jQuery to shorten the amount of JavaScript necessary for both the standard and font event asynchronous patterns discussed above. This reduces the size of your HTML page, but also delays the loading of the Typekit script until the jQuery script can be downloaded, parsed, and executed. You can see the standard jQuery pattern and font events jQuery pattern on GitHub.

Embed code at the bottom of the page

You can prevent the standard Typekit embed code from blocking the initial rendering of your page by placing it at the bottom of the tag instead of in the . While this allows your page to render, it delays the loading of the Typekit script until the entire page is nearly finished parsing. In addition, there’s no way to control the initial FOUT, and this pattern may still block the execution of other JavaScript on the page. You can see the bottom of the body pattern on GitHub.

Script tag with async attribute

Modern browsers allow you to add an async attribute to a

Choosing the right font is an important aspect of any web design project. There are hundreds, even thousands, of great options out there and many can be used with free licenses thanks to tools such as Adobe Typekit and Google Fonts.

But is one service better than the other? Is there a benefit to Google Fonts or Typekit over the other? And just how can you get started with these tools if you have not used them yet. You are in luck, because today we’ll answer those questions.

2 Million+ Fonts, Typefaces, and Design Resources With Unlimited Downloads

Download thousands of stunning premium fonts and typefaces with an Envato Elements membership. It starts at $16 per month, and gives you unlimited access to a growing library of over 2,000,000 fonts, design templates, themes, photos, and more.

Web Font Services

Adobe Typekit and Google Fonts are two different web font services. This means that the tools use a little CSS wizardry to deliver fonts to web browsers to render the typefaces on your website.

There are a few other web font services out there, but most of them are much smaller than these “big two.” Many of the typography houses offer web fonts for their signature typefaces and do some font retailers.

We’re going to break down Typekit and Google Fonts bcause of their more universal appeal and popularity.

Adobe Typekit

Typekit is part of Adobe’s Creative Cloud software suite, although developers can buy standalone usage of fonts though the service without adding on a full software bundle. Typekit has grown to become the web font giant when it comes to streaming, due in part to the tool’s inclusion with Creative Cloud. Adobe subscribers get Typekit as part of their bundled software packages.

Pros

• High-quality fonts
• Massive library to choose from
• Free for Adobe Creative Cloud subscribers
• The interface is slick and easy to use and includes helpful tools such as browsing lists
• Fonts also sync to Adobe products on your desktop so you can use them for all projects

Cons

• Does not work with some older software (Windows 2000 or Mac OS 10.3 or earlier)
• Some compatibility issues with older browsers
• Can be a pricey option for non-Adobe users

Google Fonts

Google Fonts integration is a completely free option, making it popular with WordPress users and theme and UI kit builders. Fonts are easy to integrate and download, with an ever-growing collection of typefaces.

Pros

• 100 percent free
• Provides opportunity for many typographers to be included (you can ask to submit your own font)
• The interface makes it easy to see font in use
• Font pairing and appearance tools are easy to use
• Analytics show most popular fonts by usage across the web
• Load times tend to be fast and reliable

Cons

• Open source fonts can have some quality issues
• Library can be a little more limited and you may have to substitute fonts between print and online projects
• Finding typefaces can be a little clunky if you don’t know what you are looking for

Breaking Down the Tools

When it comes to streaming web fonts there are a few commonalities as well that come with any such platform. So the first real decision is to determine if using a streaming web font service for your website is the right fit for your project.

Web font streaming, in general, gives you a lot of typeface options at a cost that would be unimaginable if you were buying typefaces. Implementation and use is rather easy and anyone with programming knowledge can handle this with ease. Users don’t know what you are using and can’t really “see” a difference.

The biggest con for web streaming font services is that you are at the mercy of font servers that belong to someone else. If they have a service glitch, so do you. Thankfully, both Adobe Typekit and Google Fonts have good track records when it comes to staying online.

Typekit Fonts Not Syncing

If you are not sold on streaming web fonts, there are other options for you to think about.

• Font stacking: This is a CSS technique where you create a list of fonts (in order of how you’d like them to be used). You don’t reliably have a specific font here, but a list of options that could appear on your site at any time. It’s a free option and is fast to load, but could result in varied website visuals.
• Self-hosted fonts: This technique allows you to use fonts that you own and have a license for in website projects. Implementation can be a little more tricky for the casual website designer and you, obviously, need to house your website on your own server. Some fonts will need to be converted to different file types for web use and ensuring you have a proper license is key here. There is also the issue of rendering – print and screen fonts are often optimized differently.

Which Is Better?

So, what should you use – Adobe Typekit, Google Fonts, another solution entirely? It really depends on your comfort level with the tools and how you are using them. Maybe you even all of the tools, based on the type of project.

Simply, there is no right or wrong service.

Then What Would You Use?

OK, I know, you came here looking for answers. While you now have some facts to help make a decision, you are still looking for a suggestion. I’m not going to tell you which choice to make. But I can tell you what I use.

As an Adobe Creative Cloud subscriber, I use Typekit. It’s easy. It integrates with all my other software. And I love the slick interface. (I want to use things that are designed well just as much as create them.)

It’s not that Typekit is necessarily better, but it is better for me. It doesn’t cost any extra and I can use the typefaces for print and digital projects, creating a polished consistency across projects that I desire. (I hate having to play the switch fonts by medium game.)

I’ve been using Typekit for a while – even before it was part of the Adobe collection – and it has gotten increasingly better. It includes great functionality and I am never lacking for a typeface (although the number of options can sometimes be overwhelming). I like what Google Fonts is doing with open sourcing, but for me Typekit is just easier.

Typekit Fonts License

Conclusion

How you serve and use fonts in your projects and on your websites is a big part of the design process. Budget and your comfort level with the tools available will likely determine the method you choose.

All of these services are improving and changing for the better all the time. Keep an eye open as you work and play with multiple options for different project types to determine what works best for you.

Typekit Fonts Not Showing Up In Illustrator

Google Fonts

Typekit Fonts Not Syncing

Google Fonts is a library of over 800 different typefaces, completely ready to be embedded in your web project. This series looks at what Google Fonts is, and shares interesting examples and combinations of fonts that can take your project to the next level.