¿Dónde debo poner las etiquetas <script> en el marcado HTML?


1488

Al incrustar JavaScript en un documento HTML, ¿dónde está el lugar adecuado para colocar las <script>etiquetas y el JavaScript incluido? Me parece recordar que se supone que no debes colocarlos en la <head>sección, pero colocarlos al comienzo de la <body>sección también es malo, ya que el JavaScript tendrá que analizarse antes de que la página se represente por completo (o algo así). Esto parece dejar el final de la <body>sección como un lugar lógico para las <script>etiquetas.

Entonces, ¿dónde está el lugar correcto para colocar las <script>etiquetas?

(Esta pregunta hace referencia a esta pregunta , en la que se sugirió que las llamadas a funciones de JavaScript deberían moverse de <a>etiquetas a <script>etiquetas. Estoy usando específicamente jQuery, pero también son apropiadas respuestas más generales).


en caso de que también esté buscando una solución simple y esté utilizando un generador del lado del servidor como Jekyll, le recomiendo incluir el script con él. mucho más simple!
cregox

Respuestas:


1864

Esto es lo que sucede cuando un navegador carga un sitio web con una <script>etiqueta:

  1. Obtener la página HTML (por ejemplo, index.html)
  2. Comience a analizar el HTML
  3. El analizador encuentra una <script>etiqueta que hace referencia a un archivo de script externo.
  4. El navegador solicita el archivo de script. Mientras tanto, el analizador bloquea y deja de analizar el otro HTML en su página.
  5. Después de un tiempo, el script se descarga y posteriormente se ejecuta.
  6. El analizador continúa analizando el resto del documento HTML.

El paso 4 causa una mala experiencia del usuario. Su sitio web básicamente deja de cargarse hasta que haya descargado todos los scripts. Si hay algo que los usuarios odian, está esperando que se cargue un sitio web.

¿Por qué sucede esto?

Cualquier script puede insertar su propio HTML a través de document.write()u otras manipulaciones DOM. Esto implica que el analizador tiene que esperar hasta que la secuencia de comandos se haya descargado y ejecutado antes de poder analizar de forma segura el resto del documento. Después de todo, el script podría haber insertado su propio HTML en el documento.

Sin embargo, la mayoría de los desarrolladores de JavaScript ya no manipulan el DOM mientras se carga el documento. En cambio, esperan hasta que se haya cargado el documento antes de modificarlo. Por ejemplo:

<!-- index.html -->
<html>
    <head>
        <title>My Page</title>
        <script src="my-script.js"></script>
    </head>
    <body>
        <div id="user-greeting">Welcome back, user</div>
    </body>
</html>

Javascript:

// my-script.js
document.addEventListener("DOMContentLoaded", function() { 
    // this function runs when the DOM is ready, i.e. when the document has been parsed
    document.getElementById("user-greeting").textContent = "Welcome back, Bart";
});

Debido a que su navegador no sabe que my-script.js no va a modificar el documento hasta que se haya descargado y ejecutado, el analizador deja de analizarlo.

Recomendación anticuada

El viejo enfoque para resolver este problema era colocar <script>etiquetas en la parte inferior de su <body>, porque esto asegura que el analizador no esté bloqueado hasta el final.

Este enfoque tiene su propio problema: el navegador no puede comenzar a descargar los scripts hasta que se analice todo el documento. Para sitios web más grandes con grandes scripts y hojas de estilo, poder descargar el script lo antes posible es muy importante para el rendimiento. Si su sitio web no se carga en 2 segundos, las personas irán a otro sitio web.

En una solución óptima, el navegador comenzará a descargar sus scripts lo antes posible, mientras que al mismo tiempo analiza el resto de su documento.

El enfoque moderno

Hoy en día, los navegadores admiten los atributos asyncy deferen los scripts. Estos atributos le dicen al navegador que es seguro continuar analizando mientras se descargan los scripts.

asíncrono

<script src="path/to/script1.js" async></script>
<script src="path/to/script2.js" async></script>

Las secuencias de comandos con el atributo asincrónico se ejecutan de forma asincrónica. Esto significa que el script se ejecuta tan pronto como se descarga, sin bloquear el navegador mientras tanto.
Esto implica que es posible descargar y ejecutar el script 2 antes del script 1.

Según http://caniuse.com/#feat=script-async , el 97.78% de todos los navegadores lo admiten.

aplazar

