How make your web-app become available faster: Let go of the DOM Ready events
thanpol.as
thanpol.as
Start with the best practices (http://developer.yahoo.com/performance/rules.html). Once you've nailed those, then you can start thinking about optimizations like this.
as one of the people responsible for publishing those rules, I feel obligated to mention that they're somewhat out of date. The more correct rule today, given browser enhancements is, "It depends".
Asynchronously loaded code is obviously better. Stick it into the head, and allow it to download in parallel with the rest of the page. It doesn't need to execute until much later, but it's the downloading and parsing that takes the most time, so get that out of the way as soon as possible.
Within your script, you can check for the existence of the elements you need to manipulate. YUI does this quite well, but if you're using something else, just poll infrequently for the nextSibling of the node you want.
Imagine a site the sets a custom `submit` handler for a `<form>` tag, possibly for client-side form validation, an AJAX file uploader, date selection, etc. A user submits the form before JavaScript has loaded completely and doesn't get the benefit of the JavaScript-enhanced experience. In local development or on a high-speed connection this will probably never happen. But a user accessing the site with their phone over the slow U.S. cell data network has a much higher chance of hitting upon this undesired behavior.
On the other hand, it's also the recommended method to protect your users from a click-jacking attack across all browsers (read those that don't support CORS).
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.
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.
Check those slides out: https://perf-metrics-velocity2012.appspot.com/#16 (move left/right with cursor keys).
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.
Would it be reasonable to ask for an opt-in feature to make document.write usage explicitly prevented, perhaps through an exception?