insertar - llamar funcion javascript html sin evento

¿Cuándo debería usar Javascript en línea o externo? (18)

Creo que el caso de guion corto específico de una página es (solo) caso justificable para el guión en línea

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 real: tengo varias páginas html que necesitan una validación de formulario del lado del cliente. Para esto utilizo un plugin jQuery que incluyo en todas estas páginas. Pero la pregunta es, ¿verdad?

escribe 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.

Durante la creación temprana de prototipos 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 la producción.

Incluso me atrevería a decir que si no puedes colocar todo tu Javascript externamente, entonces tienes un mal diseño bajo tus manos, y deberías refactorizar tus datos y scripts

Echaré un vistazo al código requerido y lo dividiré en tantos archivos separados como sea necesario. Cada archivo js solo contendría un "conjunto lógico" 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 incluyes los que se necesitan. Cuando inicie sesión en su sitio, puede optimizar combinando cada archivo js que necesita una página en un solo archivo.

En el momento en que esta respuesta se publicó originalmente (2008), la regla era simple: todas las secuencias de comandos deberían ser externas. Tanto para el mantenimiento y el rendimiento.

(¿Por qué el rendimiento? Porque si el código está separado, puede ser almacenado en la caché por los navegadores).

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

Hoy en día, la escalabilidad de la web ha cambiado. Reducir el 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, aún se recomienda tener JavaScript externo. Pero para ciertos casos, especialmente fragmentos muy pequeños de código, tiene sentido incluirlos en el HTML del sitio.

En el punto de mantener JavaScript externo:

ASP.NET 3.5SP1 recientemente introdujo la funcionalidad para crear un recurso de script compuesto (combinar un conjunto de archivos js en uno). Otro beneficio de esto es cuando la compresión del servidor web está activada, la descarga de un archivo ligeramente mayor tendrá una mejor relación de compresión que muchos archivos más pequeños (también menos gastos generales de HTTP, ida y vuelta, etc.). Supongo que esto ahorra en la carga de la página inicial, luego el caché del navegador entra en acción como se mencionó anteriormente.

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

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

Localidad . No es necesario navegar 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 de DOM (onclick, etc.) para esa sección, dependiendo de cómo los vinculó. Por ejemplo, al usar jQuery puede usar los métodos en live o delegate para eludir esto, pero me parece que si el js es lo suficientemente pequeño, es preferible simplemente ponerlo en línea.

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.

Google ha incluido los tiempos de carga en sus mediciones de clasificación de páginas, si hace mucho tiempo, las arañas demorarán más en rastrear su página, esto puede influir en el ranking de su página si tiene mucho que incluir. en cualquier caso, diferentes estrategias pueden influir en su clasificación.

La única defensa que puedo ofrecer para javascipt en línea es que al usar vistas fuertemente tipadas con .NET MVC, puede consultar las variables c # a mediados de javascript que he encontrado útiles.

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 esos archivos externos) es mejor mantener el rendimiento 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 que desee poder reutilizar ese código, hágalo externo. Si no lo hace, mire su tamaño y decida entonces.

La externalización de javascript es una de las reglas de rendimiento de yahoo: http://developer.yahoo.com/performance/rules.html#external

Si bien la regla rígida de que siempre debe externalizar los scripts generalmente será una buena apuesta, en algunos casos es posible que desee alinear algunos de los scripts y estilos. Sin embargo, solo debes alinear cosas que sabes que mejorarán el rendimiento (porque has medido esto).

Los scripts externos también son más fáciles de depurar usando Firebug. Me gusta Unit Test mi JavaScript y tenerlo todo ayuda externa. Odio ver JavaScript en código PHP y HTML, parece un gran desastre para mí.

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) . CSP incumple de forma predeterminada todas las secuencias de comandos en línea, lo que hace que su sitio sea más resistente a los ataques XSS.

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

Si solo te preocupa el rendimiento, la mayoría de los consejos en este hilo está completamente equivocado, y cada vez está más equivocado en la era del SPA, donde podemos asumir que la página es inútil sin el código JS. Pasé incontables horas optimizando los tiempos de carga de la página SPA y verificando estos resultados con diferentes navegadores. En general, el aumento de rendimiento al volver a orquestar tu html puede ser bastante dramático.

Para obtener el mejor rendimiento, debes 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 tan rápido como sea posible. Esto puede ser un poco complicado si usa mucho middleware que establece cookies (éstas deben establecerse antes de enviar contenido http), pero en principio solo va a descargar el búfer de respuesta, con suerte antes de saltar a algún código de plantillas (razor, php, etc.) en el servidor. Esto puede sonar difícil, pero luego lo estoy explicando mal, porque es casi trivial. Como habrás adivinado, esta parte estática debe contener todos los javascript en línea y minificados. Se vería algo así como

<!DOCTYPE html> <html> <head> <script>/*...inlined jquery, angular, your code*/</script> <style>/* ditto css */</style> </head> <body>  <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 porción por el cable, puede esperar que el cliente comience a recibir esto en algún lugar alrededor de 5 ms de latencia luego de conectarse a su servidor. Suponiendo que el servidor está razonablemente cerca, esta latencia podría oscilar 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 normalmente dominará el tiempo de transferencia por factor 20 o más, que ahora es su ventana amortizada para el procesamiento del lado del servidor de la porción <dynamic> .

El navegador tarda unos 50 ms (Chrome, reposo tal vez un 20% más lento) para procesar jquery en línea + signalr + angular + ng animate + ng touch + ng routes + lodash. Eso es bastante sorprendente en sí mismo. La mayoría de las aplicaciones web tienen menos código que todas esas bibliotecas populares compiladas, pero digamos que tienes tanto, así que ganaríamos latencia + 100ms de procesamiento en el cliente (este premio de latencia proviene del segundo fragmento de transferencia). Para cuando llega el segundo fragmento, hemos procesado todo el código js y las plantillas, y podemos comenzar a ejecutar las transformaciones dom.

Puede objetar que este método es ortogonal al concepto de línea, pero no lo es. Si usted, en lugar de ingresar, enlaza con cdns o sus propios servidores, el navegador tendría que abrir otra (s) conexión (es) y retrasar la ejecución. Como esta ejecución es básicamente gratuita (dado 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 dice que js externo se ejecuta más rápido, podríamos medir qué factor domina. Mis medidas indican que las solicitudes adicionales matan 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, mientras que, en verdad, la latencia y la ejecución a menudo dominan. Las bibliotecas minimizadas que he enumerado añaden hasta 300kb de datos, y eso es solo 68 kb con gzip, o 200ms de descarga en un teléfono de 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é, incluso si se almacenó en memoria caché, 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 mayor ancho de banda de todos modos.

En resumen, en este momento (2014), es mejor alinear 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 hasta 3 megabytes de código modificado, se está volviendo obvio que, al menos, las bibliotecas comunes ya no deberían estar incluidas.

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 externo.

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 ...

bueno, creo que debería usar en línea al hacer sitios web de una sola página, ya que los scripts no necesitarán ser compartidos en varias páginas