Take the 2-minute tour ×

Since placing javascript DOM methods in the bottom of the html page (after <body>) is a lot faster than using the jQuery 'ready' event, shouldnt we be forcing it by doing:


...after the body tag? I havent really tried this, but it should speed up things. Or did I miss something?

share|improve this question
FWIW the ASP.NET AJAX clientside framework loads its "ready" code (<script>Sys.Application.initialize()</script>) by injecting it right before the closing </body> tag. –  Roatin Marth Nov 13 '09 at 22:30

3 Answers 3

up vote 5 down vote accepted


share|improve this answer

The ready event means the document has now been parsed and the DOM is available to be manipulated. That happens when the browser has completed its parsing, and you can't make it happen sooner.

How do you think such a thing would work? Would it flip a magic switch in the browser's HTML parser that makes it run faster than it normally does? Would it cause the computer's processor to run faster, so the browser would finish parsing the document sooner?

You can't force the browser to parse the document any faster than it's going to anyway. Not even with jQuery ;-)

share|improve this answer
Thats not really true, is it? stackoverflow.com/questions/1438883/… We use a domReady() function in the bottom on our client sites and we never run into any problems. In fact, it's just a lot faster than using the 'ready' state and can manipulate the DOM without any problems, since it's loaded anyway. –  David Nov 13 '09 at 17:01
That wasn't the question though. The OP was asking about triggering the ready event, but that's impossible: you can trigger events that are associated with user activity such as click to simulate the user clicking a button, but you can't trigger an event that depends on the browser's internal representation of the DOM having reached a given state. Rephrase the question as asking about $('document').trigger('load'); and it should be obvious that it doesn't make sense. –  NickFitz Nov 16 '09 at 12:29
Of course you can trigger events that is not related to any user activity. I think you can trigger the ready event by using jQuery.ready(); or jQuery(document).triggerHandler("ready"); –  David Nov 18 '09 at 12:35
@David: you may be able to trigger execution of the function associated with that event, but that doesn't mean the event has actually happened yet. I can cause the onload handler to be executed using window.onload(); but that doesn't mean the document has loaded. –  NickFitz Nov 23 '09 at 18:10
Yes, but that is exactly my point. There is no "native" DOMContentLoaded event in IE, jQuery just simulates it using the IE dom ready trick described at javascript.nwbox.com/IEContentLoaded . So my question was if I can trigger the function myself by adding $.ready() before closing the body tag, to make the domReady happen as soon as possible. My tests show pretty good results doing so. –  David Nov 23 '09 at 22:54

I had a closely related question, I ended up finding the answer myself right before resorting to posting to SO. As people who have my question will likely land here (number one google result for "jquery force document ready"), allow me to give some extra info.

My problem is that I am dynamically generating some HTML (using XSLT) that will sometimes be saved for later, but other times I just want to open a new window with the new HTML so the user can preview it. Like so:

var html = UseXSLTToGenerateSomeHTML();
var myWindow = window.open('', '', 'width=805,height=493');

Problem is, the generated HTML uses jQuery, and the domready event was never getting invoked. It should have been obvious to me immediately from David's answer how to do it, but the tweak escaped me momentarily. It is:

var html = UseXSLTToGenerateSomeHTML();

Note that in this case, the page doing this doesn't even use jQuery... only the generated HTML does. Doesn't matter, you are generating the jQuery event on the other document.

share|improve this answer

Your Answer


