$ .ready() antes de cerrar el cuerpo

Question

Esto no es una pregunta de codificación real, más que una afirmación del mundo real.

He anteriormente noted que DOMReady eventos son lentos, muy lentos. Por lo tanto, al navegar por la fuente jQuery noté que el evento jQuery domeready se puede activar usando $.ready(). Entonces pensé, colocando este sencillo script de ejecución justo antes de cerrar el cuerpo debería disparar a todos los oyentes "onDomReady" que estaban adjuntos previamente. Y sí, funciona como se esperaba:

 <script>$.ready()</script> 
</body> 

Éstos son dos ejemplos, éste mide el ms gastado a la espera de domready:

http://jsbin.com/aqifon/10

Como se puede ver, el gatillo domready es muy de forma nativa lento, el usuario tiene que esperar para un conjunto 200-300 milisegundos antes del inicio de la escritura domready en

de todos modos, si colocamos $.ready() justo antes de cerrar la etiqueta BODY obtenemos la siguiente:.

http://jsbin.com/aqifon/16

ver la diferencia? Al activarlo manualmente, podemos cortar 100-300 ms de retraso de ejecución. Este es un gran negocio, porque podemos confiar en jQuery para que se encargue de las manipulaciones DOM antes de que las veamos.

Ahora, a una pregunta, nunca he visto esto siendo recomendado o discutido antes, pero todavía parece ser un problema de rendimiento importante. Todo se trata de optimizar el código en sí, lo cual es bueno, por supuesto, pero es en vano si la ejecución se demora tanto tiempo que el usuario ve un "flash of" unjQueryedContent ".

Alguna idea de por qué esto es no discutido/recomendado con más frecuencia?

Answer 1

¿Alguna idea de por qué esto no se discute/recomienda con más frecuencia?

Colocando JavaScript justo antes de </body> se ha discutido mucho, y como saben, se recomienda si está buscando cargas de página más rápidas. La activación manual de los manejadores jQuery ready de hecho es poco discutida. ¿Por qué?Bueno, yo no creo que haya una sola respuesta objetiva a eso, pero voy a tratar de esbozar algunas posibilidades:

1. El rendimiento no es el objetivo principal de jQuery (anthough es definitivamente una preocupación), y los fanáticos del rendimiento por lo general buscarán bibliotecas más livianas para la manipulación de DOM entre exploradores y el manejo de eventos, o desplegarán los suyos propios.

2. Es un paso adicional, y no se ve limpio. jQuery intenta ser limpio y elegante, y recomendar un paso adicional para inicializar las secuencias de comandos no suena como algo que vaya a suceder. Recomiendan el enlace a ready, por lo que recomendamos forzar .ready() e ignorar el evento del navegador real que se ve "incorrecto". Quien esté preocupado probablemente sepa que inicializar scripts justo antes de </body> es más rápido.

3. Optimización DOMContentLoaded suena como una tarea para los vendedores de navegadores. No estoy seguro de por qué es más lento, y tal vez no hay mucho espacio para la optimización – en mi comprensión, llamar a los scripts init antes de </body> siempre debe ser la forma más rápida de inicializar cosas (ya que se ejecuta inmediatamente al analizar la etiqueta del contenedor <script>, mientras que los navegadores deben terminar de analizar todo el archivo antes de activar DOMContentLoaded).

Es probable que recordar que no hace mucho tiempo, era una práctica común tener <script> bloques dispersos por todas partes en el código HTML. Luego vino el movimiento de Estándares Web, y recomendó maneras más sanas y fáciles de mantener para hacer cosas. Eso incluía secuencias de comandos de arranque desde un solo lugar – inicialmente, window.onload, que luego se consideraba problemático por ser lento, luego DOMContentLoaded y sus emulaciones para IE8 y versiones inferiores. Sin embargo, todavía vemos spaghetti-HTML con scripts en todas partes a diario aquí en StackOverflow. Así que no estoy seguro de si recomendar la colocación de scripts antes del final del cuerpo es una buena decisión hoy, porque puede interpretarse como una licencia para agregar scripts en cualquier parte del cuerpo.

Finalmente, si realmente está preocupado por cargar su script rápidamente, y su código no manipula el DOM, la manera más rápida de cargarlo es ponerlo en el <head> antes de cualquier hoja de estilo. Y estoy diciendo eso solo para decir que no hay una solución mágica, no hay una forma óptima de iniciar scripts que sea la más rápida y elegante en cada escenario. Creo que es por eso que la comunidad se queda con la recomendación de algo que parece sano y tiende a crear un código más sostenible, en lugar de otras alternativas de mejor rendimiento.

Answer 2

Al activar el evento usted mismo, está indicando a sus controladores ready() que su dom ha sido cargado ¡PERO puede que no haya sido así! No hay cortocircuito en el evento listo para DOM. de hecho, hay un largo tiempo de espera, luego emplea las increíbles herramientas de depuración de Firebug, Chrome, etc. Revisa tus recursos y sus tiempos. Todo está allí en blanco y negro e indicará lo que está demorando tanto (las solicitudes , la representación, cuántos recursos, etc.)

Answer 3

En realidad, realizar una llamada a la función antes de la etiqueta </body> hace que no tenga sentido usar jQuery's ready(). Simplemente ponga la llamada a la función nativa JS-wrapper que contiene llamadas de todas las demás funciones que deben invocarse en documentos listos.

En general, es una alternativa que funciona (aunque algo ensucia el código HTML y, por lo tanto, es inaceptable para los perfeccionistas) para situaciones en las que el autor no necesita/desea utilizar jQuery. Sin embargo, en tales situaciones, preferiría utilizar el controlador de eventos DOMContentLoaded nativo que es compatible con la mayoría de los navegadores, incluido IE9 + (para IE8, podemos usar window.load() como una alternativa aceptable).