CSS Crítico

Hola, mi nombre es Sergey Labozy, y soy ingeniero de software en Focus Reactive. En los últimos años, he pasado mucho tiempo explorando el rendimiento web, y en esta charla quiero compartir con ustedes algunas ideas sobre un tema clave. Critical CSS, una forma poderosa de mejorar la experiencia del usuario. En esta charla exploraremos qué es el Critical CSS, cuándo usarlo o no, cómo implementarlo de manera efectiva, y algunos desafíos y casos de uso comunes.

Antes de sumergirnos en el Critical CSS, comencemos desde el principio. Cómo un navegador renderiza una página. Esto involucra la ruta de renderizado crítica, una secuencia de pasos que el navegador toma para convertir HTML, CSS y JavaScript en contenido visible en la pantalla. Vamos a desglosarlo brevemente. Primero, el navegador necesita hacer una solicitud para obtener el HTML inicial. Tan pronto como recibe el primer fragmento de HTML, comienzas a construir el DOM, modelo de objeto del documento. El navegador encuentra el CSS y comienza a construir el CSOM, modelo de objeto CSS. Cuando el DOM y el CSOM están listos, el navegador los combina en un árbol de renderizado, que solo incluye los elementos visibles. Finalmente, ocurren los pasos de diseño y pintura y el contenido aparece en la pantalla.

El objetivo principal aquí es renderizar el contenido lo más rápido posible, pero los navegadores tienen recursos limitados como el tiempo y la CPU. El tiempo es crucial, porque queremos que el usuario vea el contenido lo más rápido posible, lo cual se mide por una métrica vital central llamada largest content to paint, o LCP. Y dado que todo sucede en el navegador del usuario, el uso de la CPU es igualmente importante, especialmente para dispositivos móviles. Añade a esto las velocidades de red y latencias variables. También deberíamos mencionar JavaScript aquí. JavaScript puede modificar dinámicamente el DOM y el CSOM. Manipular el DOM y el CSOM puede ser muy lento. No necesariamente y no en todos los casos, pero no entraremos en eso aquí, solo asumimos que no modificamos el DOM y el CSOM con JavaScript.

Con la comprensión de la ruta de renderizado crítica, acerquémonos a por qué el Critical CSS importa. Hemos visto que el árbol de renderizado necesita tanto el DOM como el CSOM. Sin embargo, a diferencia del DOM, el CSOM no se puede construir de manera incremental. ¿Por qué? Porque CSS es en cascada, lo que significa que el orden de las reglas CSS afecta su especificidad. La última línea de CSS podría anular todos los estilos anteriores. Esta es la razón por la cual el navegador no puede aplicar CSS parcialmente. Primero debe descargar, analizar y entender toda la hoja de estilo para evitar destellos de contenido sin estilo. ¿Cómo agregar CSS a HTML? Hay dos formas principales de agregar CSS a tu HTML. Estilos en línea usando etiquetas de estilo o hojas de estilo externas usando etiquetas de enlace.

Cada uno tiene sus compensaciones. Cuando usas una hoja de estilo externa a través de una etiqueta de enlace, el navegador debe hacer una solicitud adicional para obtenerla. Esto es a menudo beneficioso si tienes una gran cantidad de HTML y CSS, porque el navegador puede cargarlos en paralelo. Mientras se está obteniendo el CSS, el navegador puede seguir construyendo el DOM de manera incremental. Sin embargo, hay un inconveniente. CSS es bloqueado por el renderizado. El navegador necesita esperar a que la hoja de estilo termine de cargarse antes de poder construir el árbol de renderizado y mostrar la página. Si tu hoja de estilo es grande, este retraso se vuelve notable.

Las imágenes muestran que HTML, azul, y CSS, púrpura, se cargan en paralelo, pero el CSS está bloqueando el renderizado. El evento de renderizado, o la primera pintura conceptual, o FCP, ocurre inmediatamente después de que el CSS ha terminado de cargarse. La primera pintura conceptual está coloreada de verde y resaltada con bordes rojos. En esta imagen podemos ver que reducir el tamaño de la hoja de estilo externa no acelera el renderizado. Vemos que el FCP está bloqueado por CSS y el renderizado ocurre mucho después de que el documento se ha cargado y analizado completamente. Si tu CSS es pequeño, el tiempo que lleva enviar una nueva solicitud puede ser comparable al tiempo de carga.

