Posts Tagged Javascript

Going Async!

A lot of things have changed since my last post. In the meantime my company (Hansenet aka Alice) was sold and is now part of Telefonica, which sails under the “O2” Brand in Germany. My responsibilities have changed also quite a bit, and part of it is now the O2 Portal.

We had a big Relaunch of the site something like 6 weeks ago, and are now doing some more (performance) tweaks here and there.

One of the tweaks we had on our Agenda was going Async for the newly integrated social media widgets of Facebook, Twitter and Google+. The idea came up actually by a tweet from Steve Souders announcing that the Google Plus Button has gone async.

This was then further fueled by a Post from Stoyan Stefanov, where he showed a way to go async for actually all of the most prominent widgets.

So, maybe you are asking yourself, what is so important on async, that some of the brightest guys are working and evangelizing so much on that? Reason for that is the way Browsers behave. They are single threaded, and so quite a few Browsers will simply stop doing anything else (even downloading other assets in parallel) when they are downloading and executing Javascript. So a) it comes at a performance price for some browsers, as no other asset is downloaded and therefore interfers/blocks/halts the process of Page load and rendering, and b) due to above mentioned behaviour it becomes a Single-Point-of-Failure (SPOF). If an image loads slowly (or not at all) it is not a big issue. If a Javascript loads slowly (or not at all), it becomes really ugly for the above mentioned reasons.

And with the social widgets it is even more difficult: If your image Server is unreachable, you can politely call your engineer. If Twitter is unavailable… well… you can’t even tweet that.

And just recently Pat Meenan has written an excellent Blogpost, how the result can look like, visible in this Video. You see how the Page of businessinsider remains blank for full 20 seconds (White Page! Nothing!) just because Twitter is unavailable. And the nice chap that Pat is, he already implemented the possibility to check your Site for these SPOFs in Webpagetest.

So I tried it with our site and the result was this (Left: Twitter unavailable, Right: Twitter available) :

Video Before

What you see here is not as bad as Businessinsider. Nevertheless the Browser is spinning wheels for more than 25 seconds, indicating, that the page hasn’t completed. Even more problematic is, that the Slider (arrow >) to the right of the Screen does not show up until 24 seconds within the page load. And THAT is problematic, as the Slider functionality of the main teaser is quite an important feature to our site.

So overnight 🙂 we (actually others, see below) did some magic and today the widgets have gone async! Result? (Left: Twitter unavailable, Right: Twitter available)

Video After

As you can see, the page doesn’t need any longer, if any of the social widget providers is unavailable! (well actually it is even a bit faster due to less data to download) And as a goodie, our PageSpeed Score has improved by +1 due to ~150KB of Javascript having been defered.

Thanks to Alex K., Sasa S. and Siegfried H. for the quick fix, and as always, to the community (and this time specifically to Steve, Stoyan and Pat) for continously developing tools and sharing research results and best practices.

So I recommend to testdrive your site with Webpagetest, and make sure, it doesn’t break!

Leave a Comment

Taming IE 8 Javascript download order

Hi there!

While having started to analyze, how IE 8 interacts with our site in my recent post here, I observed another, to me, strange behaviour. We have read of course Steve Souders book High Performance Websites, and therefore decided to place as much external Javascript files as possible at THE BOTTOM of the page. Due to some reasons, though, we were forced to have still some external Javascript files in the HEAD, to be precise: 2 of them. Everything else went to the bottom.

So, when I looked at IE 7 Waterfall diagram, again plugging Pat’s great, everything seemed to be fine.

You see the 2 JS Assets in the HEAD being downloaded, sequentially, as it is IE 7, and then going on downloading the images as defined in the html document.

So, just as a comparison, I did the same thing using IE 8. And, boy, was I surprised (Which is a frequent feeling, when doing web performance optimization). The Waterfall looked like this:

It seems all our optimization efforts never took place. Again, we see all JS being downloaded first! This left me a little bit puzzled… So I looked around at, and saw other waterfalls, showing the same behaviour. But also others, that didn’t.

So I built a really simple page and was playing around a little bit. First attempt was to try to repro the results by a page being as simple as possible, but that would match this behaviour.  I succeeded with this page and the Waterfall indeed showed the same behaviour:

A small JS Script 01 is placed in the HEAD (splitting the inital payload 🙂 ). This JS Script is actually empty, nothing in there. But even though in the html document all images are placed right at the TOP of the BODY, and the JS files 02-09 are at the BOTTOM of the BODY, IE 8 fetches these JS resources, before it starts to download the images.

Rendering, though, is not being blocked by these “elevated” JS-Files. But the images of this rather… image-centric 🙂 page are not visible up until ~4.75 seconds.

So while it does NOT block Rendering, it CLOGS UP your available TCP Connections.

So by fiddling around, I found the issue is the small JS in the HEAD of the document. When I remove this JS 01 from the HEAD of the Document, the Waterfall in IE 8 suddenly changes dramatically to this:

In comparison to the first example, this page displays the first image right after 1.5 seconds, instead of 4.75 seconds. That is three times as fast! And the difference is a ~0 Byte external Javascript placed in the HEAD! (Well, okay, my example might be a little bit strechted and rather rare in the wild 🙂 )

So being also an avid reader of Steves “Even faster Websites”, I remembered, that even though IE 8 is not blocking downloads of Images while fetching JS, this might be a different story for CSS and IFRAMEs.

I did further tests and to make a long story short: While “elevating” the JS from the Bottom to the Top, these “elevated” JS DO NOT block IFRAMEs or CSS files, to be seen here:

(As you can see, even though I placed the CSS file at the TOP of the BODY and not in the HEAD, IE 8 pulls it first, and afterwards the “elevated” JS files)

and here:

So, after we have now checked out rather thoroughly the behaviour of IE 8, what can you do about this, if you simply NEED an external JS in your HEAD?

Well, you can, for instance, use the method explained here by Nicholas Zakas. Using this method, my Test Page Waterfall looks in IE 8 now like that:

Apart of finally being able to tame IE 8 Javascript load order, this also gives you the benefit of “unblocking” JS downloads in IE 7.

The result of these tests to me is the following:

With IE 8, in case an external JS-file is being placed in the HEAD by the conventional <script> method, all other external JS assets in the BODY being fetched by <script> will be elevated in the download order. These assets are not blocking rendering, but they do clog up your connections.

This can be avoided by the above mentioned method (probably there are other methods as well).

IE 7 does not show this behaviour, FF 3.6.3 does not show this behaviour.


Leave a Comment