¿Por qué no incrustar estilos / scripts en HTML en lugar de vincular?


41

Concatenamos archivos CSS y JavaScript para reducir la cantidad de solicitudes HTTP, lo que mejora el rendimiento. El resultado es HTML como este:

<link rel="stylesheet" href="all-my-css-0fn392nf.min.css">
<!-- later... -->
<script src="all-my-js-0fn392nf.min.js"></script>

Si tenemos lógica del lado del servidor / compilación para hacer todo esto por nosotros, ¿por qué no ir un paso más allá e incrustar esos estilos y scripts concatenados en el HTML?

<style>.all{width:100%;}.my{display:none;}.css{color:white;}</style>
<!-- later... -->
<script>var all, my, js;</script>

Son dos solicitudes HTTP menos, sin embargo, no he visto esta técnica en la práctica. Por qué no?


12
Culpo al almacenamiento en caché.

Respuestas:


98

Porque guardar solicitudes HTTP es de poca utilidad cuando lo logras rompiendo el almacenamiento en caché. Si las hojas de estilo y los scripts se sirven por separado, pueden almacenarse en caché muy bien y amortizarse en muchas, muchas solicitudes a páginas muy diferentes. Si están agrupados en la misma página HTML, deben volver a transmitirse con cada uno. Soltero. Solicitud.

El HTML de esta página, por ejemplo, es de 13 KB en este momento. Los 180 KB de CSS llegaron al caché, y también los 360 KB de JS. Ambos éxitos de caché tomaron menos tiempo y prácticamente no consumieron ancho de banda. Saca el generador de perfiles de red de tu navegador y pruébalo en otros sitios.


1
Si está haciendo un sitio de estilo de aplicación de una sola página, donde la gran mayoría del código era específico de una página, ¿podría tener sentido aún?
JohnB

3
John: si la página se visita solo una vez, sí. Si se visita varias veces, todo el material incrustado se transmite varias veces en lugar de una sola vez y se almacena en caché.
Konerak

Otro buen punto a tener en cuenta es que al servirlos por separado, permite la minificación de los recursos para que sean más pequeños.
maple_shaft

2
@maple_shaft Por favor, explique, ¿por qué no puede minimizar los recursos normalmente y luego incluirlos?

1
@JohnB no olvide los efectos de un CDN o el almacenamiento en caché local en el ISP. Mi solicitud de javascript para google probablemente nunca llegue a google, incluso si tengo una falta de caché localmente porque otra persona que usa el mismo ISP ya habrá causado que el ISP guarde en caché los datos.

19

¡Simplemente porque el rendimiento web realmente importa! 99% de las veces le dará tiempos de respuesta más rápidos para el usuario final.

Aquí hay algunos ejemplos de Velocity Conf.

  • Bing : una página que fue 2 segundos más lenta resultó en una caída del 4.3% en los ingresos / usuario.
  • Google : un retraso de 400 milisegundos provocó una caída del 0,59% en las búsquedas / usuario.
  • Yahoo ! - Una desaceleración de 400 milisegundos resultó en una caída del 5-9% en el tráfico de página completa.
  • Shopzilla : acelerar su sitio en 5 segundos aumentó la tasa de conversión en un 7-12%, duplicó la cantidad de sesiones del marketing de motores de búsqueda y redujo a la mitad la cantidad de servidores necesarios.
  • Mozilla : reducir 2.2 segundos de sus páginas de destino aumentó las conversiones de descarga en un 15.4%, lo que estiman dará como resultado 60 millones más de descargas de Firefox por año.
  • Netflix : la adopción de una optimización única, la compresión gzip, resultó en una aceleración del 13-25% y redujo el tráfico de red saliente en un 50%.

De Steve Souders, pionero en la optimización del rendimiento web,

El 80-90% del tiempo de respuesta del usuario final se gasta en la interfaz - Comience aquí primero.

El uso de archivos externos produce páginas más rápidas porque los archivos JavaScript y CSS son almacenados en caché por el navegador / redes / servidores proxy (como se define en el protocolo HTTP con encabezados de caché). JavaScript y CSS que están integrados en documentos HTML se descargan cada vez que se solicita el documento HTML. Esto reduce la cantidad de solicitudes HTTP que se necesitan, pero aumenta el tamaño del documento HTML. Si usa scripts similares a Jquery, es fácil hacer referencia a 300 KB de scripts y no cree que todos tengan un ancho de banda de 100 MBits / s con baja latencia, ejecutando una sola aplicación, el navegador, abierta en su sitio web. 99% de veces le dará tiempos de respuesta más rápidos para el usuario final

