"However when a script is loading, the browser will not start any other downloads, even on different hostnames!"
Orly? I guess he missed the async attribute (first one listed) in the MDN documentation he sited.
"As per the HTTP/1.1 spec browsers can download no more than two components in parallel per hostname."
Fortunately, browsers ignore the spec here and make more than two connections at a time per hostname.
"Faster page rendering, faster time when page becomes usable, faster page loading, better user experience. It’s time to let go of the DOM Ready Event."
In my experience, getting things loading in parallel is one of the best ways to speed up page load times, and a DOM ready event can really work out in your favor when you set the async attribute on a script. Each situation is different, putting all the script elements at the bottom of body and forgetting about DOM Ready events may work best many cases, but making blanket statements isn't really helping anyone. I wonder how setting the defer attribute on both scripts and moving them to the head would work out in the author's benchmark.
...so why don't you try it? You can fork and perform tests...
You are right about what the spec sais and what happens in reality as far as "loading" is concerned. Modern browsers can open multiple requests to a webserver. However "Painting" and "Rendering" is another area which most developers miss its significance.
Script parsing is blocking to rendering.
Especially when scripts are included in the HEAD the delay becomes pretty apparent.
The point of the article was to illustrate how DOM Ready is not needed when loading and executing scripts synchronously. I am not convinced that loading scripts asynchronously will result in a faster, absolute time of when the page is ready to be used by the user (events binded, complex ui that need JS are rendered.
And i am definitely not sold on the concept of polling every 5ms for the existence of elements in the DOM. Which is required for async loaded scripts if they want to be as fast as possible (and hoping that they were loaded before the elements are rendered). If I had that much a burden of manipulating an element right there and then when it was rendered, i'd plainly add a SCRIPT tag right beneath it.
Orly? I guess he missed the async attribute (first one listed) in the MDN documentation he sited.
"As per the HTTP/1.1 spec browsers can download no more than two components in parallel per hostname."
Fortunately, browsers ignore the spec here and make more than two connections at a time per hostname.
"Faster page rendering, faster time when page becomes usable, faster page loading, better user experience. It’s time to let go of the DOM Ready Event."
In my experience, getting things loading in parallel is one of the best ways to speed up page load times, and a DOM ready event can really work out in your favor when you set the async attribute on a script. Each situation is different, putting all the script elements at the bottom of body and forgetting about DOM Ready events may work best many cases, but making blanket statements isn't really helping anyone. I wonder how setting the defer attribute on both scripts and moving them to the head would work out in the author's benchmark.