¿Mejorar el rendimiento del sitio web a través de descargas paralelas de CSS?

Estaba optimizando el tiempo de carga de la página de un sitio web. Una de las formas fue combinando múltiples solicitudes HTTP para CSS en una solicitud HTTP combinada. Pero uno de los revisores hizo una pregunta interesante: ¿la paralelización de la descarga de múltiples archivos CSS no reduciría los tiempos de carga de la página?

Nunca consideré esta opción, ya que lo único que leí en Internet es que reducir el número de solicitudes HTTP (bloqueo) es clave para una página web más rápida (aunque Google Pagespeed Insights no parece indicar esto claramente 1 ).

Veo algunas razones por las cuales la paralelización no mejoraría el rendimiento, o solo importaría muy poco (compensada por el beneficio de usar menos solicitudes HTTP):

Configurar una nueva conexión es costoso. Si bien la configuración de varias conexiones se puede hacer en paralelo, los navegadores usarán como máximo unas 4-6 conexiones (dependiendo del navegador), por lo que descargar CSS en paralelo bloquearía la descarga de otros activos como JavaScript e imágenes.
Configurar una conexión HTTPS requiere algunos datos adicionales. He leído que esto puede ser fácilmente unos pocos KB de datos. Estos son algunos datos adicionales que deben enviarse por cable, en lugar del CSS que realmente queremos enviar.
Debido al algoritmo de inicio lento de TCP, cuantos más datos se hayan enviado a través de una conexión, más rápida será la conexión. Por lo tanto, las conexiones de mayor duración enviarían los datos mucho más rápido que las conexiones nuevas. Consulte, por ejemplo, el protocolo SPDY, que utiliza una única conexión para mejorar los tiempos de carga de la página.
TCP es una abstracción: todavía hay (normalmente) solo una conexión subyacente. Por lo tanto, aunque se utilizan múltiples solicitudes, los datos enviados a través del cable no necesariamente se benefician de múltiples conexiones para mejorar la velocidad.
Las conexiones a Internet son inherentemente poco confiables, especialmente en dispositivos móviles. Una solicitud puede finalizar significativamente más rápido que la otra. El uso de múltiples solicitudes de CSS significa que la página web está bloqueada hasta que la última solicitud haya finalizado, lo que puede ser significativamente más tarde que la conexión promedio.

Entonces, ¿hay algún beneficio en paralelizar las solicitudes HTTP para archivos CSS?

Nota / actualización: todos los archivos CSS bloquean el renderizado. Los archivos CSS que aún no se han movido fuera de la ruta crítica.

css performance

— ayke
fuente

Vi algo en el código de etsy como sitio de manualidades donde recomendaban usar un solo dominio sin cookies para objetos estáticos (css, imgs, js). Resulta que los navegadores modernos hacen un gran trabajo con descargas paralelas desde un solo dominio. En cuanto a varios archivos del mismo dominio (10 archivos css frente a 1 grande), creo que es mejor combinar y minimizar un archivo grande y solo hacer una solicitud. Especialmente con CSS, donde su sitio probablemente necesitará todo el CSS para que se vea correcto.

— Frank

En cierto modo, los navegadores ya se descargan en paralelo según la cantidad de conexiones disponibles para usar. Se basa en el HTML que está leyendo el navegador.

— Dom

Los archivos CSS vinculados desde documentos HTML se agregan a la cola de descarga paralela a medida que se analiza el HTML; La clave es que los enlaces JavaScript no asíncronos bloquean el analizador HTML, evitando que se agreguen etiquetas posteriores a la cola de descarga hasta que se descargue, analice y ejecute JavaScript. ^[1]

Aquí hay un ejemplo que obliga al navegador a descargar tres de los cuatro archivos secuencialmente (al menos tres viajes de ida y vuelta):

<head>
  <script src="js/fizz.js"></script>
  <link rel="stylesheet" href="css/foo.css"/>
  <script src="js/buzz.js"></script>
  <link rel="stylesheet" href="css/bar.css"/>
</head>

Este es el ejemplo modificado para que los 4 archivos se descarguen en paralelo (al menos un viaje de ida y vuelta):

<head>
  <link rel="stylesheet" href="css/foo.css"/>
  <link rel="stylesheet" href="css/bar.css"/>
  <script async src="js/fizz.js"></script>
  <script src="js/buzz.js"></script>
</head>

Otra nota: los archivos CSS son (por defecto) bloqueo de renderizado, no bloqueo de analizador; la página continuará siendo analizada y el DOM construido, pero el renderizado no comenzará hasta que se construya el CSSOM.

La razón principal para dividir su CSS es obtener las reglas mínimas necesarias para presentar el contenido de la mitad superior de la página al cliente y analizarlo lo antes posible. El resto de las reglas, para cosas que no son visibles de inmediato, se pueden marcar como no necesariamente bloqueo de renderizado conmedia consultas en la etiqueta del enlace, o agregarse a la página mediante JavaScript cargado de forma asíncrona.

Por lo tanto, no existe un beneficio claro al paralelizar sus descargas CSS solo por su propio bien. Pero como siempre, ¡mide y prueba!

Para leer más, recomiendo estos artículos sobre 'Fundamentos web: optimización del rendimiento' de Google: https://developers.google.com/web/fundamentals/performance/

[1]: Esto ignora la función de análisis especulativo de algunos navegadores:

https://docs.google.com/document/d/1JQZXrONw1RrjrdD_Z9jq1ZKsHguh8UVGHY_MZgE63II/preview?hl=es-GB&forcehl=1

https://developer.mozilla.org/en-US/docs/Web/HTML/Optimizing_your_pages_for_speculative_parsing

— Robert K. Bell
fuente

Otra buena lectura, acerca de cómo mantener sus scripts descargando simultáneamente, está aquí: stackoverflow.com/questions/436411/…

— joshreesjones

Vale la pena señalar que todos los archivos .js deben estar vinculados al final del código justo antes de la etiqueta de cierre del cuerpo, de esa manera no bloquean nada.

— Chaoley

¿Puedes explicar "Entonces, no hay un beneficio claro para paralelizar tus descargas de CSS solo por sí mismo"? De alguna manera no pude entenderlo a partir de la respuesta anterior

— gaurav5430

@ gaurav5430 Parece que no hay buenas razones para dividir archivos css, más allá de la optimización para el tiempo de renderizado anterior (¿y quizás la optimización de caché?)

— Robert K. Bell