Cómo Optimizar el CSS para Sacar el Máximo Rendimiento del Sitio

Incluso en 2021, el rendimiento de la web sigue siendo un problema. Según HTTP Archive, la página media requiere una descarga de 2 MB, realiza más de 60 peticiones HTTP y puede tardar 18 segundos en cargarse completamente en un dispositivo móvil. Las hojas de estilo suponen 60 kB repartidos en siete peticiones, por lo que no suelen ser una prioridad cuando se intenta solucionar los problemas de rendimiento.

Sin embargo, el CSS sí tiene un efecto, por mínimo que parezca. Una vez que hayas abordado tu JavaScript, aprender a optimizar el CSS correctamente debería ser la siguiente prioridad.

¡Vamos a sumergirnos en el tema!

Cómo afecta el CSS al rendimiento de la página

El CSS parece inocente, pero puede requerir un procesamiento pesado.

El CSS bloquea el renderizado

Cuando tu navegador encuentra una etiqueta <link>, detiene otras descargas y procesamientos del navegador mientras obtiene y analiza el archivo CSS.

JavaScript también puede bloquear el renderizado del navegador, pero el procesamiento asíncrono es posible con:

El atributo async para descargar scripts en paralelo, que se ejecutan inmediatamente cuando están listos.
El atributo defer para descargar en paralelo, y luego ejecutar en orden cuando el DOM está listo.
El atributo type="module" para cargar un módulo ES (que se comporta como defer).

Los activos como las imágenes suelen requerir más ancho de banda, pero existen formatos eficientes y pueden cargarse de forma diferida (atributo loading="lazy") sin bloquear la renderización del navegador.

Nada de esto es posible con CSS. El archivo se almacena en la caché, por lo que las siguientes cargas de la página deberían ser más rápidas, pero el proceso de bloqueo de la renderización permanece.

Los archivos CSS grandes tardan en procesarse

Cuanto más grande sea tu hoja de estilos, más tiempo tardará en descargarse y procesarse en un modelo de objetos CSS (CSSOM), que el navegador y las API de JavaScript pueden utilizar para mostrar la página. Aunque las hojas de estilo CSS son más pequeñas que la mayoría de los archivos de un sitio web, no son inmunes a la regla de «más pequeño es mejor».

Los archivos CSS crecen

Puede ser difícil identificar los estilos que ya no se utilizan, y eliminar los equivocados puede causar estragos en un sitio. Los desarrolladores suelen optar por el enfoque más seguro de «conservar todo». Los estilos de página, los componentes y los widgets que ya no se utilizan siguen existiendo en CSS. ¿El resultado? El tamaño del archivo, la complejidad y el esfuerzo de mantenimiento aumentan exponencialmente, haciendo que los desarrolladores sean cada vez menos propensos a eliminar el código redundante.

Las hojas de estilo pueden hacer referencia a otros activos

El CSS puede hacer referencia a otras hojas de estilo utilizando reglas @import. Estas importaciones bloquean el procesamiento de la hoja de estilo actual y cargan otros archivos CSS en serie.

También se pueden referenciar otros activos, como fuentes e imágenes. El navegador intentará optimizar las descargas, pero en caso de duda, las obtendrá inmediatamente. Los archivos codificados en base64 que se encuentran dentro de la página aún requieren un mayor procesamiento.

Renderización de efectos CSS

Los navegadores tienen tres fases de representación:

La fase de maquetación (o reflujo) calcula las dimensiones de cada elemento y cómo afecta al tamaño o posicionamiento de los elementos que lo rodean.
La fase de pintura dibuja las partes visuales de cada elemento en capas separadas: texto, colores, imágenes, bordes, sombras, etc.
El compuesto dibuja cada capa en la página en el orden correcto según los contextos de apilamiento, posicionamiento, índices z, etc.

Si no tienes cuidado, los cambios de propiedades CSS y las animaciones pueden hacer que las tres fases se vuelvan a renderizar. Algunas propiedades, como las sombras y los degradados, también son computacionalmente más caras que los colores de los bloques y los márgenes.

Herramientas de análisis del rendimiento de CSS

Admitir que tienes un problema de rendimiento de CSS es el primer paso en el camino de la recuperación. Encontrar y solucionar las causas es otra cuestión.

Las siguientes herramientas y servicios (no clasificados en ningún orden) pueden ayudarte a identificar los cuellos de botella en tu código.

1. DevTools Network Panel

Los especialistas en rendimiento web pasan mucho tiempo en DevTools y en el panel de Network en particular. DevTools es nativo en la mayoría de los navegadores modernos, aunque en nuestros ejemplos utilizaremos Google Chrome.

