¿Cuándo debo usar Inline vs.¿Javascript externo?

https://stackoverflow.com/questions/138884

02-07-2019
|

Pregunta

Me gustaría saber cuándo debo incluir scripts externos o escribirlos en línea con el código html, en términos de rendimiento y facilidad de mantenimiento.

¿Cuál es la práctica general para esto?

Escenario del mundo real: tengo varias páginas HTML que necesitan validación de formulario del lado del cliente.Para ello utilizo un complemento jQuery que incluyo en todas estas páginas.Pero la pregunta es, ¿debo:

¿Escribir los bits de código que configuran este script en línea?
¿Incluir todos los bits en un archivo que se comparte entre todas estas páginas html?
¿Incluir cada bit en un archivo externo separado, uno para cada página html?

Gracias.

Solución

En el momento en que esta respuesta se publicó originalmente (2008), la regla era simple: todo script debería ser externo. Tanto por mantenimiento como por rendimiento.

(¿Por qué el rendimiento? Porque si el código está separado, los navegadores pueden almacenarlo en la memoria caché).

JavaScript no pertenece al código HTML y si contiene caracteres especiales (como <, >) incluso crea problemas.

Hoy en día, la escalabilidad web ha cambiado. La reducción del número de solicitudes se ha convertido en una consideración válida debido a la latencia de realizar múltiples solicitudes HTTP. Esto hace que la respuesta sea más compleja: en la mayoría de los casos, se recomienda tener JavaScript externo todavía . Pero para ciertos casos, especialmente piezas de código muy pequeñas, incluirlas en el sitio & # 8217; HTML tiene sentido.

Otros consejos

La capacidad de mantenimiento es definitivamente una razón para mantenerlos externos, pero si la configuración es de una sola línea (o, en general, más corta que la sobrecarga de HTTP que obtendría por hacer que esos archivos sean externos), en términos de rendimiento, es mejor mantenerlos en línea. Recuerde siempre que cada solicitud HTTP genera una sobrecarga en términos de tiempo de ejecución y tráfico.

Naturalmente, todo esto se vuelve irrelevante en el momento en que su código es más largo que un par de líneas y no es realmente específico para una sola página. En el momento en que desee poder reutilizar ese código, hágalo externo. Si no lo hace, mire su tamaño y decida entonces.

Externalizar javascript es una de las reglas de rendimiento de yahoo: http://developer.yahoo.com/performance/rules.html#external

Si bien la regla estricta de que siempre debe externalizar los scripts generalmente será una buena apuesta, en algunos casos es posible que desee incluir algunos de los scripts y estilos. Sin embargo, solo debe incluir en línea las cosas que sabe que mejorarán el rendimiento (porque lo midió).

Si solo le importa el rendimiento, la mayoría de los consejos de este hilo son completamente incorrectos y se están volviendo cada vez más incorrectos en la era SPA, donde podemos asumir que la página es inútil sin el código JS.He pasado innumerables horas optimizando los tiempos de carga de las páginas SPA y verificando estos resultados con diferentes navegadores.En general, el aumento del rendimiento al reorquestar su html puede ser bastante dramático.

Para obtener el mejor rendimiento, hay que pensar en las páginas como cohetes de dos etapas.Estas dos etapas corresponden aproximadamente a <head> y <body> fases, pero piense en ellas como <static> y <dynamic>.La parte estática es básicamente una constante de cadena que empujas hacia abajo por el tubo de respuesta lo más rápido posible.Esto puede ser un poco complicado si usas mucho middleware que configura cookies (éstas deben configurarse antes de enviar contenido http), pero en principio es simplemente vaciar el búfer de respuesta, con suerte antes de saltar a algún código de plantilla (razor, php, etc) en el servidor.Esto puede parecer difícil, pero lo estoy explicando mal, porque es casi trivial.Como habrás adivinado, esta parte estática debe contener todo el javascript integrado y minimizado.Se vería algo así como