Esto nos lleva al critical CSS. La idea detrás del critical CSS es alinear solo los estilos necesarios para renderizar el contenido por encima del pliegue directamente en la sección head de tu documento HTML. Esto evita la necesidad de una solicitud HTTP adicional y reduce el tiempo para renderizar el primer contenido significativo. Pero también hay una compensación. Si alineas demasiado CSS, aumentas el tamaño de tu sección head, lo que a su vez retrasa la capacidad del navegador para comenzar a construir el árbol de renderizado. El objetivo aquí es encontrar un punto donde alinees solo el CSS suficiente para renderizar rápidamente la parte visible de la página mientras descargas estilos menos críticos a hojas de estilo externas que se pueden cargar de manera asíncrona. Aquí hay un ejemplo de critical CSS. En esta imagen, vemos que el renderizado ocurre mientras se carga el HTML, y la hoja de estilo externa se carga de manera no bloqueante. Resumamos por qué el critical CSS es importante. Con el critical CSS, reducimos el tamaño de los estilos que bloquean el renderizado. Todo se entrega en un documento, no se requieren hojas de estilo adicionales. Esto acelera el renderizado inicial, también conocido como FCP, o First Contentful Paint. En algunos casos, el LCP también será mejor con critical CSS, si tu LCP es texto, y para imágenes depende del tamaño de la imagen. Si la imagen es demasiado grande, el LCP se retrasará debido al tiempo de carga de la imagen. Y lo más importante, mejor experiencia de usuario, especialmente para usuarios móviles con conexiones lentas.

Hay varias formas de identificar CSS crítico. Podemos dividirlas en dos grupos, manuales y automáticas. Las herramientas manuales requieren mucho copiar y pegar. No profundizaremos mucho en estas herramientas debido a su ineficiencia, pero en pocas palabras, puedes identificar estilos críticos tú mismo, simplemente analizando la página renderizada. Las herramientas de desarrollador pueden ayudar en esto. También hay algunas herramientas en línea que pueden ayudarte a extraer estilos importantes para una URL dada.

Las herramientas automáticas, por otro lado, se pueden integrar fácilmente en tu pipeline de construcción. No hay muchas herramientas automáticas para extraer CSS crítico, y algunas de ellas son muy antiguas y parecen estar abandonadas. El CSS crítico no es tan popular, pero podemos nombrar algunas. Penthouse, Critical y Besties. Penthouse, un paquete npm que ayuda a extraer CSS para una dirección URL dada, y líneas de CSS. No hay soporte para webpack. Critical, un paquete npm que extrae y alinea CSS crítico en archivos HTML, se integra bien con herramientas de construcción como Gulp y Webpack. Besties, anteriormente Critters, un paquete npm que extrae y alinea automáticamente CSS crítico para tu HTML. También hay un plugin para webpack. Critical y Penthouse usan un navegador sin cabeza, pero no Besties. Más adelante veremos los resultados obtenidos usando Besties y Critical.

Lo que necesitas para extraer tus estilos críticos. Básicamente, quieres HTML simple que esté listo para ser enviado al usuario. Este HTML es generalmente el resultado de la generación de sitios estáticos, o SSG. También hay otro tipo de renderizado del servidor donde las páginas se generan para cada solicitud. Generalmente se refiere simplemente como renderizado del lado del servidor, o SSR. En este caso, el HTML generalmente no se almacena en el sistema de archivos. Esto no es necesariamente un problema, pero aumentará la complejidad y el tiempo de procesamiento. Usar bibliotecas de CSS en JS también añadirá complejidad a la optimización de estilos críticos. Y finalmente, las limitaciones de alojamiento o del entorno. ¿Está disponible la API del sistema de archivos? ¿Tienes solo un servidor o varios? Dependiendo de esto, esto también puede aumentar significativamente la complejidad y el tiempo requerido para completar el procesamiento. ¿Cuáles son los casos de uso para CSS crítico? CSS crítico para sitios web estáticos. Esta es la mejor opción utilizada. Sitio con páginas generadas estáticamente.

