sirve - ¿Se prefiere utilizar JavaScript en línea a una inclusión externa si el script es realmente corto?

script html ejemplos

Question

Utilizo External JavaScripts en un sitio web ya que siempre trato de mantener JavaScript en la parte inferior y externo.

Pero la velocidad de la página de Google está dando esta sugerencia.

Los siguientes recursos externos tienen cuerpos de respuesta pequeños. Insertar la respuesta en HTML puede reducir el bloqueo de la representación de la página.

http://websiteurl/ debería http://websiteurl/ los siguientes recursos pequeños: http://websiteurl/script.js

Este archivo js externo tiene solo este contenido.

$(document).ready(function() {
$("#various2").fancybox({
''width'': 485,
''height'': 691,
});
});

Pero en Yslow me sale esta sugerencia.

Calificación n / a en Hacer JavaScript y CSS externo

Solo considere esto si su propiedad es una página de inicio de usuario común.

There are a total of 3 inline scripts

JavaScript y CSS que están incluidos en los documentos HTML se descargan cada vez que se solicita el documento HTML. Esto reduce el número de solicitudes HTTP pero aumenta el tamaño del documento HTML. Por otro lado, si el JavaScript y CSS están en archivos externos almacenados en caché por el navegador, el tamaño del documento HTML se reduce sin aumentar el número de solicitudes HTTP.

¿Cuál es el derecho de Google o Yahoo?

Answer 1

Este es un ejemplo un tanto problemático, en bastantes frentes.

Puede organizar sus scripts de tal manera que no necesite alinear ese JS. Por ejemplo, podría tener un archivo common.js que ejecute ese fragmento de código, otros fragmentos de código similares y simplifique su código.

Además, esto parece haber despertado a la policía de arquitectura "nunca en línea con ningún JavaScript NUNCA". Resulta que, en ocasiones, es una práctica recomendada incluir JavaScript en línea, por ejemplo, consulte el fragmento común de Google Analytics.

¿Por qué Google sugiere que deberías incluir este pequeño script?

• Porque el 20% de las visitas a la página que obtienes tienen un caché no imprimido
• Si tiene una falta de caché, es probable que deba abrir una nueva conexión a su sitio (1 viaje de ida y vuelta) y luego los datos se entreguen en el segundo viaje de ida y vuelta. (Si tiene suerte, puede utilizar una conexión keepalive y se reduce a 1 viaje de ida y vuelta.
• Para una aplicación web en inglés "global" general, está considerando un tiempo típico de ida y vuelta de 110 ms para un servicio alojado en los Estados Unidos. Si está utilizando un CDN, el número probablemente se reduciría a la mitad.
• Incluso si el recurso es local, es posible que el navegador web aún deba acceder al disco para capturar ese pequeño archivo.
• Las etiquetas de secuencia de comandos de JavaScript no asíncronas o deferentes están bloqueadas , si esta secuencia de comandos se encuentra en algún lugar en medio de la página, se quedará atascada allí hasta que se descarguen las secuencias de comandos.

Desde una perspectiva de rendimiento si las únicas 2 opciones son:

1. Coloque un bit de JavaScript de 50 caracteres en línea
2. Coloque los 50 caracteres en un archivo separado y sirva.

Teniendo en cuenta que usted es un buen ciudadano web y comprime todo su contenido, la cantidad de carga útil adicional que esto agrega es insignificante en comparación con el riesgo del 20 por ciento de dar a las personas un retraso considerable. Siempre elegiría el # 1.

En un mundo imperfecto es muy raro tener un conjunto de opciones tan claro y fácil. Hay una opción 3 que involucra la carga asíncrona de jQuery y la captura de esta funcionalidad desde un área común.

Answer 2

Esto no es completamente cierto. Puede configurar el servidor web (bueno, al menos, apache) para que los scrips / ccs estén en línea cuando se sirvan.

Aquí hay un enlace útil.

http://www.websiteoptimization.com/speed/tweak/mod_pagespeed/

Answer 3

Hacer scripts en línea puede tener algunos efectos perjudiciales -

a) Organización del código: su código se dispersa entre su marca, lo que afecta la legibilidad

b) Código minificación y la ofuscación se vuelve difícil.

Es mejor mantener sus js en archivos separados, y luego, en el momento de la compilación, integrarlos en un solo archivo, y minimizar y ofuscar esto.

Answer 4

Hay dos factores a considerar aquí. Uno es el tiempo de descarga, el otro es la mantenibilidad. Ambos se ven afectados por la cantidad de veces que se necesita un fragmento de Javascript.

Con respecto al tiempo de descarga, obviamente tiene dos opciones: incluir el JS en el cuerpo de la página o como un archivo externo. Incluir el JS en el cuerpo guarda una solicitud HTTP adicional, aunque también aumenta un poco el HTML y puede ser una molestia mantenerlo si tiene varios scripts que está insertando en varias páginas diferentes.

Otra consideración importante es si se necesita o no el JS inmediatamente en la página. Si se necesita una pequeña porción de JS tan pronto como se cargue la página, entonces puede ser una buena idea colocarla en línea. Si se usa para algo asíncrono en el futuro, colocarlo en un archivo externo puede ser una buena opción.

Answer 5

La charla de Aaron Peters de Velocity EU del año pasado ofrece una buena perspectiva de las opciones y el curso que debe elegir: http://www.slideshare.net/startrender/fast-loading-javascript

Para un fragmento realmente pequeño de js, realmente no vale la pena colocarlos en un archivo externo, ya que la sobrecarga de la red de recuperarlos hará que los beneficios sean muy pequeños.

Dependiendo de la latencia, puede valer la pena incluir scripts grandes, por ejemplo, Bind mobile tiene un montón de js en la primera página cargada, que luego almacena en caché en localstorage para páginas posteriores.

Addy Osmani recientemente creó una biblioteca experimental para ayudar a las personas a jugar con scripts de almacenamiento en caché en localstorage - http://addyosmani.github.com/basket.js/

Answer 6

Mientras inserta la secuencia de comandos, se guardará una solicitud, ya que Yslow sugiere que aumente el tamaño del documento HTML y mezcle el contenido / marcado con el código / lógica, que generalmente desea evitar en la medida de lo posible.

La razón por la que Yslow da esta advertencia:

Solo considere esto si su propiedad es una página de inicio de usuario común.

Si la página se carga con frecuencia, vale la pena tener el javascript externo, ya que los archivos se almacenarán en caché en el navegador. Por lo tanto, si combina su JS en un solo archivo, en la primera solicitud incurrirá en una solicitud adicional, y en las solicitudes subsiguientes, el archivo se cargará desde el caché.

Answer 7

Normalmente escribo javascript en línea, especialmente si el script es tan pequeño. Yo diría que simplemente péguelo en su código. No aumentará mucho el tamaño del documento http.