Posts Tagged IE 8

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