<script src="path/to/script1.js" defer></script>
<script src="path/to/script2.js" defer></script>

Las secuencias de comandos con el atributo de aplazamiento se ejecutan en orden (es decir, primera secuencia de comandos 1, luego secuencia de comandos 2). Esto tampoco bloquea el navegador.

A diferencia de los scripts asíncronos, los scripts diferidos solo se ejecutan después de que se haya cargado todo el documento.

De acuerdo con http://caniuse.com/#feat=script-defer , el 97.79% de todos los navegadores lo admiten. El 98.06% lo respalda al menos parcialmente.

Una nota importante sobre la compatibilidad del navegador: en algunas circunstancias, IE <= 9 puede ejecutar scripts diferidos fuera de servicio. Si necesita soportar esos navegadores, ¡lea esto primero!

Conclusión

El estado actual de la técnica es colocar scripts en la <head>etiqueta y usar los atributos asynco defer. Esto permite que sus scripts se descarguen lo antes posible sin bloquear su navegador.

Lo bueno es que su sitio web aún debe cargarse correctamente en el 2% de los navegadores que no admiten estos atributos mientras acelera el otro 98%.


63
Me sorprende que nadie haya mencionado la explicación de Google ... developers.google.com/speed/docs/insights/BlockingJS
Casey Falk

66
No tengo claro qué toca el DOM y qué no. ¿Puedes aclarar? ¿Es seguro hacer una carga asíncrona en algo como jquery.js?
Doug

77
@Doug Por ejemplo, document.writeopera en el dom. La pregunta no es si un script manipula el dom, sino cuándo lo hace. Mientras toda la manipulación dom ocurra después de que el domreadyevento se haya disparado, estás bien. jQuery es una biblioteca y, como tal, no manipula el dom por sí mismo.
Bart

24
Esta respuesta es engañosa. Los navegadores modernos no dejan de analizar cuando alcanzan una etiqueta de script síncrono que puede afectar el HTML, simplemente dejan de procesar / ejecutar y continúan analizando de manera optimista para comenzar a descargar otros recursos que probablemente se solicitarán posteriormente si no se ve afectado el HTML.
Fabio Beltramini

40
¿Por qué los atributos asyncy deferno se usan en ninguna parte? Quiero decir, vi muchas fuentes HTML de Internet, y no veo los atributos asyncy en deferninguna parte. ...?
John Cj

239

Justo antes de la etiqueta de cierre del cuerpo, como se indica en

http://developer.yahoo.com/performance/rules.html#js_bottom

Poner guiones en la parte inferior

El problema causado por los scripts es que bloquean las descargas paralelas. La especificación HTTP / 1.1 sugiere que los navegadores descarguen no más de dos componentes en paralelo por nombre de host. Si publica sus imágenes desde múltiples nombres de host, puede obtener más de dos descargas en paralelo. Sin embargo, mientras se descarga un script, el navegador no iniciará ninguna otra descarga, incluso en diferentes nombres de host.


77
De acuerdo con el concepto y su explicación. Pero, ¿qué sucede si el usuario comienza a jugar con la página? Supongamos que tengo un menú desplegable AJAX que comenzará a cargarse después de que la página haya aparecido para el usuario, pero mientras se carga, ¡el usuario hace clic en ella! ¿Y qué pasa si un usuario 'realmente impaciente' envía el formulario?
Hemant Tank el

99
@Hermant Comentario anterior, pero puede hacer el truco deshabilitando los campos de forma predeterminada y luego habilitándolos utilizando JS cuando el DOM está completamente cargado. Eso es lo que parece estar haciendo Facebook hoy en día.
novato

2
Acabo de probar esto con Chrome, para comprobar si sigue siendo el mismo. Es. Puede verificar las diferencias en el tiempo de carga de la página de sus navegadores aquí. stevesouders.com/cuzillion
cypher

46
Si esta es la mejor práctica, ¿por qué el desbordamiento de pila incluye todas sus etiquetas de script en <head>? :-P
Philip

10
En algunos casos, especialmente en sitios pesados ​​de ajax, la carga en la cabeza puede resultar en tiempos de carga más rápidos. Consulte: encosia.com/dont-let-jquerys-document-ready-slow-you-down (tenga en cuenta que la función "live ()" está en desuso en jquery, pero el artículo aún se aplica con "on ()" o " delegar "función). La carga en <head> también puede ser necesaria para garantizar un comportamiento correcto como lo señala @Hermant. Finalmente, modernizr.com/docs recomienda colocar sus scripts en <head> por los motivos explicados en su sitio.
Nathan