DevTools puede abrirse desde el menú del navegador, normalmente en Más herramientas > Herramientas de desarrollo, o mediante los atajos de teclado Ctrl | Cmd + Shift + I o F12.

Cambia a la pestaña Network y asegúrate de que la opción Desactivar la caché está marcada para evitar que los archivos en caché afecten al informe. También puedes cambiar la opción de throttling para simular redes móviles más lentas.

Actualiza la página para ver el gráfico de cascada de descarga y procesamiento:

Cualquier barra larga es motivo de preocupación, pero debes tener especial cuidado con las barras largas bloqueadas/estancadas (mostradas en blanco). En este ejemplo, la fila resaltada y todas las filas siguientes no pudieron comenzar a descargarse hasta que se procesaron los archivos CSS y JavaScript que bloquean la representación en la parte superior de la página HTML.

El cuadro de filtrado le permite mostrar u ocultar activos específicos:

larger-than:<S> : Limita los archivos mayores que <S> , expresados en bytes (10.000), Kilobytes (1.000 kB) o megabytes (1 M)
-larger-than:<S> : Limita a los archivos más pequeños que <S>
-domain:*<.yourdomain.com> : Muestra las peticiones de terceros que no se cargan desde tu dominio principal. Estos juegan un factor importante que contribuye a la lentitud de los sitios.

Una página de alto rendimiento con CSS optimizado suele tener menos activos cargados en paralelo con barras cortas bloqueadas/estancadas.

2. WebPageTest

WebPageTest ofrece una vista de cascada de red similar, así como muchos otros gráficos de rendimiento:

El servicio utiliza dispositivos ubicados en diferentes lugares del mundo para poder evaluar el rendimiento en el mundo real y las optimizaciones de CSS.

3. Panel Lighthouse de Chrome DevTools

El panel DevTools Lighthouse se ofrece en navegadores basados en Chromium como Chrome, Edge, Brave, Opera y Vivaldi. Puede generar informes de rendimiento, de aplicaciones web progresivas, de mejores prácticas, de accesibilidad y de optimización de motores de búsqueda para dispositivos móviles y de escritorio.

La herramienta hace sugerencias de mejora, incluyendo formas de optimizar el CSS. Puede que no todas sean prácticas o posibles, pero se destacan las más beneficiosas.

4. Google PageSpeed Insights

PageSpeed Insights es la versión online de Lighthouse. Tiene menos funciones, pero se puede utilizar en cualquier navegador y ofrece algunas perspectivas alternativas.

Por ejemplo, un mapa de árbol muestra los mayores activos de JavaScript con una métrica de cobertura, que indica qué proporción de código se utiliza y no se utiliza:

Mapa de la página de Google PageSpeed Insights.

El CSS no se muestra, pero la cantidad de JavaScript influirá en la eficacia de los estilos.

Otras herramientas similares para comprobar la velocidad de los sitios web son Pingdom Website Speed Test y GTmetrix.

5. Chrome DevTools Coverage Panel

El panel de cobertura de DevTools en los navegadores basados en Chromium ayuda a localizar el código CSS (y JavaScript) no utilizado. Selecciona Coverage en el submenú DevTools More tools, luego actualiza tu página y navega por tu sitio/aplicación:

Los activos CSS y JavaScript se muestran en el panel de Coverage, con la proporción de código no utilizado en rojo. Haz clic en cualquier archivo para ver su código fuente con el código no utilizado resaltado en rojo en el medianil del número de línea.

Hay que tener en cuenta algunas cosas:

Las métricas de cobertura se restablecen si se actualiza o se navega a una nueva página, como es típico en un sitio de WordPress. La métrica de código no utilizado solo disminuirá si estás navegando por una aplicación de una sola página que carga el contenido sin actualizar la página.
La herramienta solo puede tener en cuenta el CSS utilizado hasta un momento determinado. No puede determinar si un widget no ha sido visualizado o tiene múltiples estados vinculados a JavaScript.

6. Monitor de rendimiento en tiempo real de Chrome DevTools

Los navegadores basados en Chromium tienen un monitor de rendimiento en tiempo real. De nuevo, está disponible en el menú DevTools More tools. Los gráficos se actualizan a medida que navegas por las páginas, te desplazas y activas las animaciones:

Las siguientes métricas son de especial interés para optimizar el rendimiento del CSS (cuanto más bajo, mejor):

Uso de la CPU: Utilización del procesador de 0% a 100%.
Layouts/seg: La velocidad a la que el navegador tiene que volver a maquetar la página.
Recalcular estilos/seg: La velocidad a la que el navegador tiene que recalcular los estilos.

