2010-12-09 9 views
58

Si la etiqueta del script está por encima o por debajo del cuerpo en una página HTML, ¿es importante para el rendimiento de un sitio web?¿La posición de la etiqueta <script> en HTML afecta el rendimiento de la página web?

Y lo que si se utiliza en el medio como éste:

<body> 
..blah..blah.. 
<script language="JavaScript" src="JS_File_100_KiloBytes"> 
function f1() { 
.. some logic reqd. for manipulating contents in a webpage 
} 
</script> 
... some text here too ... 
</body> 

O es mejor esto ?:

<script language="JavaScript" src="JS_File_100_KiloBytes"> 
function f1() { 
.. some logic reqd. for manipulating contents in a webpage 
} 
</script> 
<body> 
..blah..blah.. 
..call above functions on some events like onclick,onfocus,etc.. 
</body> 

O esta otra ?:

<body> 
    ..blah..blah.. 
    ..call above functions on some events like onclick,onfocus,etc.. 
<script language="JavaScript" src="JS_File_100_KiloBytes"> 
    function f1() { 
    .. some logic reqd. for manipulating contents in a webpage 
    } 
    </script> 
    </body> 

no necesito decirle que todo está de nuevo en la etiqueta <html> !!

¿Cómo afecta el rendimiento de la página web durante la carga? ¿Realmente? ¿Cuál es el mejor, ya sea de estos 3 o de otro que conoces?

Y una cosa más, he buscado en Google un poco en esto, de la que fui aquí: Best Practices for Speeding Up Your Web Site y sugiere put scripts at the bottom, pero, tradicionalmente, mucha gente puso en <head> etiqueta que está por encima de la etiqueta <body>. Sé que NO es una regla, pero muchos lo prefieren de esa manera. Si no lo crees, solo ver fuente de esta página! Y dime cuál es el mejor estilo para un mejor rendimiento.

+0