77

Las etiquetas de script sin bloqueo se pueden colocar en casi cualquier lugar:

<script src="script.js" async></script>
<script src="script.js" defer></script>
<script src="script.js" async defer></script>
  • async el script se ejecutará de forma asíncrona tan pronto como esté disponible
  • defer el script se ejecuta cuando el documento ha terminado de analizar
  • async defer el script vuelve al comportamiento diferido si no se admite la sincronización

Tales scripts se ejecutarán de forma asíncrona / después de que el documento esté listo, lo que significa que no puede hacer esto:

<script src="jquery.js" async></script>
<script>jQuery(something);</script>
<!--
  * might throw "jQuery is not defined" error
  * defer will not work either
-->

O esto:

<script src="document.write(something).js" async></script>
<!--
  * might issue "cannot write into document from an asynchronous script" warning
  * defer will not work either
-->

O esto:

<script src="jquery.js" async></script>
<script src="jQuery(something).js" async></script>
<!--
  * might throw "jQuery is not defined" error (no guarantee which script runs first)
  * defer will work in sane browsers
-->

O esto:

<script src="document.getElementById(header).js" async></script>
<div id="header"></div>
<!--
  * might not locate #header (script could fire before parser looks at the next line)
  * defer will work in sane browsers
-->

Dicho esto, los scripts asíncronos ofrecen estas ventajas:

  • Descarga paralela de recursos : el
    navegador puede descargar hojas de estilo, imágenes y otras secuencias de comandos en paralelo sin esperar a que se descargue y ejecute una secuencia de comandos.
  • Independencia del orden de origen :
    puede colocar las secuencias de comandos dentro de la cabeza o el cuerpo sin preocuparse por el bloqueo (útil si está utilizando un CMS). Sin embargo, la orden de ejecución sigue siendo importante.

Es posible eludir los problemas de orden de ejecución mediante el uso de scripts externos que admiten devoluciones de llamada. Muchas API de JavaScript de terceros ahora admiten la ejecución sin bloqueo. Aquí hay un ejemplo de cómo cargar la API de Google Maps de forma asincrónica .


2
Esta es la respuesta correcta para hoy: el uso de este enfoque significa que es más fácil mantener sus widgets autónomos, no es necesario <head>incluir una lógica de inclusión sofisticada .
Daniel Sokolowski

1
Estoy confundido por qué no se puede utilizar asynco defercuando se incluye jQuery como se especifica en el segundo bloque: <script src="jquery.js" async></script>. ¿Eres capaz de explicar por qué? Pensé que necesitaba tener la etiqueta asíncrona para el rendimiento, según la respuesta aceptada, para que mi página se pueda cargar incluso mientras jQuery todavía se está cargando]. ¡Gracias!
elbowlobstercowstand

3
@elbow el 99% de las veces <script src=jquery.js>es seguido por $(function(){ ... })bloques en algún lugar de la página. La carga asincrónica no garantiza que jQuery se cargará en el momento en que el navegador intente analizar esos bloques, por lo tanto, generará un error $ no definido (es posible que no obtenga el error si jQuery se cargó de la memoria caché). Respondí una pregunta sobre cómo cargar jQuery de forma asincrónica y preservar $(function(){ ... }). Veré si puedo encontrarlo, o puedes mirar esta pregunta: stackoverflow.com/q/14811471/87015
Salman A

1
@SalmanA ¡Gracias! Sí, caigo en ese 99%. Primero necesito jquerylib para cargar, luego mis .jsscripts restantes . Cuando declaro asynco deferen la jqueryetiqueta de script lib, mis .jsscripts no funcionan. Pensé $(function(){ ... })protegido eso, supongo que no. Solución actual: no agrego deferni asyncen el jqueryscript lib, pero sí agrego asyncmis .jsscripts de seguimiento . Nota: la razón por la que hago algo de esto es para hacer feliz a Google Page Speed. Gracias de nuevo por la ayuda! Cualquier otro consejo es bienvenido. (O un enlace a su respuesta anterior). :)
elbowlobstercowstand

@elbow Consulte stackoverflow.com/a/21013975/87015 , solo le dará una idea, pero no la solución completa. En su lugar, puede buscar "bibliotecas de cargador asíncrono jquery".
Salman A