Las otras métricas también pueden ser útiles si el CSS tiene problemas debido a factores externos (de nuevo, los valores más bajos indican un mejor rendimiento):

Tamaño de la pila de JS: La memoria total utilizada por los objetos de JavaScript.
Nodos DOM: El número de elementos en el documento HTML.
Escuchadores de eventos JS: El número de oyentes de eventos JavaScript registrados.
Documentos: El número de recursos, incluyendo la página, los archivos CSS, los módulos JavaScript, etc.
Marcos del documento: El número de marcos, iframes y scripts de trabajador de JavaScript.

7. DevTools Performance Report

El panel de performance de DevTools permite registrar las actividades de la página para su posterior análisis y ayuda a identificar los problemas de rendimiento. Los informes generados son complejos y muchos desarrolladores los evitan, pero proporcionan información valiosa.

El icono de configuración del panel de Rendimiento te permite establecer varias opciones, como ralentizar la red y la CPU. También puedes desactivar las muestras de JavaScript para que no se registren las pilas de llamadas detalladas.

Para empezar, haz clic en el icono circular de registro, carga y/o utiliza tu página, y luego haz clic en el botón de stop para ver el informe:

Casi todas estas métricas serán de utilidad para los desarrolladores de JavaScript, pero los problemas de optimización de CSS pueden ser especialmente evidentes desde:

Barra roja superior: Indica que la velocidad de fotogramas ha disminuido significativamente, lo que puede estar causando problemas de rendimiento. Esto es esperado al inicio de la carga de una página, pero el exceso de animaciones CSS también podría ser un problema.
Cuadro resumen: Las métricas de carga, renderizado y pintado elevadas pueden indicar problemas de CSS.

Correcciones del rendimiento del CSS indirecto

Las siguientes correcciones no solucionarán directamente los problemas de CSS, pero pueden ayudarte a solucionar algunos problemas de rendimiento con relativamente poco esfuerzo.

Utiliza un alojamiento bueno

Utilizar un buen alojamiento con servidores físicamente más cercanos a sus usuarios aportará beneficios inmediatos en cuanto al rendimiento. Los planes de alojamiento varían, pero hay tres tipos principales:

Alojamiento compartido: Tu sitio web está alojado en un servidor físico, posiblemente junto a otros cientos de sitios. El espacio en disco, la RAM, el tiempo de CPU y el ancho de banda se comparten. Los planes suelen ser económicos, pero el rendimiento y la disponibilidad se ven afectados por otros sitios. Es posible actualizarlo, pero su sitio permanecerá generalmente en la misma infraestructura.
Alojamiento dedicado: Tu sitio se aloja en uno o varios servidores físicos de tu propiedad. El hardware puede configurarse y actualizarse según las necesidades. Los planes suelen ser caros y los fallos de hardware siguen siendo problemáticos.
Alojamiento en la nube: El alojamiento en la nube abstrae la infraestructura de hardware en un conjunto de servicios a los que se puede acceder bajo demanda. Tu sitio podría ser aprovisionado a través de una gama de dispositivos para facilitar las actualizaciones.

Los planes de alojamiento en la nube y los precios varían enormemente. Puedes considerar:

Opciones de plataforma como servicio (PaaS), como servidores web y bases de datos virtuales, o
Opciones de software como servicio (SaaS), que ofrecen aplicaciones totalmente gestionadas, como WordPress.

Cambiar de host puede aumentar el rendimiento. Es poco probable que resuelva todos tus problemas, pero es una solución rentable para los problemas de backend y de ancho de banda.

También puedes considerar la posibilidad de utilizar una red de distribución de contenidos (CDN) o una CDN especializada en imágenes y vídeos que pueda distribuir la carga entre varias ubicaciones geográficamente más cercanas a los usuarios.

Aprovecha las funciones de eficiencia del navegador y del servidor

Alrededor del 10% de los sitios no activan la compresión gzip (o mejor), que suele ser la opción por defecto del servidor. Esto reduce el tamaño del CSS en un 60% o más al comprimir los archivos antes de su transmisión. No arreglará el CSS ineficiente, ¡pero el código llegará antes!

También deberías activar HTTP/2 (o mejor), que envía datos en un formato binario más pequeño, comprime las cabeceras y puede enviar más de un archivo en la misma conexión TCP.

Por último, asegúrate de que el navegador puede almacenar en caché el CSS y otros archivos de forma eficaz. Esto suele ser cuestión de establecer los hashtags Expires, Last-Modified y/o ETag en la cabecera HTTP.

