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 formularios del lado del cliente. Para esto utilizo un complemento jQuery que incluyo en todas estas páginas. Pero la pregunta es, ¿yo:
- escribe los bits de código que configuran este script en línea?
- ¿incluye todos los bits en un archivo que se comparte entre todas estas páginas html?
- ¿incluye cada bit en un archivo externo separado, uno para cada página html?
Gracias.
javascript
html
performance
frontend
Dan Burzo
fuente
fuente
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.
fuente
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 cosas en línea que sepa que mejorarán el rendimiento (porque lo ha medido).
fuente
Si solo le importa el rendimiento, la mayoría de los consejos en este hilo son totalmente erróneos y cada vez son más incorrectos en la era SPA, donde podemos suponer que la página es inútil sin el código JS. He pasado innumerables horas optimizando los tiempos de carga de la página SPA y verificando estos resultados con diferentes navegadores. En general, el aumento del rendimiento al reorganizar su html puede ser bastante dramático.
Para obtener el mejor rendimiento, debe pensar en las páginas como cohetes de dos etapas. Estas dos etapas corresponden aproximadamente a las fases
<head>y<body>, pero piense en ellas como<static>y<dynamic>. La parte estática es básicamente una constante de cadena que empuja hacia abajo el tubo de respuesta lo más rápido posible. Esto puede ser un poco complicado si usa una gran cantidad de middleware que configura las cookies (estas deben configurarse antes de enviar contenido http), pero en principio solo está descargando 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 sonar difícil, pero solo lo estoy explicando mal, porque es casi trivial. Como habrás adivinado, esta parte estática debe contener todos los JavaScript incluidos y minimizados. Se vería algo así comoDado que le cuesta casi nada enviar esta porción por el cable, puede esperar que el cliente comience a recibir esto 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 ms y 60 ms. Los navegadores comenzarán a procesar esta sección tan pronto como la obtengan, y el tiempo de procesamiento dominará normalmente el tiempo de transferencia por un factor 20 o más, que ahora es su ventana amortizada para el procesamiento del lado del servidor
<dynamic>.El navegador tarda aproximadamente 50 ms (cromo, el resto puede ser un 20% más lento) para procesar jquery en línea + señalizador + angular + ng animado + ng táctil + ng rutas + 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 supongamos que tiene 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). Cuando llega el segundo fragmento, hemos procesado todos los códigos y plantillas js y podemos comenzar a ejecutar transformaciones dom.
Puede objetar que este método es ortogonal al concepto de alineación, pero no lo es. Si, en lugar de en línea, vincula a cdns o 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 está hablando con la base de datos), debe quedar claro que todos estos saltos costarían más que no hacer ningún salto. Si hubiera una peculiaridad del navegador que dijera que js externo se ejecuta más rápido, podríamos medir qué factor domina. Mis mediciones indican que las solicitudes adicionales matan el rendimiento en esta etapa.
Trabajo mucho con la optimización de aplicaciones de SPA. Es común que las personas piensen que el volumen de datos es un gran problema, mientras que, en verdad, la latencia y la ejecución a menudo dominan. Las bibliotecas minimizadas que enumeré agregan hasta 300 kb de datos, y eso es solo 68 kb descomprimidos, o 200 ms de descarga en un teléfono 2mbit 3g / 4g, que es exactamente la latencia que tomaría en el mismo teléfono para verificar si tenía los mismos datos en su caché ya, incluso si era proxy en caché, porque el impuesto de latencia móvil (latencia de teléfono a torre) todavía se aplica. Mientras tanto, las conexiones de escritorio que tienen una latencia de primer salto más baja generalmente tienen un ancho de banda más alto de todos modos.
En resumen, en este momento (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 ahora se acumulan a más de 3 megabytes de código minificado, se hace evidente que, al menos, las bibliotecas comunes ya no deberían estar en línea.
fuente
Creo que el caso específico de una página, guión corto es (solo) un caso defendible para guión en línea
fuente
En realidad, hay un caso bastante sólido para usar JavaScript en línea. Si js es lo suficientemente pequeño (una línea), tiendo a preferir el javascript en línea debido a dos factores:
jQuerypuede usar los métodosliveodelegatepara evitar esto, pero encuentro que si js es lo suficientemente pequeño, es preferible simplemente ponerlo en línea.fuente
Otra razón por la que siempre debe usar scripts externos es para facilitar la transición a la 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.
fuente
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 "conjunto lógico" de funciones, etc. 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 aquellos 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.
fuente
La única defensa que puedo ofrecer para javascipt en línea es que al usar vistas fuertemente tipadas con .net MVC puede referirse a las variables de c # en JavaScript que me han resultado útiles.
fuente
Tres consideraciones:
fuente
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.
fuente
En 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 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.
Dejando a un lado ASP.NET, este screencast explica los beneficios con más detalle: http://www.asp.net/learn/3.5-SP1/video-296.aspx
fuente
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 y difíciles de encontrar.
fuente
En su situación, 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.
fuente
Durante la creación de prototipos temprana, mantenga su código en línea para el beneficio de una 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 puede colocar todos sus Javascript externamente, entonces tiene un mal diseño en sus manos, y debería refactorizar sus datos y scripts
fuente
Google ha incluido tiempos de carga en las medidas de clasificación de su 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.
fuente
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
fuente
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.
fuente