38

El consejo estándar, promovido por Yahoo! El equipo de rendimiento excepcional consiste en colocar las <script>etiquetas al final del cuerpo del documento para que no bloqueen la representación de la página.

Pero hay algunos enfoques más nuevos que ofrecen un mejor rendimiento, como se describe en esta respuesta sobre el tiempo de carga del archivo JavaScript de Google Analytics:

Hay algunas diapositivas excelentes de Steve Souders (experto en rendimiento del lado del cliente) sobre:

  • Diferentes técnicas para cargar archivos JavaScript externos en paralelo
  • su efecto en el tiempo de carga y la representación de la página
  • qué tipo de indicadores "en progreso" muestra el navegador (por ejemplo, "cargando" en la barra de estado, cursor del mouse del reloj de arena).

25

Si está utilizando JQuery, coloque el javascript donde lo encuentre mejor y úselo $(document).ready()para asegurarse de que las cosas se carguen correctamente antes de ejecutar cualquier función.

En una nota al margen: me gustan todas mis etiquetas de script en la <head>sección, ya que parece ser el lugar más limpio.


14
en la cabeza ... er? <header>?
Dan Lugg

77
Tenga en cuenta que el uso $(document).ready()no significa que puede colocar su JavaScript en el lugar que desee, aún debe colocarlo después del lugar <script src=".../jquery.min.js">donde incluye jQuery, para que $exista.
Rory O'Kane

2
No es óptimo colocar etiquetas de script en la sección <head>; esto retrasará la visualización de la parte visible de la página hasta que se carguen los scripts.
CyberMonk

No, @Dan, un headerelemento es parte del contenido del documento HTML, y debe aparecer una o más veces dentro de la etiqueta head del bodyelemento . The para metadatos y datos sin contenido para el documento. Es, en estos días, con defery asyncun lugar ideal para las etiquetas de script. headerLos elementos solo deben contener información que describa la sección del documento que le sigue.
ProfK

1
@ProfK, Dan se refería a la pregunta original sin editar cuando publicó esto hace más de 4 años. Como puede ver, la pregunta fue editada un año después.
kojow7

18

El enfoque moderno en 2019 es usar scripts de tipo de módulo ES6 .

<script type="module" src="..."></script>

Por defecto, los módulos se cargan asincrónicamente y se rechazan. es decir, puede colocarlos en cualquier lugar y se cargarán en paralelo y se ejecutarán cuando la página finalice la carga.

Las diferencias entre un script y un módulo se describen aquí:

https://stackoverflow.com/a/53821485/731548

La ejecución de un módulo en comparación con un script se describe aquí:

https://developers.google.com/web/fundamentals/primers/modules#defer

El soporte se muestra aquí:

https://caniuse.com/#feat=es6-module


buena información para agregar a la base de conocimiento
Sagar

1
Solo una nota de que esto no funcionará si solo está probando cosas en su sistema de archivos local sin servidor. Al menos en Chrome obtienes un error de origen cruzado al intentar cargar el js desde el HTML a pesar de que ambos tienen el mismo origen, tu sistema de archivos.
hippietrail

11

XHTML no se validará si el script no se encuentra dentro del elemento head. Resulta que puede estar en todas partes.

Puede diferir la ejecución con algo como jQuery para que no importe dónde se coloque (excepto por un pequeño golpe de rendimiento durante el análisis).


1
XHTML validará con etiquetas de script en el cuerpo, tanto estrictas como transitorias. Sin embargo, las etiquetas de estilo solo pueden estar en la cabeza.
I.devries

11
<script src="myjs.js"></script>
</body>

la etiqueta de script debe usarse siempre antes del cierre del cuerpo o Bottom en el archivo HTML .

entonces puede ver el contenido de la página primero antes de cargar el archivo js .

Marque esto si es necesario: http://stevesouders.com/hpws/rule-js-bottom.php


2
Esto realmente respondió la pregunta. Me preguntaba que casi todos los ejemplos publicados nunca dieron el contexto visual adecuado de "final de la página"
Ken Ingram

1
Esta respuesta es muy engañosa y muy probablemente incorrecta. Los artículos en Google y en MDN sugieren que JS síncrono (que es el caso aquí) siempre bloquea la construcción y el análisis DOM, lo que provocará un primer renderizado retrasado. Por lo tanto, no puede ver el contenido de la página hasta que se recupere el archivo JS y termine de ejecutarse, independientemente de dónde coloque su archivo JS en el documento HTML, siempre que esté sincronizado
Lingaraju EV

