Last week, I asserted that DOM-ready detection sucks because there’s a chicken-and-the-egg problem where some frameworks (like jQuery 1.3.2 and before) that do DOM-ready detection have trouble detecting the “event” if the framework is loaded dynamically after DOM-ready has already occurred.
I stand by that assertion, especially now that you’ve seen the launch of LABjs 1.0, which unfortunately exposes this shortcoming.
The problem is that LABjs, like many loaders that perform similarly, causes script loading, normally a blocking behavior via <script> tags, to become unblocked and asynchronous to the rest of the page. This means that the page’s DOM-ready will happen before the framework arrives, meaning the DOM-ready detection is vulnerable to “missing” the fact that the event has passed.
This still sucks. We need better solutions for DOM-ready than the hacks we currently use. I mean, come on, IE… really? We have to loop and test (try/catch) on “doScroll()”? Seriously, there has to be a better way! We also need Firefox to release patches to the entire 3.x branch of browsers (and maybe even 2.x!) to support the “document.readyState” property, not just 3.6, because it’s an effective workaround method for detecting if the event has already occurred.
Yeah, but my complaining is not covering any new ground. I do hope browsers start to get the message, though.
A silver lining in the gray cloud
There’s another side to the story — a different perspective we can take on the effects that LABjs (and other loaders) have on a page’s DOM-ready.
Let’s recall and take a deeper look at the 3 waterfall diagrams from the LABjs launch announcement. As that post points out, FF3 (and other older gen browsers) load <script> tags serially, while newer gen browsers (FF3.5, IE8, Chrome 2+, etc) got smarter and started loading scripts in parallel. But, they still block the rest of the page’s resources, which is a primary reason LABjs steps in with something to offer.
Those diagrams reveal a telling story about DOM-ready you may not have noticed at first (I didn’t!). Firebug renders a blue line at the point in the timeline where DOM-ready occurs (and a red line for the window “onload” — when all initial resources finish downloading). Notice how the blue line changes in the three diagrams.
That’s right… using LABjs on the page sped up the occurence of DOM-ready from ~10.2 seconds in FF3.0 (or ~6 seconds in FF3.5) all the way down to about 0.4 seconds with LABjs! That is a major, huge, incredible improvement no matter how you look at it!
DOM-ready is the time at which the browser typically first renders the content it has available (including styles), and allows the user some sort of basic interaction (scrolling, etc) with the page. And depending on the design of your page, it may be fully functional at DOM-ready, with only non-major decorative changes as the rest of the content arrives. This means that users see and interact with your page, on average, much, MUCH sooner than with regular <script> tag usage.
This is a great win for user-experience and page-load performance. Of course, you have to be careful about how this user-experience affects your users, because there can potentially be some negative side-effects of these optimizations.
Luckily, as mentioned in that post, there are, I believe, effective ways to deal with the FUBC (flash of un-behaviored content) issue. Moreover, you can (and should!) also think about such things from day 1 when initially designing the UX of your site, for better, more complete patterns of progressive-enhancement.
I see the light!
You see, the same thing that is an annoying curse to developers (hampering frameworks’ detection of DOM-ready and thus complicating our script logic) is a big blessing to the user.
And in the end, isn’t that what all of us really care most about: making our sites treat the users to a better experience? Don’t we owe it to the the general web public to take a little extra effort to generate potentially huge improvements in how users experience our site when they come to visit?