<!DOCTYPE html>
     <html>
         <head>
             <script>/*...inlined jquery, angular, your code*/</script>
             <style>/* ditto css */</style>
         </head>
         <body>
             <!-- inline all your templates, if applicable -->
             <script type='template-mime' id='1'></script>
             <script type='template-mime' id='2'></script>
             <script type='template-mime' id='3'></script>

Dado que no le cuesta casi nada enviar esta parte por cable, puede esperar que el cliente comience a recibirla en algún lugar alrededor de 5 ms + latencia después de conectarse a su servidor.Suponiendo que el servidor esté razonablemente cerca, esta latencia podría estar entre 20 y 60 ms.Los navegadores comenzarán a procesar esta sección tan pronto como la obtengan, y el tiempo de procesamiento normalmente dominará el tiempo de transferencia por un factor de 20 o más, que ahora es su ventana amortizada para el procesamiento del lado del servidor. <dynamic> parte.

El navegador tarda unos 50 ms (chrome, el resto quizás un 20% más lento) en procesar jquery en línea + signalr + angular + ng animate + ng touch + ng route + lodash.Eso es bastante sorprendente en sí mismo.La mayoría de las aplicaciones web tienen menos código que todas esas bibliotecas populares juntas, pero digamos que tienes la misma cantidad, por lo que ganaríamos latencia + 100 ms de procesamiento en el cliente (esta ganancia de latencia proviene del segundo fragmento de transferencia).Para cuando llegue el segundo fragmento, habremos procesado todo el código js y las plantillas y podremos comenzar a ejecutar transformaciones dom.

Puede objetar que este método es ortogonal al concepto de inserción, pero no lo es.Si, en lugar de insertarlo, se vincula a cdns o a sus propios servidores, el navegador tendría que abrir otra(s) conexión(es) y retrasar la ejecución.Dado que esta ejecución es básicamente gratuita (ya que el lado del servidor se comunica con la base de datos), debe quedar claro que todos estos saltos costarían más que no realizar ningún salto.Si hubiera una peculiaridad del navegador que dijera que el js externo se ejecuta más rápido, podríamos medir qué factor domina.Mis mediciones indican que las solicitudes adicionales acaban con el rendimiento en esta etapa.

Trabajo mucho con la optimización de aplicaciones SPA.Es común que la gente piense que el volumen de datos es un gran problema, cuando en realidad la latencia y la ejecución suelen dominar.Las bibliotecas minificadas que enumeré suman hasta 300 kb de datos, y eso son solo 68 kb comprimidos con gzip, o 200 ms de descarga en un teléfono 3g/4g de 2 mbit, que es exactamente la latencia que tomaría en el mismo teléfono para verificar SI tuviera los mismos datos. ya está en su caché, incluso si estaba en caché proxy, porque el impuesto de latencia móvil (latencia de teléfono a torre) aún se aplica.Mientras tanto, las conexiones de escritorio que tienen una latencia de primer salto más baja suelen tener un ancho de banda mayor de todos modos.

En resumen, ahora mismo (2014), es mejor incorporar todos los scripts, estilos y plantillas.

EDITAR (MAYO 2016)

A medida que las aplicaciones JS continúan creciendo, y algunas de mis cargas útiles ahora acumulan hasta más de 3 megabytes de código minificado, se vuelve obvio que al menos las bibliotecas comunes ya no deberían estar integradas.

creo que el específico para una página, breve caso de script es (solo) caso defendible para script en línea

En realidad, hay un caso bastante sólido para usar JavaScript en línea. Si el js es lo suficientemente pequeño (una línea), tiendo a preferir el javascript en línea debido a dos factores:

Localidad . No es necesario navegar por un archivo externo para validar el comportamiento de algunos JavaScript
AJAX . Si está actualizando alguna sección de la página a través de AJAX, puede perder todos sus controladores DOM (onclick, etc.) para esa sección, dependiendo de cómo los vinculó. Por ejemplo, con jQuery puede usar live o delegate para evitar esto, pero creo que si js es lo suficientemente pequeño, es preferible simplemente ponerlo en línea.

Otra razón por la que siempre debe usar scripts externos es para facilitar la transición a Política de seguridad de contenido (CSP) . Los valores predeterminados de CSP prohíben todos los scripts en línea, lo que hace que su sitio sea más resistente a los ataques XSS.

Echaría un vistazo al código requerido y lo dividiría en tantos archivos separados como sea necesario. Cada archivo js solo contendría un & Quot; conjunto lógico & Quot; de funciones, etc. ej. un archivo para todas las funciones relacionadas con el inicio de sesión.

Luego, durante el desarrollo del sitio en cada página html, solo incluye los que son necesarios. Cuando entre en funcionamiento con su sitio, puede optimizar combinando todos los archivos js que una página necesita en un solo archivo.

La única defensa que puedo ofrecer para javascript en línea es que cuando se usan vistas fuertemente tipadas con .net MVC puedes referirte a las variables de c # en javascript que he encontrado útiles.

Tres consideraciones:

¿Cuánto código necesita (a veces las bibliotecas son un consumidor de primera clase)?
Especificidad: ¿este código solo funciona en el contexto de este documento o elemento específico?
Cada código dentro del documento tiende a hacerlo más largo y, por lo tanto, más lento. Además de que las consideraciones de SEO lo hacen obvio, que minimizas las secuencias de comandos internas ...

Las secuencias de comandos externas también son más fáciles de depurar con Firebug. Me gusta Unit Test my JavaScript y tenerlo todo ayuda externa. Odio ver JavaScript en código PHP y HTML, me parece un gran desastre.

Sobre el punto de mantener JavaScript externo:

ASP.NET 3.5SP1 introdujo recientemente la funcionalidad para crear un recurso de secuencia de comandos compuesta (fusionar un montón de archivos js en uno). Otro beneficio de esto es que cuando la compresión del servidor web está activada, la descarga de un archivo un poco más grande tendrá una mejor relación de compresión que muchos archivos más pequeños (también menos sobrecarga de http, ida y vuelta, etc.). Supongo que esto ahorra en la carga inicial de la página, luego el almacenamiento en caché del navegador comienza como se mencionó anteriormente.

ASP.NET aparte, este screencast explica los beneficios con más detalle: http://www.asp.net/learn/3.5-SP1/ video-296.aspx

Otro beneficio oculto de los scripts externos es que puede ejecutarlos fácilmente a través de un verificador de sintaxis como jslint . Eso puede salvarlo de muchos errores IE6 desgarradores, difíciles de encontrar.

En su escenario, parece que escribir las cosas externas en un archivo compartido entre las páginas sería bueno para usted. Estoy de acuerdo con todo lo dicho anteriormente.

Durante la creación de prototipos temprana, mantenga su código en línea para el beneficio de la iteración rápida, pero asegúrese de hacerlo todo externo para cuando llegue a producción.

Incluso me atrevería a decir que si no puedes colocar todos tus Javascript externamente, entonces tienes un mal diseño en tus manos, y debes refactorizar tus datos y scripts

Google ha incluido tiempos de carga en las medidas de clasificación de la página, si se alinea mucho, las arañas tardarán más en rastrear a través de su página, esto puede influir en la clasificación de su página si tiene que incluir mucho. en cualquier caso, diferentes estrategias pueden influir en su clasificación.

bueno, creo que deberías usar en línea cuando crees sitios web de una sola página, ya que los scripts no tendrán que compartirse en varias páginas

Siempre trate de usar Js externos ya que js en línea siempre es difícil de mantener.

Además, se requiere profesionalmente que use un js externo ya que la mayoría de los desarrolladores recomiendan usar js externamente.

Yo mismo uso js externos.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow