Idiomas

CSS crítico

CSS crítico: extraer los estilos por encima del pliegue, insertarlos en línea y diferir el resto para acelerar el primer pintado. Por qué Google lo considera una técnica avanzada y opcional, las contrapartidas reales (pérdida de caché, riesgo de mantenimiento, condiciones de carrera) y cómo saber si el CSS es realmente tu cuello de botella.

Publicado por primera vez: 3 jul 2026 · Última actualización: 8 ago 2026 · Avanzado
Idiomas
AIEscrito porAI v2

El CSS crítico es una técnica de rendimiento: extraer el CSS necesario para renderizar una vista por encima del pliegue elegida, insertarlo en línea en el <head> y diferir el resto de la hoja de estilos de forma asíncrona. Funciona porque el CSS bloquea el renderizado por defecto: el navegador no pinta nada hasta que se construye el CSSOM. No existe una altura universal para lo que está por encima del pliegue (el dispositivo, la orientación, el zoom y el estado de la página la cambian), así que trata la división como una decisión, no como un corte fijo en píxeles. Lo más importante que hay que entender: Google presenta el CSS crítico como una técnica avanzada y opcional, no como una recomendación por defecto; su propia documentación dice: «La mayoría de los sitios deberían poder alcanzar todos nuestros objetivos de rendimiento recomendados sin implementar esta técnica». Las contrapartidas son reales: el CSS insertado en línea no se almacena en caché para visitas repetidas (las segundas visualizaciones pueden ser más lentas), la división entre crítico y no crítico se rompe silenciosamente cuando cambian las plantillas o los estados, una política style-src de CSP puede bloquear directamente el bloque en línea, y el diferimiento con preload/onload puede generar condiciones de carrera o causar cambios de diseño. Primero diagnostica: confirma que el CSS (y no el JavaScript ni el tiempo de respuesta del servidor) es realmente tu cuello de botella de renderizado antes de tocarlo. El impacto en el SEO es indirecto, a través de las Core Web Vitals (Métricas web esenciales)/LCP, y no una señal de posicionamiento directa. No hay directrices específicas de Bing. Esta página se anida bajo el hub de Critical Rendering Path.

TL;DR — CSS crítico = extraer los estilos de la parte visible inicial (above the fold), insertarlos inline en el <head> y diferir el resto de la hoja de estilos de forma asíncrona (rel="preload" + intercambio (swap) en onload, fallback de <noscript> o loadCSS). Funciona porque el CSS bloquea el renderizado por defecto. La columna vertebral de precisión: Google lo presenta como algo avanzado y opcional, no como una recomendación predeterminada — «Most sites should be able to achieve all of our recommended performance targets without implementing this technique.» (traducción) «La mayoría de los sitios deberían poder alcanzar todos nuestros objetivos de rendimiento recomendados sin implementar esta técnica.» Mantén pequeña la carga inline. Las contrapartidas son reales: el CSS inline no se almacena en caché entre cargas de página (las visitas repetidas pueden ser más lentas), la división crítico/no crítico se rompe a medida que cambian las plantillas, y el diferimiento puede generar condiciones de carrera o causar FOUC/CLS. Diagnostica primero — confirma que el CSS (y no JavaScript ni el tiempo de servidor) es el cuello de botella real. Cuidado con las minas que una demo rápida no te mostrará: una política style-src de CSP puede bloquear directamente tu bloque <style> inline, “unused at capture” (traducción) «sin uso en el momento de la captura» no es lo mismo que “safe to defer” (traducción) «seguro de diferir» en todos los temas/personalizaciones/estados, y la inserción inline no resuelve los tiempos de carga de fuentes. El impacto en el SEO es indirecto, a través de Core Web Vitals (Métricas web esenciales)/LCP. No existe orientación específica para Bing.

Qué es realmente el CSS crítico

El problema que resuelve es el CSS que bloquea el renderizado. El web.dev de Google es explícito: Por defecto, el CSS se trata como un recurso que bloquea el renderizado, lo que significa que el navegador no renderizará ningún contenido procesado hasta que se construya el CSSOM. Esa es la razón de ser de la técnica — el navegador se niega a pintar hasta que tiene tus estilos, así que cualquier cosa que retrase el CSS retrasa el primer pintado. (Para conocer el pipeline completo que subyace a esto, consulta el hub de critical rendering path en el que se enmarca esta página, y su complementario, recursos que bloquean el renderizado.)

El CSS crítico ataca eso dividiendo tu CSS en dos. la definición de web.dev: «Critical CSS is a technique that extracts the CSS for above-the-fold content in order to render content to the user as fast as possible.» (traducción) «El CSS crítico es una técnica que extrae el CSS del contenido visible en la parte superior de la página con el fin de renderizar el contenido para el usuario lo más rápido posible.» Y la mecánica: Incrustar los estilos extraídos en el <head> del documento HTML elimina la necesidad de realizar una solicitud adicional para obtener estos estilos. El resto del CSS puede cargarse de forma asíncrona.

Evidence for this claim Critical CSS extracts and inlines above-the-fold styles so the remaining CSS can load asynchronously. Scope: web.dev definition and implementation outline for critical CSS. Confidence: high · Verified: web.dev: Extract critical CSS

Hay algo que web.dev deja claro y que muchas guías secundarias pasan por alto: no existe una altura única y universal para la parte superior visible — el tamaño del dispositivo, la orientación, la interfaz del navegador, el nivel de zoom y el estado de la página (un menú abierto, la personalización cargada, un estado de error), todo ello cambia lo que realmente tiene que estar en el conjunto “crítico”. Trata el CSS crítico como una decisión sobre un viewport/estado inicial elegido, no como un corte fijo de píxeles, y valídalo contra tus breakpoints y estados reales — no contra una sola captura de pantalla de escritorio.

Así que son dos tareas, en orden:

  1. Inserta en línea el CSS mínimo de la parte superior visible (above-the-fold) en el <head> — sin ningún viaje de ida y vuelta adicional antes del primer renderizado (first paint).
  2. Difiere el resto de la hoja de estilos — cárgala de forma asíncrona para que nunca bloquee ese primer renderizado.

Así es exactamente como lo he dividido en mis charlas sobre experiencia de página. En mi presentación Lo que sigue para la experiencia de página (SMX Next 2021) dividí el trabajo de CSS en dos grupos: una ruta temprana/crítica (eliminar el CSS sin usar → minificar el CSS → insertar en línea el CSS crítico) y una ruta tardía/diferida (diferir el CSS no crítico). La misma estructura que la de web.dev, solo que ordenada de la forma en que yo lo pienso.

Cómo implementarlo

Paso 1 — inserta el CSS crítico en línea. La propia recomendación de Lighthouse es insertar los estilos críticos necesarios para el primer renderizado dentro de un bloque <style> en el head de la página HTML. El objetivo de tamaño de Google para esa carga útil insertada en línea, según la misma página: procura mantener el contenido por encima del pliegue por debajo de 14 KB (comprimido), para que quepa en la primera ida y vuelta de red. Considera esa cifra como una orientación de transporte histórica más que como una especificación atemporal — la página de origen data de 2019 y es anterior al amplio despliegue actual de HTTP/2 and HTTP/3, y ambos cambian los cálculos de la primera ida y vuelta. Sigue siendo la cifra que cita la propia documentación de Google, pero si estás ajustando con precisión, verifícala frente a tu protocolo actual y el comportamiento de tu servidor en lugar de tratar los 14 KB como una verdad absoluta.

Paso 2 — difiere el resto. El patrón que web.dev recomienda para diferir el CSS no crítico es un preload con un intercambio en onload además de una alternativa <noscript>:

<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>

El consejo de web.dev para producción es usar funciones para diferir CSS, como loadCSS, que encapsulan este comportamiento y funcionan bien en todos los navegadores en lugar de implementar el intercambio manualmente. Si, en cambio, lo difieres con JavaScript, web.dev señala que esperar a que se ejecute JavaScript antes de cargar el CSS no crítico puede causar retrasos en el renderizado cuando los usuarios se desplazan — por eso se usa preload para iniciar la descarga antes.

