Es el evento DOMContentLoaded EXACTAMENTE el mismo como jQuery .ready() de la función?

He sustituido window.addEventListener('DOMContentLoaded', function() {}); con jQuery $(document).bind('ready', function() {});, porque primero uno no funcionan en IE < 9 y yo no quería jugar con .attachEvent() para que ficticio navegador, si yo pudiera tener esta bien cubierta por jQuery sí mismo.

Poco después de la sustitución, me di cuenta de que DOMContentLoaded evento siempre fue despedido alrededor de 0-2 milisegundos después de la carga de la página /actualizar (al menos esto es lo que se registra por mi registro de secuencia de comandos), mientras que .ready() siempre requiere al menos de 15 a 20 milisegundos, después de la actualización de la página, a ser despedido (de nuevo – como registra la secuencia de comandos).

Estoy pidiendo puramente para alimentar mi curiosidad, ¿por qué no es «significativo» de retraso? Por supuesto, no es ningún problema para mí, que jQuery es disparar ese evento posterior. Es justo, por que yo quiero saber TODAS las respuestas (y gobernar el mundo! :]), Yo no puedo dormir con eso! :]

EDITAR: en .listo() la función doc algunos de usuario (Nick (de Nexxar)) señala que: «jQuery que simula la no existente «DOMContentLoaded» evento en IE, pero utiliza el mecanismo de incendios mucho más tarde que el evento se utiliza en otros navegadores«. Tal vez esto es lo mismo que le estoy pidiendo?

InformationsquelleAutor trejder | 2012-07-17