Más o menos soportado por todas las herramientas. Hay una matiz con la revalidación. No todas las herramientas pueden integrarse en Webpack y soportar la revalidación. Critical CSS para sitio web estático con CSS en JS. Ninguna herramienta tiene el soporte completo de CSS en JS. Necesitamos añadir algunos pasos adicionales para optimizarlo. Esto depende de la herramienta que usemos, pero generalmente implica conectar los estilos en línea en una sola hoja de estilo externa.

Sitios web dinámicos. Por sitios web dinámicos nos referimos a sitios que generan páginas para cada solicitud de usuario o simplemente sitios con SSR. Puede ser difícil integrar CSS crítico en este sitio. Además, después de añadir la optimización, puedes darte cuenta de que esta optimización ralentiza tu sitio. La extracción de CSS crítico toma un tiempo notable e incrementa la carga en tu servidor. También necesitamos un mecanismo para aplicar estilos críticos en tiempo de ejecución o volver a los estilos por defecto para páginas no optimizadas. Beasties o Critters, por ejemplo, es soportado por Next.js como una característica experimental.

¿Cómo comprobar el efecto del CSS crítico? Para entender cómo cambia el rendimiento, debemos medir antes y después de aplicar el CSS crítico. ¿Qué medir? Esperamos un mejor renderizado inicial o FCP. En algunos casos, LCP puede ser mejor. ¿Dónde medir? El Lighthouse en el navegador Chrome siempre está a mano y es el más famoso. También tiene una versión en la nube en PageSpeed WebDev. Pero a veces los resultados pueden variar. La pestaña de rendimiento de Chrome es mejor para probar. Puedes cambiar las condiciones de red y CPU, cambiar el viewport, etc. Los resultados son más estables en comparación con el Lighthouse. WebPageTest.org es otra opción. Tiene resultados más detallados. Se puede seleccionar entre varias opciones de red, pantalla y ubicaciones. Una nota importante aquí. Los resultados solo deben compararse con resultados de la misma herramienta. En esta tabla, podemos comparar los resultados. Usamos dos herramientas para extraer CSS crítico para la misma página.

Criticals and BISTIs. La página contiene solo hojas de estilo externas. El tamaño total de los estilos es de aproximadamente 240 kilobytes.

En la primera columna, tenemos auto inline. Es una función que automáticamente inserta estilos críticos en la sección head. Ambas herramientas tienen esta función.

La segunda columna es el tiempo de procesamiento. Es el tiempo que lleva procesar una página. Vemos una gran diferencia. 330 milisegundos frente a 17 segundos.

La tercera columna es el tamaño crítico. Es el tamaño de los estilos críticos extraídos. Ambas herramientas extraen estilos del mismo tamaño. Este es un resultado interesante, ya que esperaríamos que los estilos extraídos para BISTIs fueran más grandes.

La siguiente columna es necesita pasos o configuraciones adicionales. Aquí vemos que critical no necesita acciones adicionales, pero BISTIs sí. Comentaré sobre los asteriscos un poco más tarde.

Y la columna final es diferir estilos no críticos. Critical tiene esta función, pero BISTIs no parece tenerla.

FCP y LCP corresponden al mismo elemento en esta página, un nodo de texto. Si todos los estilos se cargan a través de una hoja de estilo externa, entonces el tiempo inicial es de aproximadamente 2 segundos. Si todos los estilos están insertados en la etiqueta head, el tiempo inicial será aproximadamente 1 segundo. El tiempo después de la optimización es de 820 milisegundos.

Comentemos sobre los asteriscos. ¿Qué pasos o configuraciones adicionales podrían ser necesarios para BISTIs? Problema potencial con las fuentes. Los estilos de fuente no se extraen y embeben completamente, por lo tanto, esto podría causar un evento LCP tardío adicional al cargar la hoja de estilo completa. Aunque nada ha cambiado desde la perspectiva del usuario, se requeriría trabajo adicional para corregir este problema. Además, BISTIs no parece diferir estilos no críticos. Esto suena como un problema, pero podemos resolverlo añadiendo algo de lógica adicional para modificar el HTML. Además, parece que si combinamos ambos enfoques, CSS crítico en línea y cargar estilos completos como hojas de estilo externas, las hojas de estilo externas no bloquearán el renderizado.

