jQuery: ¿Mover JavaScript al final de la página?

Estamos desarrollando grandes aplicaciones ASP.NET con muchas páginas creadas dinámicamente que contienen controles ASCX. Usamos mucho jQuery en todas partes.jQuery: ¿Mover JavaScript al final de la página?

He estado leyendo que tendría sentido mover el código JavaScript en línea al final de la página, ya que podría retrasar la carga de la página cuando se incluye "demasiado pronto".

Mi pregunta es ahora: ¿Esto todavía tiene sentido cuando se trabaja con jQuery?

La mayor parte del código se ejecuta en el controlador de lista, así que supongo que no se ralentiza la carga de la página. En mi caso, los múltiples controles de usuario ASCX tienen todos sus propios jQuery bits y piezas, y no sería fácil mover todo hacia abajo en la página representada.

Fuente

2008-11-24 PeterFromCologne

Cualquier razón por la cual sus llamadas listas aren ¿en un archivo externo también? Es mucho más manejable que tener esas llamadas en línea. –

¿Hay algo más que esperaras ver en las respuestas? Parece una pena dejar un hilo colgado así ... :-) –

Lo que estaba buscando cuando encontré este hilo fue cómo conseguir que ASP.NET ScriptManager ponga las referencias js en la parte inferior de la página. Parece algo que querrías si tienes un código que usa esto. –

Puede modelar las diferentes formas de ordenar el JavaScript en Cuzillion para ver cómo afecta la carga de la página.

Consulte examples y this blog post para ver ejemplos de cómo el orden de los elementos de página puede afectar la velocidad.

Fuente

2008-11-24 20:03:41

-2

La mayoría de las veces, la razón para mover su JavaScript al final de la página es asegurarse de que cualquier elemento DOM que el JavaScript pueda referencia haya sido creado antes de que se ejecute JavaScript. Esto también asegura que la página tenga tiempo de renderizar antes de ejecutar cualquier JavaScript.

En este caso, no me preocuparía mover el JavaScript hacia abajo en la página.

Fuente

2008-11-24 22:46:34 ScottKoon

eso no es verdad. La razón para ponerlo en la parte inferior es para que el contenido de la página se cargue primero y no deje al usuario mirando una pantalla en blanco mientras se descargan 200kb de scripts. – nickf

Scott, esa es la razón más obvia (y, por lo tanto, la más común), verdadera. Sin embargo, como señala el póster, la disponibilidad de los manejadores de documentos ya no es un problema. Lo que queda es el problema de rendimiento de carga de la página. Nickf tiene toda la razón. –

No se puede manipular el DOM de todos modos (seguro) antes de que se active la página OnLoad, ya que activará excepciones en algunos navegadores ... Así que esta es una afirmación completamente falsa ... (perdón, -1, mi primera ...) –

Se recomienda colocar scripts al final del proceso porque cargar y ejecutar scripts se realiza de forma secuencial (un script a la vez) y bloquea por completo la carga y el análisis de imágenes y archivos CSS mientras tanto.

Los scripts grandes/rezagados/de ejecución lenta cerca de la parte superior de la página pueden causar demoras innecesarias en la carga y representación del contenido/diseño de la página.

El tamaño del script (tiempo de descarga) y la complejidad (tiempo de ejecución (dom crossing, etc.)) son factores importantes, pero más importante aún, el número de solicitudes HTTP <script> importa mucho (menos solicitudes, mejor).

El uso del controlador "document.ready" reduce el retraso causado por la ejecución lenta, pero deja el problema de la sobrecarga HTTP secuencial.

Lectura recomendada: High Performance Web Sites por Nate Koeckley.

Fuente

2008-11-24 23:25:27

Recuerde que el paralelismo normalmente es bueno. Los scripts no se encuentran necesariamente en el mismo servidor que el HTML y CSS e imágenes. Además, si el navegador siente que los tubos están obstruidos, simplemente no puede solicitar el script. Cuanto antes el navegador tenga información de secuencia de comandos, más rápido podrá ponerla en cola/enhebrarla. – strager

Los scripts bloquean la carga de otros objetos, independientemente del servidor en el que se encuentren. Lea la literatura de rendimiento. Me opongo a la votación, por cierto. –

@strager: "si el navegador siente que los tubos están obstruidos, simplemente no puede solicitar el script". ¿Cuidado para elaborar? No he visto esa característica en ningún navegador, nunca. (Depende del navegador analizar la página y hacer una lista de recursos adicionales (imágenes, estilos, secuencias de comandos) para descargar. Es __NOT__ hasta el navegador para decidir "oh, simplemente no * siento * como descargando * that * ".) – Piskvor

Cuando incluye JS, la carga de la página desde ese punto se aplazará debido a que el archivo JS podría contener una declaración "document.write".

Esto significa que la página completa se DETECTARÁ desde el punto donde incluye sus archivos JS y hace que el navegador se ponga "blanco" o algo así (al menos no muestre el resto de la página) por lo que la respuesta corta es Definitivamente sí ...!

(Respuesta larga es "probablemente" con un 99% de probabilidad)

Como en movimiento la inclusión de JS (y también JS en línea - lo que no se debe utilizar por cierto) a la parte inferior ...

Cuando lo que se dice si estás en ASP.NET no se debe utilizar jQuery, sino más bien que por cierto Ra-Ajax tener todas estas "mejores prácticas" automágicamente incluidos para usted ...

Fuente

2008-11-25 00:43:30

Sé que esta es una publicación anterior en este momento, y podría haber sido válida en ese momento, pero debido a que el proyecto del sitio web de plantilla en Visual Studio 2010 incluye jQuery, no hay ninguna razón para desalentar el uso de jQuery en combinación con .RED. – vpiTriumph

jQuery: ¿Mover JavaScript al final de la página?

Respuesta

Cuestiones relacionadas