Herramientas. Rara vez extraes el CSS crítico a mano. La implementación de referencia de Google es el paquete de npm critical (Addy Osmani) — “a tool that extracts, minifies and inlines above-the-fold CSS.” (traducción) «una herramienta que extrae, minifica e inserta en línea el CSS de la parte visible sin desplazamiento». Las alternativas incluyen Penthouse y CriticalCSS, además de una gran cantidad de generadores SaaS/plugin para WordPress y Shopify. Para encontrar las reglas críticas tú mismo, Google te dirige a la pestaña Coverage de Chrome DevTools para identificar CSS y JS no críticos.

Si estás usando un plugin o generador (WP Rocket, Autoptimize y similares), no tomes el recorrido por la interfaz de usuario de un proveedor o una captura de pantalla de la puntuación antes/después como una garantía de la plataforma — esas páginas mezclan libremente versiones del producto y resultados de sitios específicos, y las diferencias de puntuación no se reproducen de forma independiente. Antes de confiar en uno en producción: confirma el comportamiento con la documentación actual del plugin y el número de versión, y somételo a la misma matriz de pruebas que usarías para una implementación manual — cargas en frío y repetidas, tus puntos de ruptura/temas/estados reales y tu política CSP si usas una.

Ten en cuenta que el CSS crítico es solo una de las soluciones para el CSS que bloquea el renderizado. Las otras son delimitar el alcance de las hojas de estilo con el atributo media (para que se descarguen pero no bloqueen el pintado) y, desde el principio, simplemente enviar menos CSS; de hecho, el artículo sobre recursos que bloquean el renderizado de web.dev se apoya en el enfoque del atributo media en lugar de la inclusión en línea, por lo que Google tiene más de una recomendación oficial dependiendo del documento que leas.

La postura real de Google (la columna vertebral de la precisión)

Esta es la parte que casi todos los artículos de la competencia ocultan, y es la razón principal por la que quería escribir este artículo. Google no presenta el CSS crítico como una recomendación predeterminada. Su codelab es directo sobre el riesgo: este codelab describe una técnica avanzada de rendimiento que puede mejorar el rendimiento, pero también puede provocar errores si no se implementa correctamente. Y, dos veces en su documentación, Google dice que la mayoría de los sitios no deberían tomarse la molestia: la mayoría de los sitios deberían poder alcanzar todos nuestros objetivos de rendimiento recomendados sin implementar esta técnica.

Evidence for this claim web.dev presents critical CSS as an advanced technique that can cause bugs and says most sites can meet performance targets without it. Scope: web.dev codelab guidance; not a universal recommendation. Confidence: high · Verified: web.dev: Extract and inline critical CSS

Incluso el beneficio viene con una advertencia. web.dev señala que la inserción en línea también tiene desventajas porque impide que el navegador almacene en caché el CSS para reutilizarlo en cargas de página posteriores, por lo que conviene usarla con moderación — y, sobre excederse, si todo se prioriza, entonces nada se prioriza. Si insertas demasiado en línea, inflas el HTML que estás intentando entregar rápidamente.

Así que el enfoque honesto es: el CSS crítico es una técnica real, documentada y a veces potente — y una técnica avanzada, opcional y de último recurso que, según Google, la mayoría de los sitios no necesitan para alcanzar sus objetivos. Trátalo así.

Las compensaciones reales

Los ingenieros de rendimiento independientes han sido las voces más fuertes aquí, y coinciden con las propias advertencias de Google.

Pérdida de caché en visitas repetidas. Matt Zeunert de DebugBear lo afirma sin rodeos: el CSS crítico no puede reutilizarse entre distintas cargas de página en tu sitio web; por eso las vistas posteriores pueden ser más lentas de lo que serían sin CSS crítico. Una hoja de estilo externa normal se almacena en caché una vez y se reutiliza en todas partes; el CSS en línea se vuelve a descargar dentro de cada respuesta HTML.

Riesgo de mantenimiento y regresión. El artículo contrario de Harry Roberts es la opinión más citada, y su advertencia es que adaptar el CSS crítico a posteriori es difícil y propenso a errores: una vez que has identificado el CSS como tu cuello de botella, «you need to keep it that way… One wrong decision can undo everything.» (traducción) «tienes que mantenerlo así… Una decisión equivocada puede deshacerlo todo.» No hay revalidación automática — un cambio de plantilla o diseño puede romper silenciosamente tu división de CSS crítico/no crítico.