También hace referencia a puntos hechos en 2009 y que ya no son relevantes.
toxaq

7

La respuesta convencional (y ampliamente aceptada) es "en la parte inferior", porque entonces se habrá cargado todo el DOM antes de que algo pueda comenzar a ejecutarse.

Hay disidentes, por varias razones, comenzando con la práctica disponible para comenzar intencionalmente la ejecución con un evento de carga de página.


6

El mejor lugar para colocar la <script>etiqueta es antes de cerrar la </body>etiqueta , por lo que la descarga y ejecución no bloquea el navegador para analizar el html en el documento,

También cargar los archivos js externamente tiene sus propias ventajas, ya que será almacenado en caché por los navegadores y puede acelerar los tiempos de carga de la página , separa el código HTML y JavaScript y ayuda a administrar mejor la base del código .

pero los navegadores modernos también soportan algunas otras formas óptimas como asyncy deferpara carga externa javascriptarchivos.

Asíncrono y aplazar

Normalmente, la ejecución de la página HTML comienza línea por línea. Cuando se encuentra un elemento externo de JavaScript, el análisis HTML se detiene hasta que se descarga un JavaScript y está listo para su ejecución. Esta ejecución normal de la página se puede cambiar usando defery asyncatributo.

Defer

Cuando se utiliza un atributo de aplazamiento, JavaScript se descarga en paralelo con el análisis HTML, pero se ejecutará solo después de que se complete el análisis HTML completo.

<script src="/local-js-path/myScript.js" defer></script>

Async

Cuando se utiliza el atributo asincrónico, JavaScript se descarga tan pronto como se encuentra el script y después de la descarga, se ejecutará de forma asincrónica (paralela) junto con el análisis HTML.

<script src="/local-js-path/myScript.js" async></script>

Cuándo usar qué atributos

  • Si su script es independiente de otros scripts y es modular, use async .
  • Si está cargando script1 y script2 con async, ambos se ejecutarán en
    paralelo junto con el análisis HTML, tan pronto como se descarguen
    y estén disponibles.
  • Si su secuencia de comandos depende de otra secuencia de comandos, utilice defer para ambos:
  • Cuando script1 y script2 se cargan en ese orden con defer , se garantiza que script1 se ejecutará primero,
  • Entonces script2 se ejecutará después de que script1 se ejecute completamente.
  • Debe hacer esto si script2 depende de script1.
  • Si su script es lo suficientemente pequeño y depende de otro script de tipo async, utilice su script sin atributos y colóquelo sobre todos los asyncscripts.

referencia: knowledgehills.com


3

Depende, si está cargando un script que es necesario para diseñar su página / usando acciones en su página (como hacer clic en un botón), entonces es mejor que lo coloque en la parte superior. Si su estilo es 100% CSS y tiene todas las opciones de respaldo para las acciones del botón, puede colocarlo en la parte inferior.

O lo mejor (si eso no es una preocupación) es que puede hacer un cuadro de carga modal, colocar su javascript en la parte inferior de su página y hacer que desaparezca cuando se cargue la última línea de su script. De esta forma, puede evitar que los usuarios utilicen acciones en su página antes de cargar los scripts. Y también evite el estilo incorrecto.


3

La inclusión de secuencias de comandos al final se usa principalmente donde el contenido / estilos del sitio web se muestra primero.

incluyendo los scripts en la cabeza carga los scripts temprano y puede usarse antes de cargar todo el sitio web.

Si los scripts se ingresan por fin, la validación se realizará solo después de cargar todos los estilos y diseños, lo que no es apreciado por los sitios web de respuesta rápida.


2

Dependiendo de la secuencia de comandos y su uso, lo mejor posible (en términos de carga de página y tiempo de representación) puede ser no utilizar una etiqueta <script> convencional per se, sino activar dinámicamente la carga de la secuencia de comandos de forma asincrónica.

Existen algunas técnicas diferentes, pero la más sencilla es usar document.createElement ("script") cuando se activa el evento window.onload. Luego, la secuencia de comandos se carga primero cuando la página se ha procesado, lo que no afecta el tiempo que el usuario tiene que esperar a que aparezca la página.

