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

Porque guardar solicitudes HTTP es de poca utilidad cuando lo logras al romper 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 totalmente diferentes. Si están agrupados en la misma página HTML, deben ser retransmitidos 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é, al igual que los 360 KB de JS. Ambos aciertos de caché tomaron menos tiempo y no consumieron prácticamente ancho de banda. Saque el perfil de red de su navegador y pruébelo en otros sitios.

Simplemente porque ¡El rendimiento web realmente importa! El 99% de las veces le dará tiempos de respuesta más rápidos al 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 : la aceleración de su sitio en 5 segundos aumentó la tasa de conversión entre un 7% y un 12%, duplicó el número de sesiones de marketing en buscadores y redujo a la mitad la cantidad de servidores necesarios.
• Mozilla : reducir 2,2 segundos de sus páginas de destino incrementó las conversiones de descarga en un 15,4%, lo que estiman que dará como resultado 60 millones más de descargas de Firefox por año.
• Netflix : la adopción de una única optimización, la compresión gzip, produjo 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 el frontend: Inicio   Aquí primero.

El uso de archivos externos produce páginas más rápidas porque los archivos de JavaScript y CSS se almacenan en caché por el navegador / redes / proxies (como se define en el protocolo HTTP con encabezados de caché). JavaScript y CSS que están incluidos en los 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 está utilizando 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 única aplicación (el navegador) abierta en su sitio web. El 99% de las veces le dará tiempos de respuesta más rápidos al usuario final.

La frecuencia con la que se almacenan en caché los componentes externos de JavaScript y CSS en relación con la cantidad de documentos HTML solicitados también es importante. Si los usuarios de su sitio tienen varias 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 almacenados en caché.

Pero la inclusió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, la olvida, ya que se trata principalmente de sitios web muy específicos realmente involucrados por el rendimiento del usuario final.

Puede leer aquí por qué es importante el desempeño ( Descargo de responsabilidad: yo soy el autor)

La última versión de HTTP se creó en 1999. En 1999, todos se conectaron a Internet con acceso telefónico. Internet fue muy lento. 16 años después, las cosas se han movido mucho, pero los protocolos que utilizamos no.

Las respuestas que no deberíamos incluir "porque interfieren con el almacenamiento en caché" son un poco engañosas, especialmente en la era de Internet ultrarrápida. Cuando realmente realiza los cálculos, a menudo hay una diferencia insignificante entre los tiempos de carga de los usuarios que utilizan la memoria caché y los usuarios de la memoria caché fría si ha ingresado. El hecho de que exista hay una pequeña diferencia no es inherente a que haya insertado, sino debido al diseño inflexible de HTTP / 1.1.

El protocolo SPDY implementa algo llamado push del servidor . Básicamente, esto lleva a la inclusión del propio documento HTML y al protocolo. Un servidor inteligente sabrá qué recursos ya tiene el cliente. Un servidor tonto simplemente enviará todo independientemente, esto 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 carga 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á el empuje del servidor, pero en teoría puede comenzar a usar SPDY hoy. Por lo tanto, la razón real por la que no estamos en línea es una de legada: los protocolos que existen actualmente son antiguos y no son lo suficientemente flexibles como para lograr una "integración de protocolos".

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

El 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ías que transformar tu script para escapar de algunos caracteres que se activan en HTML. Este problema desaparece cuando se suministran CSS y JavaScript como recursos externos, ya que ya no tienen que tener en cuenta el contexto de análisis "primario".

Si sirve su contenido como XML, tiene una parte de esto al usar las 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>

Cuidado con los forros.

La separación del contenido del estilo de su presentación suele ser una ventaja mayor que el menor número de solicitudes http.

La separación de todo el estilo 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 servidores como en clientes para esa página y otras páginas que se visitan.

Sin embargo, para su pregunta específica ... Si el servidor está hecho para hacer la minificación por sí mismo, hace que los activos sean más difíciles de mantener y solucionar problemas. Sin embargo, muchos marcos ahora lo hacen a nivel de archivo, por ejemplo, todos cs y todos js. Por ejemplo, el marco de Ruby on Rails ahora minimiza sus activos para la producción. 5-10 solicitudes de http adicionales generalmente no son el cuello de botella, es más si hay más de 100 solicitudes de 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 (ahora grande) la página se está descargando.

1. Minimiza la codificación duplicada. para ahorrar tiempo (puede reutilizar el estilo y la función JS codificada para una página).
2. Minimiza 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 un aumento del tamaño de las páginas individuales y demora mucho en descargarlas, pero CSS común no necesita descargarlas una y otra vez).
4. Uso remoto. (Puede colocar su CSS js JS común en un lugar remoto. No es el mismo servidor alojado)
5. Reduce el tiempo de correcció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 separa el contenido con metadatos)
7. Más limpio y comprensible de código (si incrusta todo en un archivo, la depuración y la claridad del código desaparecieron. Y cada página será una página muy larga).
8. Además, esto le ayudará a reducir el tamaño del producto.
9. Pero aún puedes considerar incrustar lo más único en la misma página.