Optimiza tu CMS

Los sistemas de gestión de contenidos como WordPress pueden ampliarse con temas y plugins que sirven su propio CSS. En la medida de lo posible, debería acelerar su CMS para:

Eliminar los plugins que no se utilizan.
Utilizar temas más sencillos
Habilitar el almacenamiento en caché para evitar la regeneración excesiva de las páginas.

Optimiza tus imágenes

Las imágenes no tienen la misma sobrecarga de procesamiento y renderización que el HTML, CSS y JavaScript, pero representan una gran proporción del peso de la página y del ancho de banda utilizable. Considera lo siguiente:

Eliminación de imágenes innecesarias.
Cambiar el tamaño de las imágenes grandes – quizás a no más del 150% del tamaño máximo que pueden aparecer en pantalla.
Utilizar un formato de imagen adecuado, idealmente una opción altamente comprimida como WebP o AVIF, pero posiblemente SVG para logotipos y gráficos.
Sustitución de imágenes con gradientes CSS u otros efectos.
Añadir atributos de anchura y altura a las etiquetas HTML <img> o utilizar la nueva propiedad CSS aspect-ratio para garantizar que se reserve el espacio adecuado en la página antes de que se descargue la imagen.

Una CDN de imágenes especializada puede encargarse de parte de este trabajo. Para más consejos, consulta nuestra guía sobre cómo optimizar las imágenes para la web.

Eliminar el CSS no utilizado

Los estilos más rápidos son los que nunca necesitas cargar o renderizar. Intenta eliminar/editar cualquier código CSS que ya no necesites, como el de las páginas heredadas, los widgets o los frameworks. Esto puede ser difícil en sitios grandes, y no siempre está claro si un determinado conjunto de estilos es esencial o no.

Las siguientes herramientas analizan el uso de HTML y CSS en el momento de la compilación o mediante el rastreo de URLs para identificar el código redundante. Esto no siempre es adecuado, por lo que pueden establecerse configuraciones adicionales para garantizar que los estilos activados por JavaScript y las interacciones del usuario se permitan en la lista:

Hay una opción mejor: Dividir el CSS en archivos separados con niveles claros de responsabilidad y documentar en consecuencia. Así, la eliminación de estilos innecesarios será mucho más fácil.

Optimizar el rendimiento de la carga de CSS

No todo el CSS se carga por igual. La humilde etiqueta <link> tiene una serie de opciones y peculiaridades que no siempre son lógicas.

Optimizar el uso de las fuentes web

Google Fonts y otras fundiciones de fuentes similares han revolucionado las fuentes web, pero unas pocas líneas de código de fuentes pueden suponer cientos de kilobytes de ancho de banda.

Estas son nuestras sugerencias de optimización:

Carga solo las fuentes que necesites: Elimina las fuentes que no utilices y comprueba si son necesarias nuevas fuentes.
Carga solo los pesos y estilos que necesites: La mayoría de las fundiciones de fuentes pueden limitar la descarga a determinados conjuntos de caracteres (por ejemplo, solo latinos), pesos (grosores) y cursivas (inclinaciones). Los navegadores pueden autogenerar los estilos que faltan, aunque los resultados pueden ser pobres.
Limita los caracteres necesarios: Las fuentes de uso poco frecuente pueden restringirse a caracteres específicos. Por ejemplo, el título «tutorial de CSS» en Open Sans puede definirse añadiendo un parámetro &text= a la cadena de consulta de Google fonts: fonts.googleapis.com/css?family=Open+Sans&text=CStuorial
Considera las fuentes variables: Las fuentes variables definen una gran variedad de estilos, pesos y cursivas mediante interpolación vectorial. El archivo de fuentes es un poco más grande, pero se necesita solo una en lugar de varias. La fuente recursiva demuestra la flexibilidad de las fuentes variables.
Carga las fuentes desde tu servidor local: El autoalojamiento de fuentes es más eficiente que el uso de una fundición. Se requieren menos búsquedas de DNS, y puedes restringir la descarga a WOFF2, que todos los navegadores modernos soportan. Los navegadores más antiguos (te miro a ti, IE) pueden recurrir a una fuente del sistema operativo.
Piensa en las fuentes del sistema operativo: Esa fuente web de 500 kB puede tener un aspecto estupendo, pero ¿alguien se daría cuenta si cambiaras a las fuentes habituales Helvetica, Arial, Georgia o Verdana? Las fuentes OS o web-safe son una forma sencilla de aumentar el rendimiento.

