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

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?

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.

¡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)

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

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.

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

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.

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.