Details on outage in Australia and New Zealand
At approximately 1:00 PM AEST/3:00 PM NZST on Friday, 13 July, our font network began to be unavailable for many users in Australia and New Zealand.
Our font network consists of a worldwide system of computers run by a Content Delivery Network, or CDN. Requests for fonts are routed to the nearest server to give the best performance. Unfortunately yesterday there was severe congestion on the link between two major internet service providers, Pacnet and NTT, and this in turn caused problems when trying to access our servers in Sydney. This meant fonts were unavailable for users in that region. According to our monitoring systems, this lasted approximately 2 hours and was resolved at 2:55 PM AEST/4:55 PM NZST.
Typekit font serving is back to normal. We know that our customers have high expectations for our uptime and performance, and we regret the impact this had on many of you. Going forward, we’ll be monitoring our vendor’s network performance closely and working with them to minimize any future interruptions.
The nature of the Internet means that occasional interruptions are unavoidable. For this reason, we encourage Typekit users to consider using our asynchronous loading pattern any time you need to eliminate the possibility that a problem loading the kit could interfere with loading the rest of the page. This approach ensures that your page won’t wait for the kit in the event that something goes wrong somewhere between the font network and the user.
If you have any questions, please don’t hesitate to leave a comment or contact us at support@typekit.com.
5 Responses
Comments are closed.
This event revealed an unsuspected vulnerability of websites which use Typekit. This included the adobe.com website which also became unavailable in Australia. Pages on any sites using Typekit would just “hang” partway through loading, displaying usually just a blank screen and a spinning “loading” indicator (in Safari at least).
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?
This outage showed us that current loading of Typekit fonts asynchronously is NOT a robust enough solution, the JS failed first (viewed by using firebug) so the try & catch was ineffective for the loading of the font.
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.
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?
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.