Utiliza una opción de carga de fuentes adecuada

Las fuentes web pueden tardar unos segundos en descargarse y procesarse. El navegador lo hará:

Mostrar un flash de texto sin estilo (FOUT): La primera fuente disponible se utiliza inicialmente, pero es reemplazada una vez que la fuente web está lista.
Mostrar un Flash de Texto Invisible (FOIT): No se muestra ningún texto hasta que la fuente web esté lista. Este es el proceso por defecto en los navegadores modernos, que suelen esperar tres segundos antes de volver a una fuente de reserva.

Ninguno de los dos es ideal. La propiedad CSS font-display y el parámetro Google Font & display = pueden seleccionar una opción alternativa:

auto: El comportamiento por defecto del navegador (normalmente FOIT).
bloque: Efectivamente FOIT. El texto es invisible hasta tres segundos. No hay cambio de fuente, pero el texto puede tardar en aparecer.
swap: Efectivamente FOUT. Se utiliza la primera fuente alternativa hasta que la fuente web esté disponible. El texto es inmediatamente legible, pero el efecto de cambio de fuente puede ser discordante. Se puede utilizar Font Style Matcher para definir una fuente alternativa de tamaño similar.
fallback: Un compromiso entre FOIT y FOUT. El texto es invisible durante un breve período (normalmente 100 ms), luego se utiliza el primer fallback hasta que la fuente web esté disponible.
opcional: Similar al fallback, excepto que no se produce un intercambio de fuentes. La fuente web solo se utilizará si está disponible dentro del período inicial. La vista de la primera página probablemente mostrará una fuente de reserva, y las siguientes vistas utilizarán la fuente web descargada y almacenada en caché.

El uso de swap, fallback u opcional puede ofrecer un aumento de rendimiento percibido.

Evitar el CSS @import

La regla @import at-rule incluir archivos CSS dentro de otros:

/* main.css */
@import url("reset.css");
@import url("grid.css");
@import url("widget.css");

Esto parece una forma efectiva de cargar componentes y fuentes más pequeñas. Desafortunadamente, cada @importación bloquea la renderización, y cada archivo debe ser cargado y analizado en serie.

Múltiples etiquetas <link> dentro de HTML son más eficientes y cargan los archivos CSS en paralelo:

<link rel="stylesheet" href="reset.css">
<link rel="stylesheet" href="grid.css">
<link rel="stylesheet" href="widget.css">

Dicho esto, es mejor…

Concatenar y reducir el CSS

Las herramientas de construcción modernas, los preprocesadores de CSS como Sass y los plugins de WordPress pueden combinar todos los parciales en un solo archivo CSS de gran tamaño. Los espacios en blanco, los comentarios y los caracteres innecesarios se eliminan para reducir el tamaño del archivo al mínimo.

Los archivos múltiples suponen un problema de rendimiento menor con HTTP/2 y versiones superiores, pero un solo archivo requiere una sola cabecera y puede comprimirse y almacenarse en caché de forma más eficiente.

Los archivos CSS separados solo son prácticos cuando se tienen una o más hojas de estilo que se cambian con frecuencia, quizás varias veces por semana. Incluso entonces, el código CSS mayoritariamente estático puede combinarse en un solo archivo.

Los clientes de Kinsta pueden acceder a la función de minificación de código en su panel de control de MyKinsta para ayudar en esta tarea. Esta función permite a los clientes activar la minificación automática de CSS y JavaScript con un simple clic. Esto ayuda a acelerar tu sitio sin ningún esfuerzo manual.

Evitar la codificación Base64

Las herramientas pueden codificar las imágenes en cadenas base64, que puede utilizar como URI de datos en las etiquetas HTML <img> y en los fondos CSS:

.background {
  background-image: url('data:image/jpg;base64,ABC123...');
}

Esto reduce el número de peticiones HTTP, pero perjudica el rendimiento del CSS:

Las cadenas en base64 pueden ser un 30% más grandes que su equivalente binario.
los navegadores deben decodificar la cadena antes de poder utilizar una imagen, y
La alteración de un píxel de la imagen invalida todo el archivo CSS.

Solo considera la codificación base64 si utiliza imágenes muy pequeñas que cambian con poca frecuencia y cuya cadena resultante no es significativamente más larga que una URL.

Dicho esto, puedes codificar en UTF8 los iconos SVG reutilizables, por ejemplo

.svgbackground {
  background-image: url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 600"><circle cx="300" cy="300" r="150" stroke-width="3" stroke="#f00" fill="#ff0" /></svg>');
}

Eliminar los CSS Hacks y los Fallbacks de IE

