javascript - page - ¿El evento DOMContentLoaded es EXACTAMENTE igual que la función.ready() de jQuery?

jquery ready vs load

Question

He reemplazado window.addEventListener(''DOMContentLoaded'', function() {}); con jQuery''s $(document).bind(''ready'', function() {}); , porque el primero no funcionó en IE <9 y no quería jugar con .attachEvent() para ese navegador ficticio, si pudiera tenerlo bien cubierto por jQuery.

Poco después del reemplazo, noté que el evento DOMContentLoaded siempre se activaba alrededor de 0-2 milisegundos después de cargar / actualizar la página (al menos esto es lo que registraba mi secuencia de comandos de registro), mientras que .ready() siempre requiere al menos 15-20 milisegundos, después de la actualización de la página, para ser disparado (nuevamente, según lo registrado por el script).

Estoy pidiendo puramente por alimentar mi curiosidad, ¿por qué hay tal retraso "significativo"? Por supuesto, no hay problema para mí, que jQuery está disparando ese evento más tarde. Es justo, porque quiero conocer TODAS las respuestas (¡y gobernar el mundo!:]), ¡No puedo dormir con eso! :]

EDITAR : en la función .ready (), algún usuario (Nick (de Nexxar)) señala que: " jQuery simula el evento" DOMContentLoaded "no existente en IE, pero el mecanismo utilizado se dispara mucho más tarde que el evento utilizado en otros navegadores " . Tal vez esto es lo mismo, estoy pidiendo?

Answer 1

Asumiendo el navegador que admite el evento:

1. El evento real puede admitir cualquier document . jQuery solo usará el document que se cargó, independientemente de lo que le pase.
2. jQuery lanzará el evento de forma asíncrona, incluso si el evento ya ha sucedido. ''DOMContentLoaded'' evento ''DOMContentLoaded'' no hará nada si el evento ya ha sucedido.

No hay demora en estos navegadores, consulte http://jsfiddle.net/rqTAX/3/ (los desplazamientos registrados están en milisegundos).

Para los navegadores que no son compatibles con el evento, jQuery obviamente también funcionará para ellos. Utilizará un mecanismo hacky que no es el mismo que el DOMContentLoaded real y no necesariamente se activará tan pronto como el DOMContentLoaded real:

// The DOM ready check for Internet Explorer
function doScrollCheck() {
if ( jQuery.isReady ) {
return;
}
try {
// If IE is used, use the trick by Diego Perini
// http://javascript.nwbox.com/IEContentLoaded/
document.documentElement.doScroll("left");
} catch(e) {
setTimeout( doScrollCheck, 1 );
return;
}
// and execute any waiting functions
jQuery.ready();
}

Answer 2

Otra razón para que aparezca el mensaje de "listo" después (en la práctica) es que puede haber muchos eventos conectados. Si cualquiera de estas son operaciones sincrónicas de larga ejecución, el evento listo vendrá mucho más tarde. Por ejemplo, uso knockout.js y puede tomar 500ms para inicializar la página.

Sin embargo, utilizando su página de prueba mínima que no es el caso, por supuesto. Intenté ejecutar lo siguiente:

 console.log(window.performance.timing.domContentLoadedEventEnd -
window.performance.timing.domContentLoadedEventStart);

Esto da aproximadamente 6ms incluso para tu súper página simple

También tomé su código y lo ejecuté a través de las herramientas de rendimiento de Chrome y descubrí algunas cosas interesantes:

• Por cierto: la barra azul vertical es DOMCONTENTLOADED y el verde es ''primera pintura''
• Puede ver que incluso una llamada a función super simple en el evento DOMCONTENTLOADED puede tomar 5 ms (y esto es en un i7). Recuerde que debe analizarse y las cosas deben inicializarse.
• Las devoluciones de llamada se muestran en el color cian (anónimo), la primera es del evento DOMCONTENTLOADED y la segunda es la devolución de llamada ''lista''.
• Notarás ''Timer Fired'' (es decir, setTimeout ). Entonces no es instantáneo de ninguna manera.

Al mirar el código fuente de jQuery , ves que realmente configuran un temporizador para las devoluciones de llamada:

// Handle it asynchronously to allow scripts the opportunity to delay ready
window.setTimeout( jQuery.ready );

No estoy exactamente seguro de lo que quieren decir aquí (cualquier idea), pero explica el comportamiento. Pude ver que es útil para evitar las condiciones de carrera y bloquear la interfaz de usuario, pero "retrasar la preparación" no está claro para mí.

Answer 3

jQuery simula este evento uniéndose al evento readystatechange del document , que es la forma estándar de simular DOMContentLoaded en oldIE.

De acuerdo con la fuente jQuery , ese evento dispara "tarde" pero antes de window.onload . Sin embargo, no puedo encontrar cuando ese evento se dispara exactamente. DOMContentLoaded cuando el DOM está construido y listo para la creación de scripts, por lo que readystatechange después de eso; tal vez espere la representación del diseño o el diseño de algo así, o el evento se desencadena más adelante en el proceso de representación / diseño?

De todos modos, es probable que se DOMContentLoaded después de DOMContentLoaded , probablemente debido a que IE decide actualizar el readyState del document para "completar".

(Si alguien tiene una respuesta definitiva, publique un comentario y actualizaré esta respuesta; me encantaría saber exactamente cuándo me despido, y no puedo encontrar esa respuesta en ninguna documentación ni en ningún sitio que pueda esperar). En modo capricho.)