En su lugar, la primera representación ocurrirá cuando se carguen las hojas de estilo externas. Así que, de todos modos, no debería ser un gran problema.

Ahora que ves los tiempos, podemos sacar algunas conclusiones. Comparamos dos de las mejores herramientas disponibles. Y, aunque BISTIs puede requerir un manejo adicional para algunos casos extremos, lo compensa con un mejor rendimiento.

Esta vez, para procesar una página, puedes calcular y averiguar cuánto tiempo tomará procesar todas tus páginas. Este tiempo se añadirá a tu pipeline de construcción. Si tienes una revalidación o SSR, entonces este tiempo se toma del tiempo de tu servidor. Esto puede interferir con el funcionamiento normal del servidor. Y en lugar de mejorar el rendimiento, puedes obtener un deterioro en el rendimiento.

Por ejemplo, para critical. Simplemente especificamos la ruta del HTML y todos los archivos CSS involucrados y el tamaño del viewport. Por ejemplo, para BISTIs. Es prácticamente lo mismo. Una diferencia importante es que no especificamos el viewport, lo que significa que extraemos estilos críticos para toda la página.

¿Qué problemas pueden surgir con los estilos críticos? Exceso de CSS en línea. Aunque en algunos casos incluir todo el CSS en línea proporcionará algunas ganancias de rendimiento, esto no siempre es así. Una gran cantidad de estilos en el head retrasará la representación, y esto sucederá todo el tiempo. Mientras que los estilos externos pueden ser almacenados en caché. Y solo la primera visita puede ser más lenta. Las visitas posteriores tendrán una representación mucho más rápida.

Critical CSS te dará un mayor impulso de rendimiento. Olvidar cargar los primeros estilos. Esta es una parte esencial de critical CSS. Divide los estilos fuente en dos partes: críticos y no críticos. Luego carga los críticos con la más alta prioridad y los no críticos de manera sincrónica. El orden de los estilos es incorrecto. Problema de especificidad. El problema puede ocurrir si no preservas el orden de los estilos. La optimización en tiempo de ejecución impacta el rendimiento.

A veces, la optimización puede tomar demasiado tiempo del servidor y, por lo tanto, degradar el rendimiento. La extracción de estilos debe realizarse en cada renderizado. Esto es importante. No puedes extraer estilos críticos solo una vez y reutilizarlos para renderizados posteriores. Algo podría cambiar. Algunos elementos que estaban previamente ocultos podrían volverse visibles. Y no querrás esto. No tendrás estos estilos en tu CSS crítico.

En ese caso, podrías tener un contenido de estilo de rendimiento deficiente. Necesitas extraer estilos para cada renderizado. Puedes detectar una nueva versión de una página por el encabezado e-tag. O verificando el hash de la página. Renderizado del lado del cliente. La optimización de Critical CSS solo se aplica al lado del servidor. Si tienes tanto renderizado del servidor como del cliente, y esos renderizados son diferentes, no puedes usar esta optimización de manera segura.

Así que, para resumir, Critical CSS se trata de encontrar un equilibrio. Se trata de entender la ruta crítica de renderizado, el papel del CSS y los compromisos entre estilos en línea y externos. Al incluir CSS crítico, puedes reducir los tiempos de renderizado y mejorar la experiencia del usuario. Especialmente en redes más lentas o dispositivos de baja potencia. Pero Critical CSS tiene un costo. Aunque Critical CSS es útil en casi todos los casos, no siempre es fácil de implementar. El procesamiento también lleva tiempo. Aunque es posible procesar páginas en tiempo de ejecución, se recomienda evitar esto y realizar la mayor parte de la optimización en tiempo de construcción. Gracias por escuchar. Espero que esto te haya dado algunas ideas sobre cómo los navegadores renderizan páginas, el papel del CSS y cuándo considerar implementar Critical CSS.