A menos que seas desafortunado y tengas una alta proporción de usuarios de Internet Explorer, las hojas de estilo condicionales de IE y los hacks pueden ser eliminados de tu CSS. En la mayoría de los casos, los usuarios de IE seguirán viendo algo, especialmente si utilizas un diseño mobile-first que muestra una vista lineal más sencilla por defecto. El resultado puede no ser bonito, y no será perfecto en cuanto a píxeles, pero tu presupuesto de desarrollo está mejor gastado teniendo en cuenta la accesibilidad para todos los usuarios.

Precarga de archivos CSS

La etiqueta <link> proporciona un atributo opcional de precarga que puede iniciar una descarga inmediatamente en lugar de esperar la referencia real en el HTML:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>My page</title>
  <!-- preload styles -->
  <link rel="preload" href="/css/main.css" as="style" />
  <!-- lots more code -->
  <!-- load preloaded styles -->
  <link rel="stylesheet" href="/css/main.css" />

Esto es especialmente beneficioso en WordPress y otros CMS’ donde un plugin podría añadir una hoja de estilos más abajo en la página.

Uso de CSS crítico en línea

Las herramientas de análisis pueden sugerirte «alinear el CSS crítico» o «reducir las hojas de estilo que bloquean la renderización». Esto mejora el rendimiento:

Identificar los estilos esenciales utilizados por los elementos por encima del pliegue (los visibles cuando se carga la página)
Inluyendo ese CSS crítico en una etiqueta <style> en tu <head>
Cargar el resto de CSS de forma asíncrona para evitar el bloqueo de la renderización. Esto puede lograrse cargando la hoja de estilos en un estilo «print» al que el navegador da una prioridad menor. Luego, JavaScript lo cambia a un estilo «all» media una vez que la página se ha cargado (un <noscript> asegura que el CSS funciona si JavaScript no está disponible):

