If I understand your answer correctly, browers must delay DOM-ready when script tags are used because of the risk that scripts contain document.write(), but using a script loader we can safely load scripts because we know they won’t contain document.write() (I notice Mozilla says: Never call document.write() from an async script.)

Why is DOM-ready a critical moment in perceived performance? I ask because tags in the HTML before the script tags are rendered before those scripts are run, so if your script tags are just before the closing body tag shouldn’t perceived performance be good? (Sorry if that’s rather a noob question -obviously there’s a good answer to that otherwise we wouldn’t need async and defer and script loaders!)

As such, browsers are forced to, no matter what, hold up the DOM-ready event (that magical moment when a user can interact meaningfully with the page) until it is certain that it in fact DOES know enough about the structure of the page to declare that the “DOM is ready”. This has the effect of blocking DOM-ready until all normally loaded (that is, with <script> tags) scripts are finished loading and running.

DOM-ready is perhaps the most critical moment in the page’s life time when it comes to both performance and perceived-performance (that is, how fast users FEEL your page is). It’s critical to get DOM-ready to happen as soon as possible. No matter where you load your scripts (top or bottom), if you do so with normal <script> tags, you will ALWAYS block DOM-ready.

The common wisdom therefore is to use techniques for loading which unblock the DOM-ready from the script load. How can you do so? <script async> is one such way. The problem is this only works for one script, or for a set of scripts which are entirely independent, because two or more “async” loaded scripts will not execute in any defined order (they execute ASAP).

<script defer> is the next most common suggestion. However, “defer” is *horribly* buggy. Not only does its behavior differ between browsers if it does or does not block DOM-ready, but there are AWFUL bugs (in IE) where if you load two or more scripts with “defer”, and one of them happens to do something like modify the DOM, it can actually cause that first script to *pause* IN THE MIDDLE OF THE CODE EXECUTION, run another script, then come back to the previous code, causing untold numbers of impossible to track down bugs. Try loading jquery.js and jquery-ui.js, both using “defer”, in IE8 and below, and you’ll see what I mean.

Anyway, bottom line, in most practical cases, “async” and “defer” are simply not good enough.

Ergo, you need a script loader, which gives you the desired behavior (INCLUDING not blocking DOM-ready) without all the bugs. LABjs is, if nothing else, a polyfill for “defer” (and “async” to an extent), to work the way they “ought to”™ work, but never will (because of legacy).

I’ve read (and you mention FF3.5 here) that newer browsers can download scripts that are referenced in script tags in parallel with each other. But what this seems to show is even newer browsers actually downloading scripts in parallel with other resources like images.

Is LABjs still needed? (or is it still worth using for when a user has an older browser?)

I might just be confused: with http://labjs.com/test_suite/test-script-tags.php Chrome 16 developers tools shows images being downloaded only after the scripts are downloaded. That said, in this case the script tags are in the document’s head whereas with the Cuzillion example they are in the body.

Putting older browsers aside for a moment, is LABjs only relevant if you need to put your scripts in the document’s head?

Thanks for any thoughts

I had an ‘iframe’ parallel loading implementation but it’s not working for the damn IE, so not usable on more than the 60% of browsers around

Your solution is quite appealing since it seems easy to implement on most sites and working cross-browser. My compliments.