Skip to content
Browse files
Delay the result of the readyState check to give scripts the opportun…
…ity to delay ready, as described by @jrburke in 747ba7d.
  • Loading branch information
jeresig committed Sep 23, 2010
1 parent 2f60335 commit e270d80
Showing 1 changed file with 2 additions and 1 deletion.
@@ -429,7 +429,8 @@ jQuery.extend({
// Catch cases where $(document).ready() is called after the
// browser event has already occurred.
if ( document.readyState === "complete" ) {
return jQuery.ready();
// Handle it asynchronously to allow scripts the opportunity to delay ready
return setTimeout( jQuery.ready, 13 );

This comment has been minimized.

Copy link

davidmurdoch Sep 24, 2010

Why 13ms? From @jrburke's comment it seems that jQuery.ready just needs to be pushed to the end of the call stack; the delay doesn't matter.

         /* jquery.js */
        if ( document.readyState === "complete" ) {
            // push jQuery.ready to the end of the queue (and do it as quickly as the browser will let us)
            return setTimeout( jQuery.ready, 1 );

        /* scriptLoader.js */
        // window.onload to make sure document.readyState === "complete"
        window.onload = function () {
            // async script loading script...
            (function ( d, t ) {
                var s = d.createElement( t );
                s.async = true;
                s.onload = function () {
                    // I am executed BEFORE setTimeout( jQuery.ready, 1 )!
                s.src = "js/jquery.js";
                ( t = d.getElementsByTagName(t)[0] ).parentNode.insertBefore( s, t );
            })( document,  "script" );

From what I've read, Chrome can execute an interval/timeout as quickly as 1ms, Firefox at 10ms or ~15ms, and IE at 15ms (src: In this case, where we don't care about UI responsiveness, I think a 1ms or 0 ms interval is appropriate.

This comment has been minimized.

Copy link

jeresig Sep 24, 2010

Author Member

Traditionally we like to set a standard threshold for our timers across jQuery - using a consistent rate that won't peg the browser. We picked 13ms as it was roughly the rate at which most timers fire at - thus not overwhelming a browser (see the code in effects.js). I tend to worry about causing different effects across browsers. Dropping the number to 1 will certainly have a different effect in Chrome from IE or FIrefox and I worry that it might cause additional issues. Now it's probably less of an issue with these one-off calls for ready so I've bumped them down a220c81. I plan on making the 13ms effects timer configurable in a follow-up commit so that users can adjust it as they see fit.


// Mozilla, Opera and webkit nightlies currently support this event

0 comments on commit e270d80

Please sign in to comment.