Paul: The hanging is caused by the fact that the request for the initial JavaScript hangs without any response. With a synchronous script tag, the browser waits to load and execute that JS before moving on with parsing and rendering the rest of the page, so a JS request with no response will have the effect of blocking rendering. This is different than a JavaScript file that immediately returns a 404 or other invalid response. In that case, the browser can immediately move on to parsing the next bit of markup.

Unfortunately, there’s not much we can do to get around this browser behavior using a synchronous embed code. That’s why we came up with the asynchronous embed code, but it has the disadvantage of requiring more work from the developer to hide the FOUT. We’re also working with our CDN provider to see if anything can be done about the length of time that goes by without any response, and improving reliability in general.

Sean, with the standard embed code, is the hang caused by inability to load the initial javascript files from use.typekit.com, or is it caused by subsequent actions of that javascript when it tries to load the actual fonts?

I would have expected that the mere inability to load a javascript file would not hang the loading of a web page? After all, surely that would happen quite often due to broken links, etc?

If it’s due to inability to load the fonts, would it be possible for Typekit to modify the standard embed code so that it is not vulnerable to the fonts being unavailable? e.g. with a timeout? Or is that just the same as the asynchronous embed code?

I don’t think I understand what you mean, so let me clarify a bit. The asynchronous embed code is different than the standard embed code that we make available through the Typekit.com UI and Kit Editor. It is detailed in this blog post.

The asynchronous embed code is designed so that the loading of the fonts shouldn’t block the rendering of the page at all. During an outage like this one, where the request for the initial JS file hangs, the rest of the page will go on loading and rendering. After a configurable timeout, the “wf-inactive” classname is added to the html tag so that you can apply fallback styles. The JS request will continue to hang in the background until it times out, but it shouldn’t affect the loading of the rest of the page. However, use of the asynchronous embed code doesn’t mean that the web fonts will load even during an outage. An outage means that the necessary data just can’t be transferred, so the best thing to do is quickly revert to the fallback fonts. Happily, outages like this are also pretty rare.

Did you see something other than the behavior that I described when using the asynchronous snippet? If so, you should send an email to support@typekit.com so that we can look into your particular case and try to determine what happened.

Can I suggest that Typekit consider the implications of this outage and whether the default typekit code needs to be more robust — e.g. some kind of timeout mechanism if fonts cannot be loaded?