3 Kommentare

  1. 21

    Suponiendo navegador que apoya el evento:

    1. El evento real que puede soportar cualquier document. jQuery sólo se hará uso de la document fue cargado, no importa lo que pase.
    2. jQuery desencadenará el evento de forma asincrónica, incluso si el evento ya ha ocurrido. Adjuntar 'DOMContentLoaded' evento va a hacer nada si el evento ya ha ocurrido.

    No hay ningún retraso en estos navegadores, consulte http://jsfiddle.net/rqTAX/3/ (los desplazamientos se registran son en milisegundos).

    Para los navegadores que no soportan el evento, jQuery, que obviamente va a trabajar para ellos. Se utilizará un hacky mecanismo que no es el mismo que el real DOMContentLoaded y no necesariamente el fuego tan pronto como el real DOMContentLoaded sería:

    //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();
    }
    • Si yo no estoy mal, su respuesta sólo se explica, ¿por qué no podría haber un retraso (cambio de hora, cuando el evento es disparado) en los navegadores que NO soporten DOMContentLoaded (como IE < 9). Pero he probado la cosa en un navegador que seguramente lo soporta (Chrome 20 y Firefox 13) y tiene retrasos de alrededor de 15-20 segundos en ambos navegadores.
    • lo siento, no estoy viendo nada de eso en absoluto. Consulte jsfiddle.net/rqTAX/3. Las diferencias son como de 5 a 20 milisegundos. En chrome y firefox
    • No hay necesidad para que lo siento! :] Solamente mi curiosidad. Tal vez me he perdido algo. Creo que podemos cerrar este tema, como para mí. Gracias!
    • así que al menos podría aceptar mi respuesta para la prestación de los 2 diferencias en la parte superior de que la mayoría de la gente no sabe nada 😉 por Cierto, usted debe utilizar $(document).ready en lugar de .bind, son muy diferentes.
    • Gracias por recordármelo, como yo estaba sure hice aceptado su respuesta! :] ¡Lo siento! Por CIERTO: ¿por Qué $(document).bind('ready', function() {}); y $(document).ready(function() {}); son tan diferentes?
    • el .bind versión no obtener jQuery como primer argumento de la función y también no funciona después de la DOMContentLoaded ha sucedido. Para perder estas ventajas. También es muy infrecuente, esta es la primera vez que lo veo.
    • Bueno… En, por ejemplo, .load() descripción del método hay una información: «Este método es un método abreviado para .bind('load', handler).«. Así, supuse que la misma relación va aquí. Que .ready(handler) es sólo un acceso directo para .bind('ready', handler).

  2. 4

    jQuery que simula este evento mediante la unión a la document‘s readystatechange evento, que es la forma estándar de la simulación de DOMContentLoaded en oldIE.

    De acuerdo a la fuente de jQuery, se dispara el evento «tarde» pero antes de window.onload. Sin embargo, no puedo encontrar cuando que se dispara el evento exactamente. DOMContentLoaded se desencadena cuando el DOM está construido y listo para secuencias de comandos, así que readystatechange incendios después de que, tal vez espera para la representación de diseño o estilo algo como eso, o se activa el evento más tarde en la representación de/proceso de diseño?

    Independientemente, es probable que el fuego después de DOMContentLoaded, probablemente debido a que cuando IE se decide a actualizar la document‘s readyState a «completo».

    (Si alguien tiene una respuesta definitiva, publicar un comentario y voy a actualizar esta respuesta; me gustaría saber cuando es exactamente lo que los incendios de mí mismo, y no puedo encontrar la respuesta en la documentación o en cualquiera de los sitios que yo esperaría como Quirksmode.)

    • OK, pero similar a la anterior. Usted es la mayoría hablando de IE. Y los mismos retrasos que sucede en los dos más recientes de Chrome y el más reciente de Firefox.
    • DOMContentLoaded sucede DESPUÉS de secuencias de comandos (regular y defered) se ejecutan (excepto async queridos)
  3. 1

    Otra razón por la que el «listo» que aparecen a fuego más tarde (en la práctica) es que puede haber muchos eventos enganchado a ella. Si alguno de estos son de larga ejecución de operaciones síncronas, a continuación, el evento listo vendrá mucho más tarde. Por ejemplo yo uso knockout.js y se puede tomar 500ms para inicializar la página.


    Sin embargo el uso de su mínimo de la prueba de la página que no es el caso, por supuesto. He intentado correr el siguiente :

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

    Esto da acerca de 6ms, incluso para su simple super página


    También tomé su código y corrió a través de Chrome herramientas de rendimiento y descubrí un par de cosas interesantes:

    Es el evento DOMContentLoaded EXACTAMENTE el mismo como jQuery .ready() de la función?

    • BTW: la vertical de La barra azul es DOMCONTENTLOADED y el verde es la ‘primera pintura’
    • Se puede ver incluso una super simple llamada a la función en el evento DOMCONTENTLOADED puede tomar 5ms (y esto es un i7). Recuerde que necesita ser analizada y las cosas que necesita inicializar.
    • Las devoluciones de llamada se muestran en el color cian (anónimo), la primera es desde el evento DOMCONTENTLOADED y el segundo es el «listo» de devolución de llamada.
    • Usted notará Contador ‘Despedido’ (es decir,setTimeout). Así que no es instantáneo por cualquier medio.

    Mirando el jQuery código fuente se ve que en realidad establecer 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 significan aquí (idea) – pero no explica el comportamiento. Pude ver que es útil para evitar condiciones de carrera, y el bloqueo de la interfaz de usuario, pero «retrasar listo» está claro para mí.

    • El setTimeout() es una solución para IE9-10 disparando el DOMContentLoaded evento antes de que añade un detector para él. El código comprueba si document.readyState ya se ha completado, a continuación, agrega un setTimeout() para empujar el jQuery.ready de devolución de llamada a la cola de eventos, dando tiempo para que el otro en la cola de async devoluciones de llamada de una oportunidad para ejecutar antes de jQuery.ready se ejecuta.
    • pero estoy usando Chrome! el tiempo es probablemente insignificante, pero estoy tratando de que el fuego de una SignalR conexión y la necesidad de que tan pronto como sea posible
    • Chrome controla correctamente, no disparar la DOMContentLoaded evento hasta que se alcanza el final de la </body> etiqueta. IE9-10 no, de modo que necesita una solución. El código jQuery comprueba esta en una instrucción if. Se gira de nuevo para el comportamiento apropiado si el document.readyState no está listo.
    • sí, es obras pero hay un retraso innecesario debido a que el temporizador. tal vez hay algún tipo de condición de carrera pasando, pero me pareció más rápido para poner mi SignalR código de inicialización en mi propia DOMContentLoaded como solo necesito el apoyo de los navegadores modernos
    • Eso es probablemente debido a que el análisis de jQuery en sí, que es 84KB.
    • También, no es probable que el uso de las devtools para controlar este frena así?
    • el Dev tools aquí fue más para mostrar que algo sucede en el medio. La ventana de tiempo de rendimiento de los valores de no ser afectados por tener herramientas de encendido.

Kommentieren Sie den Artikel

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein

Pruebas en línea