[load the 15k jQuery library first]

<script type="text/javascript">
/*<![CDATA[*/
$(document).ready(function(){

// Do stuff

});
/*]]>*/
</script>

Done.

@Jonathan: Perhaps his point is that emulating DOMContentLoaded in IE has been "solved" by all the major libraries already. The solutions are hacky, but battle-tested.

Heh, this is something I've used before. Didn't know it was that big of an issue; thought it was my IE flipping out once more...

setTimeout is very happy to run before the DOM is ready, it'll just queue the function behind whatever the browser's currently doing. When the whole page arrives in the browser at once, the function is conveniently queued after the DOM is ready.

Obviously the page isn't all arriving at once, but gzipping gives that effect. The parser gets the page as one big complete chunk.

Current IE DOMReady solutions use setTimeout to test properties of an element which throw an error before the DOM is ready. When an error isn't thrown, it is assumed the DOM is ready.

Jake.

I'm running gzip on my server and have set up a simple test. The culprit of slow loading pages in my experience hasn't been so much the connection the user has or the size of the page, but often third parties - in particular externally loaded scripts, for example for ad serving.

My test simulates a slow response from a third party script provider and, sadly, the setTimeout fires before the DOM is ready.

http://remysharp.com/demo/onload.php

Essentially the setTimeout will work, so long as a) you're running gzip, and b) you're confident you're not serving any external scripts (that might be slow in responding).

I'd rather just use window.setTimeout than a 15k library (which I'll point out is only 15k when gzipped).

Well, if all you need is the DOMContentLoaded stuff, you can gank that pretty easily. It'd cost you only ~15 lines of JavaScript (not including the obligatory MIT license at the top, of course).

My problems with the setTimeout approach are twofold. First: to know if it'll work, you have to keep track of whether a seemingly unrelated and arbitrary switch (gzip on/off) is in the proper position. I usually try to minimize the number of tiny "be sure to..." maxims when I develop, because some law of the universe dictates that I'll forget about one of them just in time to spend 30 minutes debugging some simple piece of code.

Second: it's no guarantee that the DOM is ready – only that a function got called after having been deferred. An approach that demonstrates the DOM is ready (e.g., "the DOM must be ready because I can now read this DHTML property without an exception being thrown") seems far sturdier.

Oh, I just thought of a third: to require gzip compression means that pages can't be tested locally without running a web server. Can't just drag an HTML file into a browser window, because then all your DOMContentLoaded handlers will fire too early.

I want to add that you may not be seeing the problem until you hit a page long enough due to buffering on the server. In Apache/PHP the output buffering is set by default to buffer up to 4Kbytes. The problem shows more often when pages are served chunked ("Transfer-Encoding: chunked"), normally dynamic pages are served that way.

You have two options to show the problem:

1) Be sure your page is at least 3 times (12Kb) the setting of the output buffer

and/or

2) Insert some delay in a PHP script and force a flush() on the output buffer

Local cache can also be hiding problems, so disable it during testing, then enable it again and repeat the same tests. And you are right, even if we have a solution there is no time to rest on laurels...IE8 is coming :-)

I agree with Andrew's first two warnings about the technique.

That said, it's important to keep on innovating. It's still a very valid observation, and one that might be usable at some later date, perhaps with only a little modification.

Jonathan, I'm a little curious about your comment about "Charles"? I think I've been looking for a tool like that for awhile now, but have yet to find one that seems to work when testing locally. Can you elaborate on this software at all, and whether it works when accessing a localhost webserver?

Brendon: Charles can be found here.
I've been using it for almost 3 years, and it just gets better and better, with formatting xml responses, displaying images, reading AMF and so on. It's gold when developing with ajax or flash related server calls.

I like this solution, only that I agree with the comments saying the current approach is too specific to be used without thinking or testing. But maybe it's a good new starting point. As it fires once the DOM is ready, if not earlier, you'd have to check if you're complete or not. I can't come up with anything creative right now, possibly checking for some element at the bottom, in a loop, or something? Sounds terrible, I know.

Well, IE has a few properties that could be useful. For example, the activeElement property doesn't exist until the DOM is "ready" according to IE docs. We could just put f back onto the queue if the DOM doesn't seem ready in a progressive load under IE.

function DOMReady(f) {
  if (/(?!.*?compatible|.*?webkit)^mozilla|opera/i.test(navigator.userAgent)){ // Feeling dirty yet?
    document.addEventListener("DOMContentLoaded", f, false);
  }
  /*@cc_on @*/
  /*@if (@_win32)
  elseif(document.activeElement === null) {
    window.setTimeout(function() { DOMReady(f); }, 10); // back onto the event queue
  }
  /*@end @*/
  else{
    window.setTimeout(f,0);
  }
}

There are other ways too that get messy writing script elements with the IE-specific defer property, but the goal seems to be to try and keep the code short and sweet. That said, I am really not a fan of that anonymous function in the IE-specific setTimeout(), but my brain's too tired to figure out how to make it go away.

@Matthias: Thanks! If anyone else wants to elaborate a bit more on its use, I'd greatly appreciate it! I'll go take a look at it for now though. As for the DOMContentLoaded issue, most of the projects I've had, I haven't had an excuse to *not* use a JS library that solves the issue, thankfully.

Preved dyatlam!

I believe my IEContentLoaded trick has proven to be more precise and reliable on IE and will work both with compressed and uncompressed pages.

It has been proven by many that the setTimeout is unreliable in most situations, the exact moment is hard to detect, especially when navigating back and forward with the browsers buttons. Unfortunately the combinations we have to check are too many, better rely on something described by the browser vendor itself.

Diego Perini