La frecuencia con la que los componentes externos de JavaScript y CSS se almacenan en caché en relación con la cantidad de documentos HTML solicitados también es importante. Si los usuarios de su sitio tienen múltiples vistas de página por sesión y muchas de sus páginas reutilizan los mismos scripts y hojas de estilo (paquetes), existe un mayor beneficio potencial de los archivos externos en caché.

Pero la alineación es, a veces, preferible para aplicaciones de una sola página o sitios web con una sola vista de página por sesión. No existe una regla de oro y, en general, olvídala, ya que se refiere principalmente a sitios web muy específicos realmente involucrados en el rendimiento del usuario final.

Puede leer aquí por qué importa el rendimiento (Descargo de responsabilidad: soy el autor)


3

La última versión de HTTP se creó en 1999. En 1999, todos se conectaban a Internet con acceso telefónico. El internet era muy lento. 16 años después, las cosas han avanzado mucho, pero los protocolos que usamos no lo han hecho.

Las respuestas que no deberíamos incluir "porque interfiere con el almacenamiento en caché" son un poco engañosas, particularmente en la era de Internet súper rápido. Cuando realmente hace los cálculos, a menudo hay una diferencia insignificante entre los tiempos de carga con los usuarios de caché en caliente y frío en caché si se ha incorporado. El hecho de que no es una pequeña diferencia no es de por sí, ya que han inline, pero debido al diseño inflexible de HTTP / 1.1.

El protocolo SPDY implementa algo llamado servidor push . Esto esencialmente elimina la alineación del documento HTML en sí mismo y lo incorpora al protocolo. Un servidor inteligente sabrá qué recursos tiene el cliente. Un servidor tonto enviará todo independientemente, eso seguirá siendo un beneficio de rendimiento, pero puede costar en términos de ancho de banda. Si el navegador tiene el contenido en su caché, simplemente puede descartar las copias entrantes. El servidor espera hasta que se cargue el HTML antes de enviar los recursos adicionales; en teoría, el navegador puede enviar una señal para cancelar la inserción del servidor.

HTTP / 2.0 se basa en SPDY y probablemente implementará la inserción del servidor, pero en teoría puede comenzar a usar SPDY hoy. Por lo tanto, la verdadera razón por la que no estamos en línea es una herencia: los protocolos que existen actualmente son antiguos y no son lo suficientemente flexibles como para lograr una "inserción de nivel de protocolo".


2
Respuesta interesante, pero en lugar de "legado", la razón que da para no incluir en la actualidad es porque es la mejor opción para la infraestructura de protocolo web actual. Será heredado si todos siguen haciendo lo mismo en n años cuando HTTP / 2.0 / SPDY está completamente implementado ;-)
andybuckley

2
¿Podría dar una cita, hacer un bosquejo de los cálculos, o al menos dar un número de estadio para "superrápido"? Las personas en países civilizados del primer mundo con una suma considerable para gastar en línea (léase: clientes) aún pueden a veces, o incluso a menudo, navegar con menos ancho de banda que cientos de megabytes por segundo. Por mi parte, rara vez alcanzo más de tres MB / s, a menudo menos de 700 KB / s. Como punto separado, no da una razón para alinearse en la forma en que OP sugiere (de hecho, da razones para no hacerlo ), da razones para optimizar los protocolos.

1
Mi conexión 3G no es exactamente "superrápida", ni mi factura telefónica aprecia datos innecesarios. No lo olvide: no todo el uso de datos móviles se realiza en el teléfono con anclaje a red y tabletas / computadoras portátiles habilitadas para 3G. Esp. con las computadoras portátiles se supone wifi / ethernet en una conexión de banda ancha doméstica. No se aprecia cuando se conecta de forma remota ...
AnonJr

3

Además de las preocupaciones de almacenamiento en caché y recuperación que generan las otras respuestas, me gustaría resaltar otro problema más oscuro: el análisis .

JavaScript que aparece en HTML puede tener problemas de análisis, como en este ejemplo:

<html>
<head>
<script>
function myfunc() {
    if ("</style> isn't a problem")
        return "but </script> is"
}
</script>
<style>
body::after {
  content: '</script> is okay, but not </style>'
}
</style>
</head>
<body>
<script>document.write(myfunc())</script>
</body>
</html>

... lo que significa que tendría que transformar su script para escapar de algunos caracteres que se activan en HTML. Este problema desaparece cuando proporciona CSS y JavaScript como recursos externos, porque ya no tienen que tener en cuenta el contexto de análisis 'principal'.

Si sirve su contenido como XML, tiene una forma de evitarlo mediante el uso de secciones CDATA. CDATA, sin embargo, viene con un problema similar:

<?xml version="1.0" encoding="utf-8"?>
<html>
<head>
<script>
// <![CDATA[
function myfunc() {
    if ("</script> is no longer a problem")
        return "but ]]> is"
}
// ]]>
</script>
<style>
<![CDATA[
body::after {
  content: 'same ]]> issue here'
}
]]>
</style>
</head>
<body>
<script>document.write(myfunc())</script>
</body>
</html>

Inliners ten cuidado.


1

La separación del contenido del estilo de su presentación suele ser una ventaja mayor que menos solicitudes http.

La separación de todos los estilos permite y fomenta la reutilización y los archivos compartidos.

El contenido de los archivos también será más estático y estará disponible para el almacenamiento en caché tanto en los servidores como en los clientes tanto para esa página como para otras páginas visitadas.

Sin embargo, para su pregunta específica ... Si el servidor está hecho para hacer la minificación en sí mismo, hace que los activos sean más difíciles de mantener y depurar problemas. Sin embargo, muchos marcos lo hacen ahora a nivel de archivo, por ejemplo, todos los cs y todos los js. Por ejemplo, el marco de ruby ​​on rails ahora minimiza sus activos para la producción. 5-10 solicitudes http adicionales generalmente no son el cuello de botella, es más si hay más de 100 solicitudes http (que a menudo se obtienen con imágenes).

El paso adicional de incluir realmente el código en las páginas en sí tendría la desventaja de que las páginas más grandes tendrían que administrar la secuencia de descarga con cuidado y la página no podría mostrar contenido a menudo sin el resto de la página (ahora grande) siendo descargado


Para aclarar, ¿está diciendo que la separación de estilo y contenido beneficia a los desarrolladores o beneficia el rendimiento en el navegador del usuario final?

Digo que el beneficio general para la empresa suele ser una ganancia mayor que la reducción de las solicitudes en términos comerciales.
Michael Durrant

3
¿Te das cuenta de que OP aboga por el desarrollo con archivos separados y solo concatena durante el despliegue, junto con la minificación, la ofuscación y la concatenación "regular"? Usted puede tener su base de código mantenible y también comer los beneficios de rendimiento. Esta es una práctica común con otras optimizaciones de manipulación de código, como minimizar el código fuente y concatenar múltiples archivos JS / CSS en uno.

No me doy cuenta de eso. Las palabras "incrustar esos estilos y scripts concatenados en el HTML?" me confunde.
Michael Durrant

Para ser claros, de hecho quise sugerir lo que @delnan ha aclarado en mi nombre en su comentario. Lo siento si la redacción de mi pregunta fue ambigua.
Gladstone

1
  1. Minimiza la codificación duplicada. para ahorrar tiempo (puede reutilizar el estilo y la función JS codificados para una página).
  2. Minimice el esfuerzo de cambio. (Si su cliente le pide que cambie el color del botón del sitio web, debe ir página por página).
  3. Reduzca el tiempo de carga (si su CSS y JS se duplican, significa que el tamaño de las páginas individuales aumenta y consume mucho tiempo descargar. Pero CSS JS común no necesita descargar una y otra vez).
  4. Uso a distancia. (puede colocar su CSS js JS común en un lugar remoto. No es el mismo servidor alojado)
  5. Reduce el tiempo de reparación de errores. Si hay un error en una función, debe ir página por página para corregir los errores en JS y CSS incrustados.
  6. Para aumentar el SEO (simplemente separe el contenido con metadatos)
  7. Un código más claro y comprensible (si incrusta todo en un archivo, la depuración y la claridad del código desaparecerán, y cada página será una página muy larga).
  8. Además, esto lo ayudará a reducir el tamaño del producto.
  9. Pero aún así puede considerar incrustar la cosa más única en la misma página.

0

No debemos incrustar estilos / scripts en HTML porque

Los estilos / scripts integrados deben descargarse con cada solicitud de página:

El navegador no puede almacenar en caché estos estilos y volver a utilizarlos para otra página. Debido a esto, se recomienda incorporar una cantidad mínima de CSS / JS como sea posible.

en su lugar usamos vinculación porque usamos vinculación para vincular css / scripts

La velocidad del sitio aumenta para múltiples solicitudes de página:

Cuando una persona visita su sitio web por primera vez, su navegador descarga el HTML de la página actual más el archivo CSS y JS vinculado. Cuando navegan a otra página, su navegador solo necesita descargar el HTML de la nueva página, el archivo CSS / JS se almacena en caché, por lo que no es necesario volver a descargarlo. Esto puede marcar una gran diferencia, especialmente si tiene un gran archivo de estilo y script.

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.