Condiciones de carrera en el aplazamiento. Roberts también señala que el intercambio preload/onload puede salir mal por los tiempos: si tardas 1 s en analizar tu <head> y 0,5 s en obtener de forma asíncrona el CSS no crítico, el CSS volverá a convertirse en un archivo síncrono 0,5 s antes de que estuvieras listo para continuar. Y cuando el CSS no crítico llega tarde, te arriesgas a un destello de contenido sin estilo y a un cambio de diseño.

A menudo ni siquiera es el cuello de botella. La tesis central de Roberts: El CSS crítico solo ayuda si el CSS es tu mayor cuello de botella que bloquea el renderizado y, con bastante frecuencia, no lo es. DebugBear coincide: antes de insertarlo en línea, comprueba si el CSS es realmente el problema, porque si aún tienes código JavaScript que bloquea el renderizado, es poco probable que insertar el CSS en línea ayude, y «often it’s not the most impactful optimization.» (traducción) «a menudo no es la optimización de mayor impacto.»

Minas terrestres en producción: CSP, estado y fuentes

Tres modos de fallo más que no aparecen en una demo rápida, pero que muerden cuando esto está en producción:

Una política CSP puede bloquear directamente tu bloque <style> en línea. Una política style-src de Content-Security-Policy puede bloquear un bloque <style> crítico en línea a menos que la política lo permita explícitamente, normalmente mediante un nonce o un hash coincidente. MDN documenta los casos de infracción y los mecanismos de nonce/hash. Recurrir a unsafe-inline para hacer desaparecer el error de la consola debilita la política en todo el sitio y no es la solución predeterminada: integra la generación de nonce/hash en la herramienta que extrae el CSS crítico y comprueba si hay infracciones en la consola del navegador después de publicar.

«Sin usar en la captura» no es lo mismo que «seguro de diferir». La pestaña Coverage te indica qué CSS se ejecutó durante una ejecución registrada. Una división segura tiene que preservar el orden de cascada y las reglas necesarias para tus breakpoints responsive, las variantes de tema, el contenido personalizado, los estados de foco, los menús/modales abiertos y los estados de error, no solo lo que resultó renderizado en esa única pasada. Roberts plantea la misma pregunta desde otro ángulo: ¿qué viewport y qué elementos fuera de pantalla o con los que no se interactuó (dropdowns, flyouts) necesita cubrir realmente tu extracción?

No resuelve tu problema de fuentes, y puede añadir trabajo de renderizado. Insertar en línea los estilos de los elementos no hace por sí mismo que una fuente web se descubra antes ni garantiza que el texto se renderice a tiempo; el descubrimiento de fuentes, preload, font-display y las métricas de fallback son dependencias separadas que el CSS crítico no toca. Y aplicar un subconjunto en línea seguido de una hoja de estilos más grande puede significar recálculo de estilos, layout y pintado adicionales; reducir la demora de descarga no significa automáticamente menos trabajo total de renderizado. Mide ambos, no solo la cascada de red.

Cómo diagnosticar si siquiera lo necesitas

Dado todo lo anterior, no empieces por «añadir CSS crítico»; empieza por «confirmar que el CSS es mi cuello de botella de renderizado» y no te detengas ahí. Cuatro condiciones, y todas tienen que cumplirse antes de que valga la pena hacerlo:

1. El CSS es un bloqueador comprobado, no una suposición.

  • Abre el informe de PageSpeed Insights / Lighthouse. A partir de Lighthouse 13, la antigua auditoría «Eliminate render-blocking resources» se ha integrado en el insight Render-blocking requests — por lo que los artículos antiguos que hacen referencia al nombre anterior de la auditoría están desactualizados.
  • Usa la pestaña Coverage de Chrome DevTools para ver cuánto de tu CSS (y JS) realmente no se usa en el primer renderizado.
  • Separa las causas. Si tu cuello de botella es JavaScript que bloquea el renderizado, o una respuesta del servidor (TTFB) lenta, insertar CSS en línea no lo solucionará — estarías optimizando lo equivocado.