<style>
/* critical styles */
body { font-family: sans-serif; color: #111; }
</style>
<!-- load remaining styles -->
<link rel="stylesheet" 
     href="/css/main.css"
    media="print" 
   onload="this.media='all'">
<noscript>
  <link rel="stylesheet" href="/css/main.css">
</noscript>

Herramientas como critical y criticalCSS pueden ayudar a extraer los estilos de los elementos de la vista.

La técnica mejora notablemente el rendimiento y aumenta las puntuaciones de las auditorías. Los sitios o aplicaciones con interfaces consistentes deberían ser más sencillos de implementar, pero puede ser más difícil en otros casos:

Una herramienta de construcción es esencial para todos los sitios, excepto los más sencillos.
El «pliegue» es diferente en cada dispositivo.
Los sitios pueden tener una variedad de diseños que requieren diferentes CSS críticos.
Las herramientas CSS críticas pueden tener problemas con marcos específicos, HTML generado en el lado del cliente y contenido dinámico.
Esta técnica beneficia sobre todo a la carga de la primera página. El CSS se almacena en la caché para las páginas siguientes, por lo que los estilos alineados adicionales aumentarán el peso de la página.

Utiliza el renderizado de consulta de medios

Un único concatenado y minificado beneficiará a la mayoría de los sitios, pero los sitios que requieren una cantidad significativa de estilos de pantalla más grandes podrían dividir los archivos CSS y cargarlos utilizando una consulta de medios:

<!-- core styles loaded on all devices -->
<link rel="stylesheet" href="core.css">
<!-- served to screens at least 40em wide -->
<link rel="stylesheet" media="(min-width: 40em)" href="40em.css">
<!-- served to screens at least 80em wide -->
<link rel="stylesheet" media="(min-width: 80em)" href="80em.css">

Este ejemplo presupone una metodología «mobile-first». Los dispositivos móviles cargan core.css pero no necesitan descargar o analizar el resto de hojas de estilo.

Utiliza el renderizado progresivo

El renderizado progresivo es una técnica que define hojas de estilo individuales para páginas o componentes separados. Puede beneficiar a sitios muy grandes donde las páginas individuales se construyen a partir de una amplia gama de componentes.

Cada archivo CSS se carga inmediatamente antes de que un componente sea referenciado en el HTML:

<head>
  <!-- core styles -->
  <link rel="stylesheet" href="core.css" />
</head>
<body>
  <!-- header -->
  <link rel="stylesheet" href="header.css" />
  <header>...</header>
  <!-- primary content -->
  <link rel="stylesheet" href="main.css" />
  <main>
    <!-- widget styling -->
    <link rel="stylesheet" href="widget.css" />
    <div class="mywidget>...</div>
  </main>
  <!-- footer -->
  <link rel="stylesheet" href="footer.css" />
  <footer>...</footer>
</body>

Esto funciona bien en la mayoría de los navegadores. (Safari muestra una página en blanco hasta que se carga todo el CSS, pero no debería ser notablemente peor que una sola hoja de estilos grande).

La adopción de Web Components también fomenta el uso de estilos de alcance que se cargan cuando se renderiza el elemento personalizado.

Optimizar el rendimiento del CSS

Las técnicas y propiedades de CSS ejercen diferentes presiones sobre el navegador, la CPU, la memoria, el ancho de banda y otros recursos. Los siguientes consejos pueden ayudarte a evitar el procesamiento innecesario y la lentitud en el rendimiento.

Adoptar técnicas modernas de diseño (Grid y Flexbox)

Los diseños basados en flotadores son difíciles de crear, utilizan numerosas propiedades, requieren continuos ajustes de márgenes y rellenos, deben ser gestionados mediante consultas de medios e incurren en un considerable procesamiento del navegador. Fueron el único método de diseño viable durante muchos años, pero ya no son necesarios. Utiliza cualquiera de los dos:

CSS Flexbox para diseños unidimensionales que pueden pasar a la siguiente fila. Es ideal para menús, galerías de imágenes, tarjetas, etc.
CSS Grid para diseños bidimensionales con filas y columnas explícitas. Es ideal para diseños de páginas.

Ambos son más sencillos de desarrollar, utilizan menos código, se renderizan más rápido y se adaptan a cualquier tamaño de pantalla sin necesidad de consultas de medios.

Los navegadores muy antiguos no reconocerán las propiedades modernas de flexbox y grid, por lo que cada elemento se convierte en un bloque. Muéstralos en un diseño lineal simple como el de los móviles: no hay necesidad de emular el diseño con fallbacks basados en flotación.

Reemplazar imágenes con gradientes y efectos CSS

Siempre que sea posible, opta por el código CSS en lugar de las imágenes. Experimenta con degradados, bordes, radios, sombras, filtros, modos de fusión, máscaras, recortes y efectos de pseudoelementos para reutilizar o sustituir las imágenes existentes.

Los efectos CSS utilizan mucho menos ancho de banda, son más fáciles de modificar y normalmente pueden ser animados.

Evita el uso excesivo de propiedades

Puede tener un código declarativo terso, pero algunos CSS requieren más procesamiento que otros. Las siguientes propiedades desencadenan cálculos de pintura que pueden ser costosos cuando se utilizan en exceso:

position: fixed
border-radius
box-shadow
text-shadow
opacity
transform
filter
backdrop-filter
background-blend-mode

Utiliza transiciones y animaciones CSS cuando sea posible

Las transiciones y animaciones CSS siempre serán más suaves que los efectos basados en JavaScript, que modifican propiedades similares. No se procesarán en los navegadores más antiguos, pero como es probable que se ejecuten en dispositivos de menor capacidad, es lo mejor.

Sin embargo, hay que evitar las animaciones excesivas. Los efectos deben mejorar la experiencia del usuario sin afectar negativamente al rendimiento o causar mareos. Comprueba la consulta de medios «prefiere movimiento reducido» y desactiva las animaciones cuando sea necesario.

Evita animar las propiedades que desencadenan un re-diseño

Alterar las dimensiones de un elemento (ancho, alto, relleno, borde) o la posición (arriba, abajo, izquierda, derecha, margen) puede hacer que toda la página se redistribuya en cada fotograma de la animación. Las propiedades más eficientes para animar son:

opacity
filter: Desenfoque, contraste, sombra y otros efectos
transform: Trasladar (mover), escalar o rotar un elemento

Los navegadores pueden utilizar la GPU acelerada por hardware para renderizar estos efectos en su propia capa, por lo que solo se ve afectada la etapa de composición.

Si tiene que animar otras propiedades, puede mejorar el rendimiento sacando el elemento del flujo de la página con position: absolute.

Cuidado con los selectores complejos

Los navegadores analizarán rápidamente los selectores CSS más complejos, pero simplificarlos reduce el tamaño de los archivos y mejora el rendimiento. Los selectores complejos suelen generarse cuando se crean estructuras profundamente anidadas en preprocesadores de CSS como Sass.

Indica qué elementos cambiarán

La propiedad CSS will-change permite advertir cómo se modificará o animará un elemento para que el navegador pueda realizar optimizaciones por adelantado:

.myelement {
  will-change: transform, opacity;
}

Se puede definir cualquier número de valores separados por comas, pero la propiedad solo debe utilizarse como último recurso para solucionar problemas de rendimiento conocidos. No debes aplicarla a demasiados elementos y asegúrate de darle el tiempo suficiente para que se inicialice.

Considera la contención del CSS

La contención es una nueva función de CSS que puede mejorar el rendimiento al permitir identificar subárboles aislados de una página. El navegador puede optimizar el procesamiento al renderizar -o no renderizar- un bloque de contenido DOM específico.

La propiedad contain acepta uno o más de los siguientes valores en una lista separada por espacios:

none: La contención no se aplica
layout: El diseño del elemento está aislado del resto de la página – su contenido no afectará a otros elementos
paint: Los hijos del elemento no se muestran fuera de su límite
size: El tamaño del elemento puede determinarse sin comprobar los elementos hijos: las dimensiones son independientes del contenido

También hay dos valores especiales disponibles:

strict: Se aplican todas las reglas de contención (excepto ninguna)
content: Aplica el diseño y la pintura

La contención CSS está soportada en la mayoría de los navegadores modernos. No hay soporte en Safari o en aplicaciones más antiguas, pero la contención se puede utilizar con seguridad en estos porque el navegador simplemente ignorará la propiedad.

Reaccionar al Save-Data

Save-Data es una cabecera de petición HTTP que indica que el usuario ha solicitado datos reducidos. Puede estar etiquetado como modo «Lite» o «Turbo» en algunos navegadores.

Cuando se activa, se envía una cabecera Save-Data con cada solicitud del navegador:

GET /main.css HTTP/1.0
Host: site.com
Save-Data: on

El servidor puede responder en consecuencia cuando se detecta la función Save-Data. En el caso de CSS, podría enviar un diseño lineal más sencillo similar al de los móviles, utilizar una fuente OS, cambiar a colores de bloque o cargar fondos de imágenes de baja resolución.

Ten en cuenta que el servidor debe devolver la siguiente cabecera en las solicitudes modificadas para garantizar que el contenido mínimo no se almacena en la caché y se reutiliza cuando el usuario desactiva el modo Lite/Turbo:

Vary: Accept-Encoding, Save-Data

La cabecera también puede ser detectada por el JavaScript del lado del cliente. El siguiente código añade una clase bestUX al elemento <html> cuando Save-Data no está activado:

if ('connection' in navigator && !navigator.connection.saveData) {
  document.documentElement.classList.add('bestUX');
}

Las hojas de estilo pueden reaccionar en consecuencia sin necesidad de manipular el servidor:

/* no hero image by default */
header {
  background-color: #abc;
  background-image: none;
}
/* hero image when no Save-Data */
.bestUX header {
  background-image: url("hero.jpg");
}

La consulta de medios «prefers-reduced-data» ofrece una opción de solo CSS como alternativa, aunque no es compatible con ningún navegador en el momento de escribir este artículo:

/* no hero image by default */
header {
  background-color: #abc;
  background-image: none;
}
/* hero image when no Save-Data */
@media (prefers-reduced-data: no-preference) {
  header {
    background-image: url("hero.jpg");
  }
}

Resumen

Hay muchas opciones para optimizar el rendimiento del CSS, pero para los nuevos proyectos, considere las siguientes prácticas:

Utiliza un enfoque «mobile-first»: Codifica primero el diseño móvil más sencillo y luego añade mejoras a medida que el espacio de la pantalla y el conjunto de características del navegador aumenten.
Dividir el CSS en archivos separados con responsabilidades identificables: Un preprocesador de CSS o un plugin de CMS puedes combinar los parciales de CSS en un solo archivo.
Añade un paso de compilación: Existen herramientas que pueden eliminar automáticamente el código, identificar problemas, concatenar, minificar, reducir el tamaño de las imágenes, etc. La automatización facilita la vida, y es menos probable que te olvides de un paso de optimización.
Documenta tus hojas de estilo: Una guía de estilo con ejemplos documentados hará que tu código sea más fácil de recoger y mantener. Podrás identificar y eliminar el CSS antiguo sin sudar.

Por último, ¡aprende CSS! Cuanto más sepas, menos código tendrás que escribir y más rápida será tu aplicación web. Te convertirá en un mejor desarrollador independientemente de las plataformas y frameworks que utilices.

¿Qué otros consejos tienes para optimizar el rendimiento del CSS? Compártelos en la sección de comentarios.

Craig Buckler

Desarrollador web, escritor y conferenciante freelance del Reino Unido. Lleva mucho tiempo en esto y despotrica sobre estándares y rendimiento.