Naturalmente, esto requiere que el script en sí no sea necesario para la representación de la página.

Para obtener más información, consulte la publicación Escritos asíncronos de acoplamiento de Steve Souders (creador de YSlow pero ahora en Google).


2
  • Si todavía le importa mucho el soporte y el rendimiento en IE <10, SIEMPRE es mejor que sus etiquetas de script sean las últimas etiquetas de su cuerpo HTML. De esa manera, está seguro de que el resto del DOM se ha cargado y no bloqueará ni renderizará.

  • Si ya no le importa demasiado IE <10, puede poner sus scripts en el encabezado de su documento y usarlos deferpara asegurarse de que solo se ejecuten después de que se haya cargado su DOM ( <script type="text/javascript" src="path/to/script1.js" defer></script>). Sin embargo, si aún desea que su código funcione en IE <10, ¡no olvide envolver su código de manera window.onloaduniforme!


En la respuesta aceptada, esto se conoce como la "recomendación anticuada". Si todavía lo dices en serio, probablemente debas producir alguna referencia para respaldarlo.
dakab

1

El script bloquea la carga del DOM hasta que se carga y ejecuta.

Si coloca scripts al final de <body>todo, DOM tiene la posibilidad de cargar y renderizar (la página se "mostrará" más rápido). <script>tendrá acceso a todos esos elementos DOM.

Por otro lado, colocarlo después del <body>inicio o superior ejecutará el script (donde todavía no hay elementos DOM).

Incluye jQuery, lo que significa que puede colocarlo donde desee y usar .ready ()


1

Creo que depende de la ejecución de la página web. Si la página que desea mostrar no se puede mostrar correctamente sin cargar JavaScript primero, entonces debe incluir primero el archivo JavaScript. Pero si puede mostrar / representar una página web sin descargar inicialmente el archivo JavaScript, entonces debe poner el código JavaScript en la parte inferior de la página. Debido a que emulará una carga rápida de la página, y desde el punto de vista del usuario, parecería que esa página se está cargando más rápido.


1

Puede colocar la mayoría de las <script>referencias al final de <body>,
pero si hay componentes activos en su página que usan scripts externos,
entonces su dependencia (archivos js) debería aparecer antes (idealmente en la etiqueta de encabezado).


1

Antes del final de la etiqueta del cuerpo para prevenir y bloquear la interfaz de usuario.


-1

Al final del documento HTML

Para que no afecte la carga del documento HTML en el navegador en el momento de la ejecución.


-1

El mejor lugar para escribir su JavaScriptcódigo es al final del documento después o justo antes de la </body>etiqueta para cargar el documento primero y luego ejecutar el código js.

<script> ... your code here ... </script>
</body>

Y si escribe JQuerylo siguiente puede estar en el documento principal y se ejecutará después de que se cargue el documento:

<script>
$(document).ready(function(){
   //your code here...
});
</script>

arrojaSyntaxError
Raz

Su respuesta no fue incorrecta, pero necesitaba urgentemente ser actualizada.
Paul Carlton

-2

Para mí tiene más sentido incluir el script después del HTML. Porque la mayoría de las veces necesito que se cargue el Dom antes de ejecutar mi script. Podría ponerlo en la etiqueta de la cabeza, pero no me gusta todo el oyente de carga de documentos por encima. Quiero que mi código sea corto, dulce y fácil de leer.

Escuché que las versiones antiguas de safari eran extrañas al agregar su script fuera de la etiqueta de la cabeza, pero digo a quién le importa. No conozco a nadie que use esa vieja basura.

Buena pregunta por cierto.


-6

Puede colocar donde desee los scripts y uno no es mejor que otra práctica.

La situación es la siguiente:

La página se carga linealmente, "de arriba hacia abajo", por lo que si coloca el script en la cabeza se asegura de que comience a cargarse antes de todo, ahora, si lo coloca dentro del cuerpo mezclado con el código puede causar cargas de página de una manera desagradable.

identificar buenas prácticas no depende de dónde.

para apoyarlo, mencionaré lo siguiente:

puedes colocar:

y la página se cargará linealmente

la página se carga de forma asíncrona con otro contenido

el contenido de la página se cargará antes y después de completar la carga, se cargarán los scripts

Una buena práctica aquí sería, ¿cuándo se implementará cada uno?

Espero haber sido útil, cualquier cosa solo respóndeme este problema.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.