2. Puedes construir una cobertura de extracción realmente estable — en todos tus breakpoints reales, temas, personalización y estados interactivos, no en una sola captura de pantalla de escritorio (consulta las minas mencionadas arriba).

3. El costo de las vistas repetidas y de CSP es aceptable. El CSS en línea no se almacena en caché, así que sopesa eso frente a la profundidad típica de tus sesiones. Si aplicas una política CSP style-src, la generación de nonce/hash debe integrarse en el pipeline antes de lanzar esto, no descubrirse después.

4. Realmente lo mantendrás. Regenéralo en cada cambio de plantilla o diseño y vuelve a ejecutar la matriz de pruebas completa — cargas en frío y repetidas, cada ruta/viewport/ estado que admitas — no una sola verificación visual después del despliegue.

Si se cumplen las cuatro condiciones, el CSS crítico vale el costo de mantenimiento. Si alguna no se cumple, las soluciones más económicas — eliminar el CSS no utilizado, minificar y limitar las hojas de estilo no críticas con media — son una opción mejor.

Un problema actual de 2026

Hay una complicación vigente que vale la pena señalar: existe un informe abierto y sin resolver que indica que el patrón exacto <link rel="preload" as="style"> que la documentación de Google recomienda para diferir el CSS comenzó a marcarse nuevamente como un recurso que bloquea el renderizado después de una actualización puntual de Lighthouse/PSI. GitHub issue #17031 documenta que el CSS precargado aparecía en verde en Lighthouse 13.0.1 y luego se marcaba como un recurso que bloquea el renderizado en 13.3.0. En el momento de escribir esto no hay una resolución pública de Google, así que trátalo como un tema en desarrollo — pero la lección práctica se mantiene: si PSI marca tu CSS diferido correctamente, la propia auditoría puede estar equivocada, así que lee el informe críticamente en lugar de asumir que tu implementación está rota.

¿El CSS crítico ayuda al SEO?

Indirectamente, y de forma modesta. Hay dos cosas que distinguir:

  • El CSS no es una señal de posicionamiento directa. Sobre los nombres de clase CSS, Martin Splitt, de Google, ha dicho lo siguiente: “I don’t think we care because the CSS class names are just that.” (traducción) «No creo que nos importe, porque los nombres de clase CSS son solo eso». Esto se refiere específicamente a los nombres de clase, pero refuta el mito más amplio de que tus decisiones de CSS se interpretan como un factor de posicionamiento.
  • La velocidad es una señal (pequeña), a través de Core Web Vitals (Métricas web esenciales). El CSS crítico puede mejorar el primer pintado, lo que puede mejorar el LCP, que es una métrica de Core Web Vitals (Métricas web esenciales) que alimenta las señales de experiencia de página de Google. Esa es toda la conexión con el SEO: un pintado más rápido, no una bonificación por la técnica en sí.

Así que la justificación SEO del CSS crítico es exactamente tan sólida como su impacto en el LCP de tu sitio, el cual, según Google y la comunidad de rendimiento, frecuentemente es menor de lo que sugerirían las herramientas de los proveedores que lo venden.

¿Y qué hay de Bing?

Nada específico de Bing. A diferencia de Google —que tiene múltiples páginas en web.dev y un codelab sobre la técnica—, no pude encontrar ningún documento dedicado de Bing/Microsoft que aborde el CSS crítico. Se aplica la guía general de experiencia de página de Bing (mantén las cosas rápidas, mantén el contenido crítico accesible), pero no existe un equivalente en Bing del codelab de CSS crítico de web.dev. Cualquiera que te diga que Bing tiene una recomendación específica de CSS crítico se lo está inventando.

Dónde encaja esto

Esta página se ubica bajo el hub de Critical Rendering Path — el CSS crítico es una táctica para acortar esa ruta — y es la página hermana práctica de los recursos que bloquean el renderizado. El beneficio, cuando lo hay, se refleja en Largest Contentful Paint (LCP), First Contentful Paint (FCP), y el conjunto más amplio de Core Web Vitals (Métricas web esenciales). Para una visión más amplia del rendimiento, consulta el clúster de rendimiento web.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.