script representar qué para llamar insertar etiqueta emplea ejemplos documento desde cómo código bloque archivo apertura javascript html performance optimization

javascript - representar - ¿La posición de la etiqueta<script> en HTML afecta el rendimiento de la página web?



qué etiqueta de html se emplea para representar la apertura de un bloque de código javascript (8)

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?

Y qué pasa si se usa en medio de esta manera:

<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 esto mejor ?:

<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 este?:

<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 es necesario que diga 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, busqué en Google un poco sobre esto, de la cual fui aquí: Mejores prácticas para acelerar su sitio web y sugiere poner guiones en la parte inferior , pero tradicionalmente muchas personas lo ponen en la etiqueta <head> que está por encima del etiqueta <body> Sé que NO es una regla, pero muchos lo prefieren de esa manera. ¡Si no lo crees, solo ve el origen de esta página! Y dime cuál es el mejor estilo para un mejor rendimiento.


Así que sé que esta es una discusión antigua, pero he estado leyendo sobre este tema y leyendo otras respuestas en ...

En realidad, ya no importa dónde coloque la etiqueta jQuery:

Finalmente, una palabra sobre folklore persistente. Es posible que haya encontrado los consejos que se repiten con frecuencia para "colocar siempre JavaScript en la parte inferior de la página justo antes de la etiqueta de cierre". Esto fue una vez cierto porque los navegadores web cargaron los scripts secuencialmente y bloquearon la carga y el procesamiento hasta que se completó cada script. Esto ya no es verdad; los navegadores modernos realizan el "escaneo precargado" y comienzan a cargar todos los guiones en paralelo, ya sea que figuren en el encabezado o en la parte inferior de la página. El JavaScript externo a menudo se carga de forma asíncrona y se escribe para que no se ejecute hasta que se cargue la página 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


En primer lugar, las etiquetas de script 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 secuencia de comandos en la parte inferior de la etiqueta de cuerpo, no bloquearán HTML / CSS y, dado que solo puedes jugar con 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 usar bibliotecas como LABJS y RequireJS para iniciar su JavaScript desde 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, solo la carga e interpretación de require.js bloqueará la representación HTML / CSS, que generalmente es insignificante. Después de lo cual jQuery y somePlugin se cargarán en paralelo, por lo que HTML / CSS se renderizará muy bien.


Junto con el aspecto de rendimiento, también debe tener cuidado siempre que incluya 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 el script se carga antes de que se cargue DOM (o la etiqueta <p> ), lo que provoca un error en el script (dado que getElementById no puede encontrar el elemento con el nombre ''demo'').

En tales casos, debe usar el script únicamente dentro de la etiqueta body.

Teniendo en cuenta las otras respuestas, es mejor tener el script 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: descripción detallada del problema


La ejecución del guión en sí será definitivamente la misma.

Sin embargo, la ubicación es importante, tal como se explica en el artículo que ha 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 incluir su .js . Se verá más suave para el usuario.

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


Los activos de Javascript, por defecto, tienden a bloquear cualquier otra descarga paralela. Entonces, puede imaginarse si tiene muchas etiquetas <script> en la cabeza, al invocar múltiples scripts externos se bloqueará la carga del HTML , saludando al usuario con una pantalla blanca en blanco, porque ningún otro contenido en su página se 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.

Alternativamente, puede optar por cargar archivos Javascript de forma asincrónica. Hay muchos métodos existentes que esto se puede lograr mediante:

XHR Eval

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

Elemento DOM de script

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

Meebo Iframed 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 existe el atributo defer que puede usar así:

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

Cuando se establece, este atributo booleano proporciona una pista al agente de usuario de que el script no generará ningún contenido de documento (por ejemplo, no "document.write" en javascript) y, por lo tanto, el agente de usuario puede continuar el análisis y la representación.


Los elementos de script en la parte superior del documento están disponibles antes (para que pueda vincular los manejadores de eventos y hacer que JS se ejecute 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 queda ninguna página significativa, por lo que no importa si eso está bloqueado.

Lo mejor depende de lo relativo importancia prioridad (que debe determinarse caso por caso) de tener el JS corriendo vs. tener la representación de HTML.

Tenga en cuenta que un elemento script en la parte inferior debe aparecer dentro del elemento body. Entonces debería ser:

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

y no

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


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

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

Ahora, es probable que alguien tenga en cuenta 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.


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 tienes algo que lleva mucho tiempo en tu JavaScript, evitará que se cargue el resto de la página:

Vea estos ejemplos:

Puede ver el efecto que tiene la alerta en 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 inyecten las etiquetas de 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.