duplicado posible de [JavaScript etiquetas, rendimiento y W3C] (http://stackoverflow.com/questions/2812496/javascript-tags-performance-and-w3c). –

+0

Creo que esto ya se discutió en SO ver [aquí] (http://stackoverflow.com/questions/496646/how-does-the-location-of-a-script-tag-in-a-page-affect- a-javascript-function-that) y [aquí también] (http://stackoverflow.com/questions/2812496/javascript-tags-performance-and-w3c). – Pratik

Respuesta

58

Los activos de Javascript, por defecto, tienden a bloquear cualquier otra descarga paralela. Entonces, puede imaginarse si tiene muchas etiquetas <script> en la cabeza, la invocación de varias secuencias de comandos externas bloqueará la carga del HTML, saludando al usuario con una pantalla blanca en blanco, porque ningún otro contenido en su página cargará hasta los archivos JS se han cargado por completo.

Para combatir este problema, muchos desarrolladores han optado por colocar JS en la parte inferior de la página HTML (antes de la etiqueta </body>). Esto parece lógico porque, la mayoría de las veces, JS no es necesario hasta que el usuario comienza a interactuar con el sitio. Colocar los archivos JS en la parte inferior también permite una representación progresiva.

O bien, puede optar por cargar archivos Javascript de forma asincrónica. Hay un montón de métodos existentes que esto se puede conseguir por:

XHR Eval

var xhrObj = getXHRObject(); 
xhrObj.onreadystatechange = 
    function() { 
    if (xhrObj.readyState != 4) return; 
    eval(xhrObj.responseText); 
    }; 
xhrObj.open('GET', 'A.js', true); 
xhrObj.send(''); 

Guión DOM Element

var se = document.createElement('script'); 
se.src = 'http://anydomain.com/A.js'; 
document.getElementsByTagName('head') 
[0].appendChild(se); 

Meebo iframes JS

var iframe = document.createElement('iframe'); 
document.body.appendChild(iframe); 
var doc = iframe.contentWindow.document; 
doc.open().write('<body onload="insertJS()">'); 
doc.close(); 

Para nombrar unos pocos ...

Nota: Solo se pueden cargar un máximo de cinco scripts en paralelo en los navegadores actuales.


Para IE no es el defer atributo que puede utilizar de esta manera:

<script defer src="jsasset.js" type="text/javascript"></script> 

Cuando se establece, este atributo booleano proporciona una pista para el agente de usuario que la secuencia de comandos no se va para generar cualquier contenido de documento (por ejemplo, no "document.write" en javascript) y por lo tanto, el agente de usuario puede continuar analizar un documento nd representación.

+0

¿Qué sucede si dos archivos js provienen de rutas o servidores diferentes, incluso pueden cargarse simultáneamente? – Pratik

+0

@Rahul Joshi Por supuesto. Los sitios de alto tráfico generalmente tienden a invertir en una red de entrega de contenido, que es un dominio sin cookies destinado a contenido estático. Entonces, sí dos archivos js pueden provenir de diferentes servidores, aunque el tiempo de carga dependerá del servidor en cuestión. –

+0

¿Pero puede ser simultáneo, reduciendo así el tiempo total? – Pratik

15

Los elementos de script en la parte superior del documento están disponibles antes (para que pueda vincular manejadores de eventos y ejecutar JS tan pronto como un elemento esté disponible), pero bloquean el análisis del resto de la página.

Los elementos de script en la parte inferior no son (por lo que no se puede) y no hay ninguna página importante, por lo que no importa si eso está bloqueado.

¿Qué es mejor depende de la relativa importancia prioridad (que tiene que ser determinada sobre una base caso por caso) de tener el funcionamiento JS vs. tener la representación de HTML.

Tenga en cuenta que un elemento de script en la parte inferior debe aparecer dentro de elemento del cuerpo. Por lo que debe ser:

<script>...</script></body></html> 

y no

</body><script>...</script></html> 
1

Rendimiento de la escritura sí mismo sin duda será el mismo.

Sin embargo, la ubicación es importante, como se explica en el artículo vinculado, ya que el navegador "detendrá" (o "congelará") descargas simultáneas y renderización de la página cuando encuentre y cargue el contenido de una etiqueta <script>. Por lo tanto, probablemente sea mejor dejar que el navegador represente la página y aplicar estilos CSS, y luego incluyen su .js. Se verá más suave para el usuario.

Además, incluir el script en la parte inferior probablemente significa que está justo antes de cerrar la etiqueta <body>.

5

Sí, afecta el rendimiento de la carga de la página web.

El problema es que las etiquetas <script> normales están bloqueadas, por lo que todo después de la etiqueta del script debe esperar hasta que la etiqueta del script se termine de cargar y analizar antes de que se cargue el resto de la página.

Ahora alguien probablemente notará que si usa async="true" en la etiqueta del script, no se bloqueará. Pero eso solo cuenta con el respaldo de un par de navegadores, por lo que eso no ayudará al caso general aún.

De cualquier manera, en general, es una buena idea colocar las etiquetas de script en la parte inferior de la página para que no contengan otras partes de la página.

+0

La posición de la secuencia de comandos no afecta la velocidad de carga de la página; esto depende de su conexión a Internet. En realidad, afecta el rendimiento percibido: los elementos visibles de la página se cargan primero (en lugar de tener que esperar a que se cargue un script), por lo que parece que la página se carga más rápido de lo habitual, mientras que en realidad lleva el mismo tiempo. – whostolemyhat

+0

@What: no del todo cierto, lamentablemente, ya que bloquea su navegador para que no cargue otros archivos mientras carga la etiqueta del script, la página se carga más despacio. Mientras se carga, la página no podrá cargar las imágenes mientras que normalmente se podrían cargar en paralelo durante toda la carga de la página. – Wolph

11

Sí, afecta el rendimiento de la página web.

El problema con JavaScript es que bloquea la ejecución/carga del resto de la página.Si usted tiene algo que lleva mucho tiempo en su Javascript a continuación, se evitará que el resto de la página se cargue:

ver a estos ejemplos:

Se puede ver la efe ct la alerta tiene sobre la representación del resto de la página. Cualquier JavaScript que pongas en la parte superior de tu página tendrá el mismo efecto. En general, es mejor poner algo crítico para el diseño de su página (es decir, complementos de menú o algo así). Cualquier cosa que requiera una interacción del usuario (controladores de ventanas emergentes) o que no involucre al usuario en absoluto (Google Analytics) debe ir al final de la página.

Puede obtener cargadores perezosos que inyectarán sus etiquetas script en su código. Como el código no está en el HTML, puede estar seguro de que toda su página se ha procesado correctamente y que el JS que está incluyendo no bloqueará nada.

+0

En Safari 8 cada uno de esos ejemplos es exactamente el mismo y la alerta bloquea todo. –

4

En primer lugar, las etiquetas de scripts que no están dentro de los elementos de cuerpo/cabeza crean HTML no válido e incluso pueden causar algunas excepciones en algunos navegadores.

Las etiquetas de script dentro del elemento principal se cargarán e interpretarán antes de que se represente HTML, esto bloquea la representación de HTML/CSS.

Las etiquetas de scripts en la parte inferior de la etiqueta del cuerpo, no bloquearán HTML/CSS y ya que solo puedes jugar con el DOM en DomReady, esta es la mejor posición para poner tu JavaScript. Como nota al margen, ni siquiera necesitará usar un contenedor de eventos domReady.

Alternativamente, también puede utilizar bibliotecas como LABJS y RequireJS para arrancar su JavaScript de la etiqueta principal (mínimo bloqueo HTML/CSS). Cualquier secuencia de comandos cargada a través de cualquiera de estas bibliotecas se ejecutará en paralelo a la representación de HTML/CSS.

<head> 
    <script data-main="INITSCRIPT.js" src="require.js"></script> 
</head> 

INITSCRIPT.js

require([ "jQuery" , "somePlugin" ] , function(){ 
    $(document).ready(function(){ 
     $("#someId").somePlugin(); 
    }); 
}); 

En el ejemplo anterior, sólo la carga y la interpretación de require.js bloquearán representación HTML/CSS, que por lo general es insignificante. Después de lo cual jQuery y somePlugin se cargarán en paralelo, por lo que HTML/CSS se renderizará muy bien.

14

así que sé que esto es una vieja discusión, pero he estado leyendo acerca de este tema y la lectura de otras respuestas en StackOverflow ...

En realidad, no importa donde se coloca la etiqueta de jQuery ya:

Finalmente, una palabra sobre el folclore persistente. Es posible que haya encontrado el consejo que se repite con frecuencia para "colocar siempre JavaScript en el , en la parte inferior de la página, justo antes de la etiqueta de cierre". Esto fue una vez verdadero porque los navegadores web cargaron scripts secuencialmente y bloquearon cargando y renderizando hasta que se completó cada script.Esto no es más cierto; los navegadores modernos realizan un "escaneo previo" y comienzan a cargar todos los scripts en paralelo, ya sea que estén listados en el elemento principal o en el en la parte inferior de la página. El JavaScript externo a menudo se carga asincrónicamente y se escribe para que no se ejecute hasta que la página se cargue y el DOM esté listo. Cargando una secuencia de comandos en el elemento principal ya no es una mala práctica .

http://railsapps.github.io/rails-javascript-include-external.html

+1

Antes de tener que preocuparse por la colocación de la etiqueta '

-1

Junto con el aspecto de rendimiento, también es necesario tener cuidado cuando se incluye la etiqueta <script> dentro de la etiqueta <head>.

Consideremos el siguiente ejemplo:

<head> 
<script>document.getElementById("demo").innerHTML="hello";</script> 
</head> 
<body> 
<p id="demo">The content of the document......</p> 
</body> 

Aquí, observe que la secuencia de comandos se carga antes de que el DOM (o la etiqueta <p>) se carga, lo que provoca un fallo en el guión (Desde el getElemenById puedo encontrar el elemento con el nombre 'demo').

En tales casos, solo debe usar el script dentro de la etiqueta del cuerpo.

Considerando las otras respuestas, es mejor tener la secuencia de comandos siempre antes de la etiqueta </body>, ya que nunca se sabe si las secuencias de comandos que se cargarían externamente tienen tales dependencias en su DOM.

Referencia: Detailed problem description

Cuestiones relacionadas