So, when I looked at IE 7 Waterfall diagram, again plugging Pat’s great Webpagetest.org, 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 webpagetest.org, 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:
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)
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?
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.