New, improved embed code
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.
Update: We’ve since made asynchronous loading a default setting for all new kits. Details are in this blog post.
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:
//use.typekit.net/xxxxxx.js try{Typekit.load();}catch(e){}
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.
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.
10 Responses
Comments are closed.
Thanks Typekit!
Love the async code. Thank you!
This is great, I’ll be very glad to use the new async-embed and reap the performance benefits! Thanks!
The asynchronous embed was causing issues on modernizr.com, having the font events trigger too slow and, as a result, browsers would start to render something only to then undo it.
If you aren’t trying to have no FOUT, the async is great, but if you *are* trying to hide text until the fonts have loaded, I recommend not using async. Fast machines + fast browsers will be too fast for your code. 🙂
That said, modernizr.com is now using the new embed code. Hooray! (it also got some other much-needed improvements.)
Update on this: I think the slowdown is exacerbated when using YepNope, as I see a much more significant flash/delay when doing so. Using Typekit’s own native embed code works a lot better. Since this was not a reduced test case, I can’t quite be conclusive either way. However, I am posting this here to correct my earlier statement—it was *not* the asynchronous loading (alone?) that caused the problem.
Faruk: I’m curious about the delay in font events that you’re seeing with the async code. None of the JS font event callbacks will trigger until the initial JS is finished downloading and executing, but the “wf-loading” CSS font event classname should be applied to the html element immediately when the embed code executes. If the embed code is in the head of your page, that should be before the browser gets a chance to render any part of your page. So, if you have CSS that hides elements with web fonts while “wf-loading” is present, there should be absolutely no FOUT visible, even though you’re using async loading.
Were you trying to use the JS callbacks instead of the CSS classnames, perhaps? Or were you using some other library or tool that was somehow delaying execution of the embed code?
Hey Sean, it seems the issue was caused by YepNope’s async loading. When I switched to the Typekit async code (and moved it way up to right after Modernizr), it no longer experienced a FOUT.
Excited to implement the asynchronous code on the blog. No flashy text!
Tim: Just to clarify, the asynchronous embed code doesn’t necessarily make it easier to hide the FOUT. Font events are available when using both the default and advanced embed code styles, so you should be able to eliminate flashy text no matter what.
There is still room for optimization. I would appreciate to help you with further improvements.