Si alguna vez te has peleado con PageSpeed Insights o Lighthouse, seguramente has visto recomendaciones del tipo «elimina recursos que bloquean el renderizado» o avisos sobre CSS que se descarga y procesa antes de pintar lo que el usuario ve. En WordPress esto es especialmente común: temas con hojas de estilo grandes, constructores que cargan CSS «por si acaso», WooCommerce metiendo estilos aunque no estés en una ficha de producto… y, como resultado, un primer renderizado que llega tarde.

Aquí es donde entra el critical CSS: una técnica muy simple de entender (aunque no siempre fácil de implementar bien), que consiste en extraer el CSS mínimo necesario para pintar el contenido «above the fold» y servirlo inline (incrustado directamente en el HTML) en el <head>. El resto del CSS se carga de forma diferida, evitando que bloquee el renderizado inicial.

La idea de este artículo no es que salgas con «una receta universal», porque cada stack (combinación de tecnologías) de WordPress es un mundo (tema, plugins, caché, CDN). La idea es que salgas con un proceso: detectar qué bloquea, generar el critical correcto, aplicarlo por contexto y mantenerlo sin que se convierta en una bomba de mantenimiento.

Si estás buscando mejorar Core Web Vitals con cambios que tienen impacto real, el critical CSS suele ser uno de los mejores retornos cuando tu web todavía carga demasiado CSS antes de pintar.

  1. Qué es el critical CSS (y qué no es)
  2. Por qué mejora el rendimiento: relación con LCP1, FCP2 y renderizado
  3. Cómo funciona el renderizado CSS en el navegador
  4. Estrategias posibles en WordPress: global vs por plantilla
  5. Cómo identificar el «above the fold» real en tu web
  6. Métodos para generar critical CSS
  7. Aplicarlo en WordPress: formas de integración (tema, plugin, caché, CDN)
  8. Critical CSS por plantilla: home, single, page, archive, product…
  9. Compatibilidades y problemas típicos (builder, bloques, WooCommerce, fuentes, CLS)
  10. Automatización y mantenimiento: cuándo regenerar y cómo evitar regresiones
  11. Cómo medir si lo has hecho bien (Lighthouse, PageSpeed, DevTools, waterfall)
  12. Errores comunes y antipatrones
  13. Conclusión y checklist final

Qué es el critical CSS (y qué no es)

Antes de meternos en herramientas, plugins o integraciones, necesitas tener clara una cosa: critical CSS no es «optimizar el CSS» en general, ni es «minificar», ni es «quitar CSS sin usar». Es una técnica concreta con un objetivo muy concreto.

Qué es el critical CSS

El critical CSS es el conjunto mínimo de reglas CSS necesarias para renderizar correctamente el contenido visible inicial (lo que el usuario ve nada más cargar la página, sin hacer scroll). A esa zona se le suele llamar above the fold.

Critical CSS en el Blog de WordPress.com en español
Contenido resaltado en verde marcando el Above the fold

La implementación típica es:

  1. Extraes ese CSS mínimo.
  2. Lo incrustas inline dentro del <head> (en un <style>).
  3. El CSS completo (global) se carga de forma no bloqueante (deferred/async, o con un patrón de precarga).

Resultado: el navegador puede pintar antes porque no necesita esperar a descargar y procesar una hoja de estilos enorme para mostrar el primer render.

La clave no es «tener menos CSS total», sino tener el CSS correcto disponible justo a tiempo.

Qué NO es

No es minificar CSS

Minificar solo reduce bytes (muy útil, sí), pero no cambia el comportamiento de bloqueo del renderizado. Una hoja minificada sigue siendo una hoja que el navegador tiene que descargar y procesar antes de pintar.

No es eliminar CSS no usado (aunque se relaciona)

Eliminar CSS no usado (unused CSS) ataca un problema diferente: sobrecarga y mantenimiento. Puede mejorar tiempos, pero no garantiza que el render inicial deje de estar bloqueado, sobre todo si sigues cargando una hoja grande en el <head>.

No es «meter todo el CSS inline»

Esto es un antipatrón clásico: si añades demasiado CSS inline, conviertes el HTML en un monstruo, empeoras el TTFB percibido, puedes afectar a cachés y… encima pierdes el beneficio porque el CSS inline también hay que parsearlo.

Critical CSS significa mínimo y específico.

No es una solución mágica universal

En WordPress, el comportamiento real depende de:

  • Cómo carga CSS tu tema (una hoja global vs. múltiples archivos).
  • Si usas builder (Elementor, Divi, WPBakery, etc.).
  • Si WooCommerce añade estilos por defecto.
  • Si tu plugin de caché/CDN reescribe recursos.

Critical CSS funciona muy bien, pero si lo aplicas mal, puedes provocar:

  • FOUC (flash of unstyled content): se ve «sin estilos» durante un instante.
  • Diseño roto al hacer scroll (faltan estilos no críticos).
  • CLS (saltos de layout) por fuentes, tamaños o elementos que no estaban en el critical.

Critical CSS y CSS diferido: van en pareja

Otro punto importante: critical CSS por sí solo no hace magia si no acompañas el resto con una carga no bloqueante.

El patrón habitual es:

  • Inline del critical en <style>.
  • Carga del CSS completo con un método no bloqueante (por ejemplo, precarga con rel="preload" + onload, o el clásico media="print" que luego cambia a all).

En WordPress, esto suele hacerlo un plugin de caché/WPO o una integración a medida (lo veremos más adelante). Lo importante es que entiendas el concepto: critical CSS es el «arranque» y el CSS completo es el «resto del viaje».

Por qué en WordPress tiene tanto sentido

WordPress tiende a mezclar muchas capas:

  • Estilos del tema.
  • Estilos del editor de bloques y bloques personalizados.
  • Estilos de plugins.
  • Estilos condicionales (a veces mal condicionados y se cargan siempre).

Eso hace que el CSS «necesario para ver el primer pantallazo» sea, en realidad, una fracción pequeña de todo lo que se termina cargando.

Y aquí está el punto: si consigues servir esa fracción mínima desde el inicio, puedes mejorar notablemente el tiempo hasta el primer render y, en muchos casos, el LCP.

Idea práctica para quedarte con el concepto

Piensa en tu web como en un teatro:

  • El critical CSS es la iluminación y el escenario que necesitas para abrir el telón.
  • El CSS completo es todo el atrezzo y decorado para el resto de la obra.

Si intentas montar todo antes de abrir, el público espera en la oscuridad.

Por qué mejora el rendimiento: relación con LCP1, FCP2 y renderizado

El critical CSS no es un «truco para sacar mejor nota» en PageSpeed. Funciona porque ataca un cuello de botella muy concreto del navegador: el CSS es un recurso que bloquea el renderizado.

Cuando el navegador empieza a procesar tu HTML, no puede pintar de forma fiable hasta construir (al menos en parte) el CSSOM3 (el «árbol» de estilos). Si el CSS necesario para el primer pantallazo está en un archivo externo grande, el navegador tiene que:

  1. Descargarlo.
  2. Parsearlo.
  3. Resolver prioridades y reglas.

Y todo eso ocurre antes del primer render útil.

Qué métricas suele mejorar (y por qué)

FCP (First Contentful Paint)

  • FCP mide cuándo aparece el primer contenido (texto, imagen, fondo) en pantalla.
  • Si el CSS bloquea, el navegador retrasa ese primer pintado.
  • Con critical CSS inline, tienes estilos disponibles desde el inicio y el navegador puede pintar antes.

LCP (Largest Contentful Paint)

  • LCP mide cuándo se renderiza el elemento «principal» de la vista (a menudo un H1, un bloque hero (la sección principal destacada de la página), una imagen destacada).
  • Si ese elemento depende de CSS para su layout (tamaños, display, fuentes, grid/flex), el CSS bloqueante puede retrasar el LCP.
  • Con critical CSS, reduces el tiempo que el navegador está «esperando estilos» para componer ese elemento.

TBT4 / INP5 (interacción)

  • No es el objetivo principal del critical CSS, pero si reduces trabajo temprano (menos CSS bloqueante y menos recalculado inicial), a veces mejoras la sensación de respuesta.
  • Ojo: si añades demasiado CSS inline, puedes conseguir lo contrario (más parsing en el hilo principal).

Por qué «elimina recursos que bloquean el renderizado» aparece tanto en WordPress

En WordPress es muy común que el CSS llegue de muchas fuentes y casi siempre acaba en el <head>:

  • style.css del tema.
  • CSS de plugins (formularios, sliders, popups, WooCommerce).
  • CSS del editor de bloques + estilos de bloques.
  • CSS del builder, si lo usas.

Y el navegador no negocia: si ese CSS se declara como stylesheet normal, lo trata como render-blocking.

El mecanismo real: menos tiempo «en blanco»

Sin critical CSS, el usuario suele ver una de estas situaciones:

  1. Pantalla en blanco (o un fondo sin contenido) mientras el CSS llega.
  2. Contenido que aparece tarde, porque el navegador espera estilos.

Con critical CSS inline, el navegador puede:

  • Pintar el layout base del primer pantallazo.
  • Mostrar tipografías, espaciados y estructura esencial.
  • Dejar para después el CSS no crítico (footer, secciones bajo el fold, componentes no visibles).

Por qué a veces lo aplicas y no mejora (o incluso empeora)

Esto es importante, porque pasa mucho.

1) Tu LCP no depende del CSS, sino de una imagen/servidor

Si el LCP es una imagen hero pesada, lo que manda es:

  • Tamaño y formato de la imagen.
  • Prioridad de carga (fetchpriority, preload, lazy-load mal aplicado).
  • TTFB6 y caché.

En ese caso, critical CSS puede mejorar FCP, pero el LCP seguirá «atascado» por la imagen.

2) Estás añadiendo demasiado CSS inline

Más CSS inline significa:

  • Más bytes dentro del HTML.
  • Más parseo y más trabajo temprano.
  • Peor eficiencia de caché (el HTML cambia aunque el CSS no).

El critical CSS tiene que ser mínimo. Si se convierte en una hoja «grande», pierdes el beneficio.

3) Falta CSS crítico y aparece FOUC7 o layout inestable

Si te dejas fuera reglas necesarias (por ejemplo, estilos del header, navegación, tipografías base, alturas, etc.), verás:

  • Flash sin estilos.
  • Saltos de layout (CLS) cuando llega el CSS completo.

4) El CSS diferido llega tarde o se bloquea por otras razones

No basta con «tener critical»; necesitas que el resto del CSS:

  • Se cargue de forma no bloqueante.
  • Pero llegue a tiempo antes de que el usuario empiece a interactuar o hacer scroll.

Si tu estrategia de defer es agresiva (o tu caché/CDN reescribe cosas), puedes crear una web que se ve bien arriba pero se rompe al bajar.

La idea práctica: lo que buscamos conseguir

Cuando el critical CSS está bien hecho, lo que deberías notar es:

  1. El primer pintado llega antes (FCP baja).
  2. El contenido principal aparece antes o más estable (LCP baja o mejora la estabilidad).
  3. Menos tiempo «en blanco» al cargar.
  4. El scroll hacia abajo no rompe estilos (el CSS completo llega a tiempo).

Cómo funciona el renderizado CSS en el navegador

Para aplicar critical CSS bien, no necesitas ser experto en motores de render. Pero sí necesitas entender por qué el CSS bloquea y qué está haciendo el navegador cuando tu página «parece que tarda en aparecer».

El navegador no «pinta HTML», pinta un árbol

Cuando un usuario abre una URL, el navegador no va pintando tu HTML línea por línea. Hace, más o menos, este flujo:

  1. Descarga el HTML.
  2. Lo parsea y construye el DOM8.
  3. Descarga y parsea CSS para construir el CSSOM.
  4. Combina DOM + CSSOM para crear el render tree (qué se pinta y cómo).
  5. Calcula geometría (layout): tamaños, posiciones, cajas.
  6. Dibuja (paint) y compone (compositing) en pantalla.

El punto clave es el paso 3: si falta CSS, el navegador no puede calcular el layout de forma fiable.

DOM de una página web
DOM de una página web

Por qué el CSS es render-blocking

Un <link rel="stylesheet" href="..."> en el <head> se considera bloqueante porque:

  • El navegador necesita ese CSS para saber cómo se ven los elementos.
  • Si pinta antes y luego llegan estilos, tendrías saltos y repaints masivos.

Por eso, en la práctica, el navegador tiende a esperar el CSS «crítico» antes de hacer el primer render significativo.

Resultado: si tu tema carga una hoja de 300KB en el head, el navegador se queda «parado» hasta que la procesa.

CSSOM + cascada: el coste no es solo descargar

En rendimiento solemos fijarnos en el peso del archivo, pero con CSS hay dos costes:

  • Red (network): descargar el recurso.
  • CPU (main thread): parsear reglas, resolver la cascada, recalcular estilos.

Por eso a veces ves una web con CSS «no tan grande» pero que sigue tardando: el CSS puede tener muchas reglas, selectores complejos o estar duplicado por plugins/builder.

La interacción con JavaScript (y por qué te afecta)

En teoría, CSS y JS son cosas distintas. En la práctica, se cruzan constantemente:

  • JavaScript suele depender de estilos (mediciones con getBoundingClientRect, alturas, etc.).
  • Si cambian estilos tarde, JS puede forzar recalculados.
  • Algunas librerías meten CSS dinámico o cambian clases en carga.

En WordPress, esto pasa mucho con:

  • Menús sticky.
  • Sliders.
  • Animaciones.
  • Builders que inyectan estilos por página.

Si tu CSS llega tarde, puedes provocar layout thrashing (recalcular layout varias veces) y aumentar el trabajo en el hilo principal.

Above the fold: el «critical» no es el mismo para todas las páginas

Aquí es donde WordPress se complica: tu site no es una única página, es un conjunto de plantillas.

  • En home sueles tener un hero, listados, bloques.
  • En single post, un header diferente, tipografía, contenido largo.
  • En archive, cards y grids.
  • En WooCommerce, elementos específicos (precio, variaciones, galería).

Eso implica que el CSS necesario para el primer pantallazo:

  • Cambia según la plantilla.
  • Incluso puede cambiar por tipo de contenido (un post con imagen hero vs sin imagen).

Por eso tiene sentido hablar de critical CSS por plantilla: no quieres un critical «genérico» gigante que cubra todos los casos, porque se convierte en una hoja completa inline.

Qué ocurre cuando añades critical CSS inline

Cuando pones critical CSS inline:

  • El navegador lo tiene disponible en el primer byte del HTML.
  • Puede construir CSSOM parcial antes, sin esperar a la red.
  • Calcula layout del primer pantallazo y pinta.

Y cuando el CSS completo llega más tarde (de forma no bloqueante), se completa el resto del estilo sin frenar el primer render.

La clave es el equilibrio:

  • Suficiente CSS para que el primer pantallazo se vea bien y estable.
  • No tanto como para que el HTML se vuelva pesado y lento de parsear.

Un ejemplo típico en WordPress: el «hero» que no se ve

Imagina una home con:

  • Header + menú.
  • Un bloque hero con fondo y H1.
  • Un botón CTA.

Si el CSS del hero está en la hoja global, el navegador puede tardar en mostrar:

  • La altura del hero (layout no calculado).
  • El tamaño de fuente del H1.
  • Espaciados y alineación.

Con critical CSS, metes lo mínimo para:

  • Tipografía base y tamaños del hero.
  • Layout del header.
  • Botones.

El hero aparece antes y, sobre todo, sin saltos.

La regla de oro

La idea principal que debemos recordar:

  • El navegador necesita CSS para calcular el layout.
  • El CSS externo en el head bloquea.
  • Critical CSS es «darle al navegador lo mínimo» para pintar el primer pantallazo sin esperar.

Estrategias posibles en WordPress: global vs por plantilla

En WordPress, aplicar critical CSS no es solo «generarlo y ya». La parte importante es cómo lo organizas para que sea útil, mantenible y no termine convirtiéndose en un CSS inline gigante que empeora el rendimiento.

En cuanto a la estrategia, tienes dos enfoques principales:

  1. Critical CSS global (uno para todo).
  2. Critical CSS por plantilla (varios, según contexto).

No hay una única respuesta correcta. Depende de tu web, tu tema y tu stack de caché.

Enfoque 1: critical CSS global

Consiste en generar un único bloque de critical CSS que «cubra» los casos principales del sitio y aplicarlo siempre.

Cuándo tiene sentido

  • Web pequeña o simple (pocas plantillas reales).
  • Tema muy «clásico», con estructura parecida en todas las páginas.
  • No usas builder o tu builder genera CSS bastante consistente.
  • Quieres algo rápido de implementar y con poco mantenimiento.

Ventajas

  • Implementación sencilla.
  • Menos puntos de fallo.
  • Regeneración más simple (un archivo/bloque).

Inconvenientes

  • Para cubrir todo, el critical tiende a crecer.
  • Acabas poniendo inline estilos que no se usan en muchas páginas.
  • Menos precisión: a veces mejoras FCP pero no optimizas tanto LCP.

En otras palabras: funciona, pero puede ser «caro» en bytes.

Enfoque 2: critical CSS por plantilla

Consiste en generar distintos critical CSS según el tipo de página:

  • Home
  • Single post
  • Page
  • Archive / categoría
  • Búsqueda
  • 404
  • WooCommerce (shop, product, cart, checkout)

Y aplicarlos de forma condicional.

Cuándo tiene sentido

  • Sitio mediano/grande con estructuras distintas.
  • Usas WooCommerce.
  • Tienes landings con diseño muy específico.
  • Tu tema/builder carga mucho CSS «genérico» que realmente no necesitas para el primer pantallazo.
  • Estás optimizando en serio Core Web Vitals (no solo «subir nota»).

Ventajas

  • Critical CSS más pequeño y más relevante en cada vista.
  • Mejor control sobre LCP (especialmente en home y fichas de producto).
  • Menos riesgo de «meter por meter» estilos innecesarios.

Inconvenientes

  • Más piezas: necesitas mapear plantillas y aplicar condiciones.
  • Más mantenimiento: cambios de diseño implican regenerar varios critical.
  • Riesgo de inconsistencias si no defines bien qué plantilla corresponde a qué.

Aun así, para la mayoría de los proyectos con tráfico real, por plantilla es el enfoque que mejor escala.

Estrategia híbrida

Si quieres equilibrio entre impacto y mantenimiento, lo más sensato suele ser un híbrido:

  • Un critical base (tipografía base, header, estructura general).
  • Critical específico por plantilla solo donde compensa (home, product, checkout, landings).

Así evitas que cada plantilla tenga que cargar «todo desde cero» y reduces el tamaño del critical específico.

Cómo decidir qué enfoque te conviene

Aquí tienes un criterio práctico para decidir sin complicarte:

  1. ¿Tienes plantillas muy distintas?
    • Sí → por plantilla o híbrido.
    • No → global puede bastar.
  2. ¿Usas WooCommerce?
    • Sí → por plantilla (mínimo product + cart + checkout).
  3. ¿Usas builder y cada landing es un mundo?
    • Sí → híbrido, y critical específico solo para las páginas que importan.
  4. ¿Tu problema principal es FCP «en blanco» por CSS bloqueante?
    • Global puede dar una mejora rápida.
  5. ¿Tu problema principal es LCP en home/product?
    • Por plantilla suele dar el mejor retorno.

Lo que casi nunca recomiendo

  • Un critical global enorme para «cubrirlo todo».
  • Generar critical por URL para cientos/miles de páginas sin una política clara (el mantenimiento y la caché se vuelven un infierno).

Si te encuentras con un plugin que te genera critical «por página» sin control, úsalo con cabeza: limita a tipos de plantilla o a un conjunto de URLs clave.

Objetivo final de la estrategia

El objetivo no es tener «critical CSS» por tenerlo. El objetivo es:

  • Pintar antes el primer pantallazo.
  • Mantener estabilidad visual (sin FOUC ni CLS).
  • No añadir complejidad innecesaria.

El hosting para los desarrolladores más exigentes

Hosting con funcionalidades avanzadas para un control y rendimiento total de tus proyectos.

Quiero saber más

Cómo identificar el «above the fold» real en tu web

El critical CSS solo funciona si defines bien qué es «crítico». Y aquí es donde la mayoría de implementaciones fallan: se genera un CSS que no corresponde a lo que el usuario ve realmente, o se asume un «fold» ideal que no existe en la vida real.

En WordPress esto es todavía más delicado porque:

  • El header puede cambiar por plantilla.
  • El hero puede variar según el contenido.
  • Hay banners de cookies, avisos, barras de administración, popups…
  • La tipografía cambia la altura de todo (y con ello el elemento LCP).

Vamos a ponerle método.

Qué significa «above the fold» de verdad

Above the fold no es una altura fija tipo «los primeros 800px». Es:

  • Lo que se ve sin scroll
  • En un dispositivo concreto
  • Con un viewport concreto
  • En una situación real (banner de cookies, barra del navegador móvil, etc.)

Por eso el critical CSS no puede ser perfecto para todos los dispositivos. Lo que buscas es cubrir los casos más comunes con el mínimo CSS posible.

El primer error: decidir el fold mirando tu monitor

Si defines el fold mirando tu home en un monitor de 27”, vas a generar un critical que:

  • En móvil se queda corto (faltan estilos que sí se ven).
  • En desktop puede meter estilos de más (incluyes cosas que en realidad están bajo el fold en portátiles).

La solución es trabajar con viewports representativos.

Viewports recomendados

No necesitas una lista infinita. Con 3–4 tamaños bien elegidos suele bastar:

  • Móvil: 360×640 (Android típico)
  • Móvil «grande»: 390×844 (iPhone moderno)
  • Tablet: 768×1024 (iPad vertical)
  • Desktop: 1366×768 (portátil muy común)

Si tienes Analytics, ajusta estos tamaños a tus datos. Si no, estos te dan una base realista.

Resolución de pantalla en Google Anlaytics
Resoluciones de pantalla en Google Anlaytics

Lo que sí suele ser crítico en la mayoría de páginas

Aunque el diseño cambie, hay piezas que casi siempre aparecen en el primer pantallazo:

  • Tipografía base (body, p, h1…h3).
  • Estructura del header y navegación.
  • Contenedor principal y grid/flex base.
  • Estilos del hero (título, subtítulo, botón) en home/landing.
  • Estilos del elemento LCP (a veces es imagen, a veces texto).

Y hay piezas que normalmente no son críticas:

  • Footer.
  • Widgets de sidebar que están abajo.
  • Secciones largas del contenido.
  • Animaciones complejas.
  • Estilos de componentes que no aparecen arriba (tabs, accordions que están abajo, etc.).

Identifica el elemento LCP antes de decidir el fold

Esto es un «truco» muy útil: si tu objetivo es mejorar las Core Web Vitals, el critical CSS tiene que cubrir el elemento que Lighthouse considera LCP en esa plantilla.

Cómo encontrarlo rápido:

  1. Abre Chrome DevTools.
  2. Ve a Performance.
  3. Graba una carga en modo incógnito (sin extensiones) y con cache desactivada.
  4. En el resumen verás el LCP y qué nodo lo provoca.

Si el LCP es un H1 o un bloque hero, tu critical debe incluir:

  • Tipografía y tamaños.
  • Espaciados.
  • Layout (grid/flex).

Si el LCP es una imagen, el critical CSS no la hace cargar antes, pero sí puede:

  • Evitar que el layout dependa de CSS tardío.
  • Reducir «esperas» antes del primer render.
LCP de imagen

Ojo con los «invasores» del fold en WordPress

Hay elementos que alteran el above the fold y cambian qué es crítico:

  • Banner de cookies (CMP).
  • Barra de admin de WordPress (usuarios logueados).
  • Avisos promocionales del tema o plugin.
  • Popups/slide-ins.
  • Sticky headers que ocupan más altura en móvil.

Recomendación práctica:

  • Genera y valida critical siempre como usuario no logueado.
  • En móvil, valida con el banner de cookies activo si es obligatorio en la primera visita.

Método rápido para decidir qué entra en el critical

Este es un proceso que suele dar buenos resultados en proyectos reales:

  1. Elige una URL representativa por plantilla
    • Home
    • Un single «típico»
    • Un archive con listados
    • Si hay WooCommerce: una ficha de producto, carrito y checkout
  2. Captura el primer pantallazo por viewport
    • No hace falta screenshot bonito: con una simple inspección visual vale.
  3. Marca qué bloques se ven sin scroll
    • Header
    • Hero
    • Primer bloque del contenido
  4. Asegura estilos base
    • Tipografías y tamaños principales
    • Layout del contenedor
    • Botones/enlaces del hero
  5. Valida scroll corto
    • Haz scroll 200–400px: si al bajar «se rompe», te falta CSS o tu defer llega tarde.

Este paso de «scroll corto» evita el típico caso de: «arriba se ve bien, pero en cuanto bajas se nota el parche».

Cómo saber si tu critical está mal definido

Señales claras:

  • Ves FOUC (contenido sin estilos) al cargar.
  • Hay saltos de layout (CLS) justo al aplicar el CSS completo.
  • El hero tarda en coger su tamaño o alineación.
  • El menú aparece descolocado durante un instante.

Si pasa algo de esto, no es «mala suerte»: es que tu critical no cubre lo necesario o el CSS diferido llega demasiado tarde.

Métodos para generar critical CSS

Llegamos a la parte práctica: cómo generar el critical CSS. Aquí hay muchas opciones, pero casi todas encajan en uno de estos enfoques:

  1. Generación automática (plugin/caché).
  2. Generación con herramienta externa (CLI [línea de comandos] o SaaS [software como servicio]) y despliegue manual.
  3. Generación «semi-manual» (tomar CSS del above the fold y depurarlo).

Lo importante no es «qué herramienta uses», sino que el resultado cumpla tres reglas:

  • Cubre el primer pantallazo (sin FOUC).
  • No es enorme (mínimo razonable).
  • Es mantenible (puedes regenerarlo cuando cambie el diseño).

Opción A: generación automática con plugin de caché/WPO

Es la vía más común en WordPress, porque resuelve el 80 % con poco trabajo.

Qué hace normalmente:

  • Renderiza la URL (a veces con un headless Chrome).
  • Extrae CSS usado en el viewport.
  • Guarda un bloque de critical (por plantilla o por URL, según el plugin).
  • Lo inserta en <head> y difiere el CSS completo.

Ventajas

  • Fácil de activar.
  • Integra defer/async del CSS completo.
  • Suele regenerarse cuando limpias caché.

Contras

  • Puede fallar con contenido dinámico (cookies, popups, A/B tests).
  • En builders o WooCommerce a veces genera un critical demasiado grande.
  • Si el plugin «no ve» el layout real (por ejemplo, sin cookies, sin personalización), puede quedarse corto.

Cuándo elegirlo

  • Sitios con plantillas relativamente estables.
  • Cuando quieres resultado rápido y no necesitas un control quirúrgico.

Opción B: herramienta externa (SaaS o CLI) y despliegue manual

Aquí generas el critical fuera de WordPress y luego lo aplicas tú (tema, mu-plugin, o integración con tu caché).

Suele haber dos formatos:

  • SaaS: le das una URL, eliges viewport y te devuelve el CSS.
  • CLI: lo integras en tu pipeline (CI/CD [integración y despliegue continuos]) y generas critical para un set de URLs/plantillas.

Ventajas

  • Más control sobre viewports y URLs.
  • Puedes versionar y automatizar la regeneración.
  • Ideal si trabajas con entornos (staging [preproducción]/producción) y despliegues controlados.

Contras

  • Tienes que implementar tú la inserción y el defer del CSS completo.
  • Mantener el mapping plantilla → critical.
  • Si el sitio cambia mucho, puedes estar regenerando a menudo.

Cuándo elegirlo

  • Proyectos donde ya tienes el pipeline (flujo de trabajo automatizado).
  • Si quieres critical por plantilla «real» y control de calidad.
  • Si el plugin de caché te da resultados inconsistentes.

Opción C: semi-manual (para afinar o para casos difíciles)

Esto no significa «escribir CSS a mano desde cero». Significa:

  1. Generas un primer critical (automático o con herramienta externa).
  2. Lo revisas, lo recortas y lo estabilizas.
  3. Aseguras que incluye lo crítico (header, hero, tipografías base) y nada más.

Ventajas

  • Es la forma de conseguir critical muy pequeño sin romper el layout.
  • Te permite arreglar casos raros (por ejemplo, estilos que dependen de clases que se aplican en runtime).

Contras

  • Requiere criterio y algo de tiempo.
  • Si cambias el diseño a menudo, tendrás que revisar de nuevo.

Cuándo elegirlo

  • Landings con diseño muy específico.
  • Builders que generan CSS por página.
  • Cuando necesitas exprimir LCP al máximo.

Cómo elegir el método según tu caso

Veamos una guía rápida:

  1. Sitio sencillo, sin WooCommerce ni builder complejo
    • Empieza por un plugin de caché/WPO.
  2. Sitio con WooCommerce
    • El plugin puede valer, pero asegúrate de critical por plantilla (product/cart/checkout).
    • Si el critical sale enorme, pasa a híbrido o a herramienta externa.
  3. Builders con landings diferentes
    • Híbrido: base + critical específico para páginas clave.
    • Considera herramienta externa o semi-manual para las URLs que importan.
  4. Proyecto con CI/CD y staging
    • Tool externa/CLI + despliegue versionado.

Un checklist para validar el critical generado

Da igual el método, valida el resultado:

  1. Recarga en incógnito (sin extensiones) y mira si hay FOUC.
  2. Scroll corto (200–400 px): no debe «romperse» el diseño.
  3. Revisa tamaño del CSS inline: si ocupa una barbaridad, estás añadiendo demasiado CSS inline.
  4. Comprueba duplicidades: critical + CSS completo repiten reglas, pero no deberían repetir «medio framework».
  5. Confirma el LCP: el elemento LCP debe tener el estilo correctamente desde el inicio.

Nota importante: critical CSS y fuentes

Muchos problemas atribuidos a critical CSS en realidad son de fuentes:

  • Si cambias de fuente al cargar (FOIT/FOUT), el layout cambia y aparece CLS.
  • El critical puede incluir font-family, pero si la fuente no está lista, el navegador usará fallback.

Solución habitual: combinar critical CSS con una buena estrategia de fuentes (preload de woff2, font-display, etc.).

Aplicarlo en WordPress: formas de integración (tema, plugin, caché, CDN)

Generar el critical CSS es la mitad del trabajo. La otra mitad (y donde se suele liar) es aplicarlo bien: inline del critical en <head> y carga del CSS completo de forma no bloqueante sin romper estilos.

En WordPress tienes cuatro vías típicas para integrarlo:

  1. Plugin de caché/WPO (la forma «fácil»).
  2. Código en tema/child theme (control total, más responsabilidad).
  3. MU-plugin (ideal para mantenerlo independiente del tema).
  4. CDN o edge (cuando tu stack lo permite).

Opción 1: plugin de caché/WPO

Es lo más habitual, porque muchos plugins ya hacen el pack completo:

  • Insertan critical CSS inline.
  • Difieren/precargan el CSS completo.
  • Regeneran al limpiar la caché.

Lo importante aquí es entender qué está haciendo el plugin, porque no todos aplican la misma estrategia.

Patrones de carga no bloqueante más comunes

A) preload + onload (muy común)

  • Pre-carga la hoja como recurso de alta prioridad.
  • Al terminar de cargar, la convierte en stylesheet.

B) media="print" y luego media="all" (clásico)

  • Evita el bloqueo inicial porque el navegador no lo considera aplicable.
  • Al cargar, se activa.

C) «Remove unused CSS» con inline parcial

  • Algunos plugins directamente generan CSS reducido por página/plantilla.
  • Ojo: no es exactamente lo mismo que critical + defer, aunque a veces se parece.

Riesgos típicos

  • Si el plugin difiere demasiado agresivo, al hacer scroll rápido faltan estilos.
  • Si tu tema o builder ya manipula CSS, puedes tener duplicidades o cargas dobles.
  • Si hay CSS inline adicional (por ejemplo, del builder), el beneficio puede ser menor.

Opción 2: integración en el tema hijo

Esta vía te da control total: tú decides qué critical se inyecta y cómo se carga el CSS completo.

Recomendación: si lo haces así, hazlo en un child theme o en un MU-plugin.

Qué tienes que conseguir

  1. Inyectar un <style> con el critical en el <head>.
  2. Convertir tus hojas de estilo principales en no bloqueantes.

Para el punto 1, lo típico es engancharte a wp_head.

Para el punto 2, puedes:

  • Reescribir los <link rel="stylesheet"> del tema.
  • O añadir un <link rel="preload"> y cambiar comportamiento.

Importante: en WordPress, tocar el encolado de estilos (wp_enqueue_style) sin romper dependencias requiere cuidado.

Opción 3: MU-plugin

Un MU-plugin (must-use plugin) se carga siempre y no depende del tema.

Ventajas:

  • No se desactiva por accidente.
  • No se pierde al cambiar de tema.
  • Puedes versionarlo y mantenerlo como parte de tu «stack» de rendimiento.

Si vas a aplicar critical CSS por plantilla, un MU-plugin suele ser el sitio más limpio para:

  • Mapear plantillas a critical.
  • Inyectar el bloque correcto.
  • Controlar la carga diferida.

Opción 4: CDN / edge (cuando tu arquitectura lo permite)

Si trabajas con un stack más avanzado (edge rules, workers, etc.), puedes:

  • Insertar critical CSS en el HTML en el borde.
  • Ajustar prioridades de carga de CSS/JS.

Esto es potente, pero tiene condiciones:

  • Necesitas control sobre el HTML a nivel CDN.
  • Tienes que evitar romper cachés y variaciones (cookies, idioma, usuario logueado).

En proyectos grandes puede ser una ventaja.

La parte crítica: diferir CSS sin romper nada

Vamos ahora a ver cómo deberemos llevarlo a la práctica.

1) No difieras todo indiscriminadamente

Hay estilos que conviene que sigan cargando de forma normal (dependiendo del sitio):

  • CSS de formularios si el formulario está arriba.
  • CSS del header si no está cubierto 100 % por el critical.
  • CSS mínimo de iconos (si no está en el CSS inline).

Diferir «a lo bruto» te da nota, pero te puede dar FOUC y tickets de «se ve raro».

2) Controla el orden de carga

En WordPress el orden importa:

  • Tema
  • Child theme
  • Plugins

Si difieres una hoja pero otra se queda normal, puedes cambiar prioridades y provocar estilos inesperados.

3) Evita duplicidades

Si tu plugin de caché ya está:

  • Insertando critical, y
  • Difieriendo CSS,

…no implementes lo mismo a mano en el tema. Lo más común es acabar con:

  • Dos critical distintos.
  • Dos estrategias de defer a la vez.
  • CSS aplicado tarde o dos veces.

Recomendación práctica según perfil de proyecto

  1. Freelance / sitios pequeños
    • Plugin de caché/WPO con critical automático.
  2. Sitios medianos con plantillas claras
    • Plugin + ajustes + validar por plantilla.
  3. WooCommerce o proyectos con rendimiento crítico
    • Híbrido o por plantilla.
    • MU-plugin para control + (si quieres) plugin de caché solo para cacheado.
  4. Entornos con CI/CD
    • Generación externa + MU-plugin que inyecta según plantilla.

Critical CSS por plantilla: home, single, page, archive, product…

Si tuviera que elegir un único punto donde el critical CSS deja de ser «una opción más» y pasa a ser una mejora real y sostenible, sería este: aplicarlo por plantilla.

Porque en WordPress rara vez tienes «una web», tienes varias:

  • La home suele tener un hero, listados, bloques de marketing.
  • Un single post tiene tipografía, contenido largo, TOC, sidebar.
  • Un archive es grid/cards.
  • WooCommerce es otro mundo (galería, variaciones, botones, precio, avisos, mini-carrito).

Intentar cubrirlo todo con un critical único suele acabar en lo mismo: un critical gigante.

La idea base: un mapa de plantillas (no de URLs)

El enfoque que mejor escala es este:

  1. Definir un conjunto de plantillas «tipo».
  2. Elegir una URL representativa para generar el critical de cada plantilla.
  3. Aplicar ese critical de forma condicional usando conditional tags de WordPress.

Así evitas generar critical por cada URL (caro y difícil de mantener) y, a la vez, consigues critical más pequeños que un «global».

Plantillas habituales

En la mayoría de proyectos, con estas ya cubres el 90 %:

  1. home/front page
  2. single post
  3. page (página estándar)
  4. archive (categoría, tag, CPT archive)
  5. search
  6. 404

Y si hay WooCommerce, mínimo:

  1. shop / product archive
  2. single product
  3. cart
  4. checkout

Si tu web tiene landings especiales, puedes añadir:

  • landing (por plantilla específica, por slug o por page template)

Qué debería incluir el critical en cada plantilla

Aquí es donde suele haber errores: se intenta «meter estilos del tema entero». No. Piensa en el primer pantallazo.

Home / front page

Suele ser la plantilla más sensible, porque el LCP suele estar aquí.

Incluye normalmente:

  • Header + navegación (incluido estado sticky si aplica arriba).
  • Layout base del contenedor principal.
  • Hero (título, subtítulo, CTA, fondo).
  • Tipografía base y botones.

Evita:

  • Secciones posteriores del home.
  • Carruseles complejos que aparecen abajo.
  • Estilos del footer.

Single post

Aquí mandan la legibilidad y la estabilidad.

Incluye normalmente:

  • Header.
  • Contenedor y ancho de lectura.
  • Tipografía del contenido (p, h1–h3, ul/ol, enlaces).
  • Imagen destacada si aparece arriba (y su ratio/altura para evitar CLS).

Evita:

  • Estilos de tablas/galerías si no aparecen arriba.
  • Componentes embebidos que están más abajo.

Page (página estándar)

Muchas páginas son parecidas a un single post, pero con bloques.

Incluye:

  • Header.
  • Contenedor.
  • Tipografía base.
  • Bloques que se usen casi siempre arriba (por ejemplo, un bloque «hero» reutilizable).

Si hay páginas «tipo landing», mejor tratarlas aparte.

Archive (categoría/tag/CPT)

Lo crítico suele ser el grid/listado.

Incluye:

  • Header.
  • Layout del listado (grid/flex).
  • Card base (imagen, título, meta).
  • Paginación si aparece arriba (a veces no).

Evita:

  • Estilos de widgets o filtros avanzados si no aparecen en la primera vista.

Search

Suele ser parecida a archive, pero con particularidades (mensaje «X resultados», buscador).

Incluye:

  • Header.
  • Campo de búsqueda si aparece arriba.
  • Listado de resultados (card base).

404

No es por rendimiento (no debería tener tráfico «bueno»), pero sí por coherencia.

Incluye:

  • Header.
  • Layout del mensaje.
  • Botones/enlaces de salida.

WooCommerce: shop / product archive

Muy parecido a archive, pero con precio, badges, botones, etc.

Incluye:

  • Header.
  • Grid de productos.
  • Elementos de card (imagen, título, precio, botón).

Evita:

  • Estilos de filtros laterales si están bajo el fold en móvil.

WooCommerce: single product

Aquí suele estar uno de los LCP más críticos.

Incluye:

  • Layout de la ficha (galería + resumen).
  • Tipografía/tamaños del título.
  • Precio.
  • Botón de añadir al carrito.
  • Variaciones si aparecen arriba.

Muy importante:

  • Reservar altura/ratio de la galería para evitar CLS.

WooCommerce: cart y checkout

Son páginas de conversión. No quieres FOUC aquí.

Incluye:

  • Layout del formulario.
  • Botones.
  • Resumen del pedido.
  • Mensajes/alerts.

Evita:

  • Estilos de elementos que solo aparecen tras interacción (por ejemplo, métodos de envío que se despliegan abajo), si puedes.

Cómo mapear plantillas en WordPress

La forma limpia es basarte en conditional tags.

Ejemplos típicos:

  • is_front_page() / is_home() para home
  • is_single() para single post (con matices si hay CPT)
  • is_page() para páginas
  • is_archive() / is_category() / is_tag() para archives
  • is_search()
  • is_404()

Y en WooCommerce (si está activo):

  • is_shop()
  • is_product_category() / is_product_tag()
  • is_product()
  • is_cart()
  • is_checkout()

La idea es que el código elija un «slug» de plantilla (por ejemplo: home, single, archive, product) y, con eso, cargue el critical correspondiente.

Estrategia recomendada: base + específico

Para evitar duplicar en todos los critical:

  • Define un critical base (tipografía base + header + contenedor).
  • Añade un critical específico por plantilla con lo que cambia (hero, grid, ficha de producto).

Esto te da:

  • Menos tamaño total.
  • Menos repetición.
  • Menos trabajo al mantener.

Validación mínima por plantilla

No validas critical CSS «en general». Lo validas por plantilla.

Checklist rápido:

  1. Carga en incógnito, sin caché.
  2. Revisa FOUC en header/hero.
  3. Identifica el LCP: ¿Aparece con estilos desde el inicio?
  4. Scroll 200–400 px: ¿Hay componentes sin estilos?
  5. Repite en móvil y desktop.

Hosting ultrarrápido, sin concesiones

Rendimiento imbatible, velocidad sin igual y estabilidad garantizada para que tu web nunca se detenga.

Supera tus límites

Compatibilidades y problemas típicos (builder, bloques, WooCommerce, fuentes, CLS)

En un mundo ideal, generas critical CSS, lo añades inline, difieres el resto y listo. En WordPress real, aparecen fricciones porque el frontend no lo controla solo el tema: lo controlan tema + plugins + builder + cookies + caché.

Aquí tienes los problemas más frecuentes y cómo resolverlos sin entrar en hacks peligrosos.

1) FOUC: «flash» de contenido sin estilos

Síntoma

  • Durante un instante ves el contenido «sin CSS» o con estilos por defecto.
  • Luego, cuando llega el CSS completo, se arregla.

Causas típicas

  • El critical no incluye estilos base suficientes (tipografía, contenedor, header).
  • El CSS diferido llega tarde (defer demasiado agresivo).
  • El tema depende de un CSS secundario que no se está cargando pronto.

Soluciones

  1. Asegura en el critical:
    • body (font-family, font-size, line-height, color, background).
    • Layout del header y contenedor principal.
    • Botones/enlaces básicos.
  2. Ajusta la estrategia de carga diferida:
    • Si usas media="print", verifica que el swap a all ocurra siempre.
    • Si usas preload, verifica que no haya bloqueos por CSP o por reescrituras del plugin.
  3. No difieras hojas imprescindibles:
    • Si hay una hoja «base» pequeña y crítica, puede quedarse como stylesheet normal.

2) CSS que «falta» al hacer scroll

Síntoma

  • Arriba se ve bien.
  • Bajas un poco y aparecen secciones sin estilo o descolocadas.

Causas típicas

  • Has diferido demasiado tarde el CSS completo.
  • Tu critical es demasiado «justo» y el usuario llega a contenido no cubierto antes de que llegue el CSS.
  • Bloques/elementos bajo el fold tienen CSS inyectado por JS o por builder (y tarda).

Soluciones

  • Prioriza la llegada del CSS completo (que sea no bloqueante, sí, pero no «tardío»).
  • Valida con «scroll corto» (200–400 px) en móvil y desktop.
  • Si una sección está siempre cerca del fold en móvil, inclúyela en el critical de esa plantilla.

3) CLS (saltos de layout) tras cargar el CSS completo

Síntoma

  • La página «se recoloca» cuando llega el CSS completo.

Causas típicas

  • Falta en el critical algún estilo que define alturas/ancho/espaciados de elementos visibles.
  • Imágenes o banners sin dimensiones reservadas.
  • Tipografías que cambian métricas al cargarse.

Soluciones

  1. Reserva espacio:
    • Define width/height (o aspect-ratio) para imágenes visibles.
    • Asegura alturas mínimas de header/hero.
  2. Fonts:
    • Usa font-display: swap (o una estrategia equivalente).
    • Preload de WOFF2 para la fuente crítica si es realmente necesaria.
    • Si la fuente cambia mucho el layout, considera ajustar fallbacks.
  3. Incluye en critical reglas que afectan al layout del primer pantallazo:
    • display, position, grid/flex, gap, padding, margin, min-height, aspect-ratio.

4) Builders (Elementor, WPBakery, Divi, etc.)

Los builders suelen tener dos patrones:

  • CSS «global» del builder.
  • CSS generado por la página (a veces inline o en archivos separados).

Problemas típicos

  • Critical CSS enorme si intentas cubrir «todo el builder».
  • CSS por página que se carga tarde y rompe secciones específicas.

Soluciones

  • Enfoque híbrido:
    • Critical base (layout + tipografía + header).
    • Critical específico por plantilla/landing solo para URLs clave.
  • Si el builder genera CSS por página, evita generar critical «por plantilla genérica» para esas landings: usa URLs representativas o agrupaciones.
  • Valida siempre con páginas reales del builder, no con una URL «vacía».

5) Gutenberg y bloques (core + personalizados)

Con bloques, el CSS puede venir de:

  • Estilos del tema.
  • theme.json.
  • wp-block-library.
  • CSS de bloques de plugins.

Problemas típicos

  • El critical no incluye estilos base del editor/bloques y el contenido aparece «sin forma».
  • Cambios en theme.json alteran mucho el above the fold y dejan obsoleto el critical.

Soluciones

  • Asegura en el critical estilos base del contenido:
    • Tipografías, anchuras de contenedor, alineaciones.
    • Estilos básicos de bloques que sueles usar arriba (cover, buttons, columns).
  • Si tu stack cambia mucho por theme.json, define un proceso de regeneración cuando cambies estilos globales.

6) WooCommerce y sus estilos «siempre cargados»

WooCommerce mete CSS y componentes que pueden afectar al above the fold en plantillas clave.

Problemas típicos

  • Ficha de producto: galería y variaciones dependen de CSS que llega tarde.
  • Mini-cart, notices, badges: aparecen sin estilo.

Soluciones

  • Critical específico para:
    • is_product().
    • is_cart().
    • is_checkout().
  • En product, incluye en critical:
    • Layout galería/summary.
    • Botón add-to-cart.
    • Variaciones si están visibles.
  • Reserva tamaño de imagen/galería para evitar CLS.

7) Cookies, personalización y contenido dinámico

Problema

  • Tu herramienta genera critical en un estado (sin cookies/banner), pero el usuario ve otro (con banner).

Soluciones

  • Genera/valida critical en condiciones reales:
    • Primera visita (banner de cookies visible).
    • Usuario no logueado.
  • Si el banner de cookies afecta mucho al layout, considera:
    • Estilos mínimos del banner en el critical.
    • O un banner que reserve espacio desde el inicio.

8) Caché, minificación y «reescrituras» que interfieren

A veces el critical CSS está bien, pero la integración se rompe por cómo el plugin de caché reescribe HTML/CSS.

Señales

  • El CSS se carga dos veces.
  • El <link rel="preload"> desaparece.
  • Se reordena el head y cambia la prioridad.

Soluciones

  • Evita solapar optimizaciones:
    • Si el plugin gestiona critical + defer, no lo reimplementes a mano.
    • Si lo haces a mano, desactiva en el plugin lo que choque.
  • Revisa el HTML final (no el que «crees» que sirve WordPress).

Conclusión práctica: el critical CSS no es solo «generar un bloque». Es integrarlo sin efectos secundarios. Si ves FOUC o CLS, casi siempre es porque:

  1. Falta CSS que afecta al layout del primer pantallazo, o
  2. El CSS diferido llega demasiado tarde, o
  3. Las fuentes/medidas no están controladas.

Automatización y mantenimiento: cuándo regenerar y cómo evitar regresiones

El critical CSS es una optimización con «cara B»: si tu web cambia y no lo regeneras, se queda desactualizado. Y cuando se queda desactualizado, no solo pierde eficacia: puede introducir FOUC, CLS o estilos inconsistentes.

La buena noticia es que se puede mantener sin drama si lo planteas como un sistema.

Cuándo tienes que regenerar el critical CSS

Piensa en el critical como en una «foto» del above the fold. Si cambia la escena, la foto ya no sirve.

Regenera cuando ocurra cualquiera de estas cosas:

  1. Cambios en el header o navegación
    • Nuevo menú, sticky distinto, cambios de altura.
  2. Cambios en el hero o en la cabecera de plantillas
    • Home, landings, fichas de producto.
  3. Cambios globales de estilos
    • Modificaciones en theme.json.
    • Cambio de tipografías, tamaños base, spacing.
    • Cambio de tema o child theme.
  4. Actualizaciones que afectan al frontend
    • Actualización mayor del builder.
    • Actualización de WooCommerce.
    • Plugins que inyectan estilos en zonas altas (cookies, banners, popups).
  5. Cambios de estructura del contenido visible
    • Añades un bloque nuevo arriba del fold (banner, aviso legal, promo).

Regla práctica: si un cambio afecta a lo que se ve «sin scroll» en una plantilla, regenera el critical de esa plantilla.

Define una política: por plantilla, no por URL

Si estás aplicando critical por plantilla, el mantenimiento se vuelve manejable porque:

  • No regeneras «mil páginas».
  • Regeneras un conjunto pequeño: home, single, archive, product, cart, checkout…

Y si tienes landings especiales:

  • O las metes en un grupo (plantilla «landing»),
  • O aceptas que solo las críticas (las que convierten) tienen critical dedicado.

Automatización «ligera» en WordPress (sin CI/CD)

Si tu enfoque es plugin de caché/WPO, la automatización suele venir incluida:

  • Regeneración al limpiar caché.
  • Regeneración programada.
  • Regeneración al detectar cambios.

Pero incluso así, necesitas poner límites:

  • No regeneres por cada visita (te fundes la CPU).
  • No regeneres por cada URL si tienes miles.

Lo que suele funcionar mejor:

  1. Regeneración por plantilla.
  2. Regeneración bajo demanda (cuando hay cambios reales).
  3. Programación en horas valle.

Automatización «seria» con pipeline

Si trabajas con staging + despliegues, el enfoque ideal es:

  1. Generar critical en staging (con URLs representativas).
  2. Versionar los archivos de critical.
  3. Desplegarlos junto con el código.

Ventajas:

  • Puedes revisar diffs.
  • Puedes hacer rollback.
  • No dependes de procesos «mágicos» en producción.

Evitar regresiones: lo que realmente importa comprobar

La mayoría de equipos valida solo «que subió la nota». Eso no es suficiente. Lo que te interesa es:

  1. No hay FOUC
  2. No hay CLS nuevo
  3. El LCP está bien estilado desde el inicio
  4. El CSS completo sigue llegando a tiempo

Checklist rápido tras una regeneración:

  1. Carga en incógnito (usuario no logueado).
  2. Móvil + desktop.
  3. Scroll corto.
  4. Performance (LCP node) en DevTools.

Si puedes añadir un control extra, mejor:

  • Un test manual rápido en home + product + checkout (si existe WooCommerce).

Control de tamaño: la regla para no acabar con un critical monstruoso

Un critical CSS que crece sin control suele venir de:

  • Intentar cubrir demasiadas plantillas con un solo bloque.
  • Generar critical con demasiados viewports y unirlo todo.
  • Incluir CSS de componentes que no están realmente en el fold.

Buenas prácticas:

  1. Limita viewports a 3–4 representativos.
  2. Usa base + específico.
  3. Si un critical supera cierto umbral (define uno para tu proyecto), revísalo y recórtalo.

No te doy un número fijo, ya sabes que siempre «depende» de tu HTML, caché y tráfico. Pero sí te digo esto: si el critical empieza a parecer «una hoja de estilos completa», algo va mal.

Gestión de caché: que no se quede viejo

Problema típico:

  • Regeneras el critical.
  • El usuario sigue viendo el viejo por caché (HTML cacheado, CDN, etc.).

Solución práctica:

  • Asegúrate de que el critical forma parte del HTML cacheado y que al purgar:
    • se invalida la caché de la página,
    • se invalida el CDN,
    • y se regenera el critical si aplica.

En stacks con CDN, lo más común es que «purges WordPress» pero el HTML siga en el edge.

Mantenibilidad en WordPress: una recomendación clara

Si vas a trabajar critical CSS por plantilla de forma sostenida:

  • Centraliza la lógica (mejor MU-plugin que tema).
  • Define un mapping plantilla → critical.
  • Documenta cuándo regenerar (una checklist en tu repo o en tu documentación interna).

Así evitas depender del «recuerdo» de alguien cada vez que se toca el header.

Cómo medir si lo has hecho bien (Lighthouse, PageSpeed, DevTools, waterfall)

Si aplicas critical CSS y solo miras la «nota», te vas a engañar. La medición buena es la que te dice:

  • si pinta antes,
  • si pinta estable,
  • y si la mejora viene de critical CSS y no de otra optimización colateral (caché, minificación, etc.).

Aquí tienes un proceso de validación para usar en proyectos reales.

1) Antes de medir: controla el entorno

Si no controlas el entorno, tus mediciones serán ruido.

Checklist previo:

  1. Modo incógnito (o perfil limpio sin extensiones).
  2. Usuario no logueado (sin barra de admin).
  3. Desactiva la cache del navegador en DevTools (solo para pruebas).
  4. Haz varias ejecuciones y quédate con las tendencias, no con un único número.
  5. Mide en URLs representativas por plantilla (home, single, archive, product…).

Y muy importante:

  • Si tienes CDN/cache, haz dos escenarios:
    • Cold (primera visita, cachés frías si puedes simularlo).
    • Warm (cachés calientes, que es lo que ve la mayoría de usuarios).

2) Lighthouse (en DevTools): dónde mirar de verdad

Lighthouse es útil porque te da contexto y te señala síntomas típicos (render-blocking, unused CSS), pero lo que te interesa es:

  • FCP
  • LCP
  • CLS
  • El elemento LCP (qué nodo es)

Cómo comprobar si el critical CSS está ayudando

  1. Ejecuta Lighthouse antes/después.
  2. Observa:
    • Baja el FCP → suele indicar que el primer render llega antes.
    • Baja el LCP → si tu LCP dependía de los estilos, debería mejorar.
    • El CLS no debe empeorar.

Si el LCP no cambia pero el FCP sí mejora, puede ser normal: quizá tu LCP depende de una imagen o del servidor.

3) PageSpeed Insights: útil para campo y «tendencia»

PageSpeed te mezcla dos cosas:

  • Datos de laboratorio (simulación).
  • Datos de campo (CrUX) si tu URL tiene suficiente tráfico.

Cómo usarlo sin liarte:

  • Lab: úsalo para ver si tu cambio reduce el render-blocking y mejora el FCP/LCP en condiciones controladas.
  • Campo: úsalo para validar si, con el tiempo, mejora la experiencia real.

Ojo con esto:

  • El campo no cambia «al instante». Necesita acumular datos.
  • Si solo tienes lab, no pasa nada: mide con DevTools y con WebPageTest (si lo usas).

4) Chrome DevTools Performance: la prueba buena

Si quieres ver claramente el efecto del critical CSS, Performance es tu herramienta.

Proceso:

  1. Abre DevTools → Performance.
  2. Activa «Disable cache» en Network.
  3. Graba una recarga (Ctrl/Cmd + R).
  4. Busca los marcadores:
    • FCP
    • LCP
    • (y si aparece) Layout Shifts

Qué deberías ver cuando el critical está bien:

  • El primer pintado ocurre antes.
  • El LCP se renderiza sin esperar a una hoja CSS enorme.
  • Menos «recalculate style / layout» temprano.
Panel Performance de Chrome DevTools mostrando métricas de rendimiento
Performance en la herramientas de desarrollo del navegador

Y lo más importante: al seleccionar LCP, DevTools te muestra el nodo. Pregunta práctica:

  • ¿Ese nodo tenía estilos aplicados desde el inicio?
  • ¿O ves que se remaqueta cuando llega el CSS completo?

5) Network waterfall: confirma que el CSS ya no bloquea

Ve a DevTools → Network y mira:

  • ¿Tus CSS principales siguen cargando como render-blocking?
  • ¿Ves preload?
  • ¿Ves cambios raros de prioridad?

Dos comprobaciones simples:

  1. Inicio de descarga: el CSS completo debería empezar pronto (aunque no bloquee).
  2. Momento de aplicación: no debería aplicarse «demasiado tarde» (sino, al hacer scroll falta el CSS).

Si al hacer scroll ves estilos que faltan, normalmente el CSS diferido está llegando tarde o está bloqueado por algo.

6) Coverage (cobertura de CSS): úsalo para entender, no como KPI

DevTools → Coverage te dice qué CSS se usa durante la carga.

Esto te sirve para:

  • Detectar si tu hoja global está sobredimensionada.
  • Entender si tu critical está siendo redundante (poniendo inline reglas que realmente no se usan).

Pero no lo conviertas en el objetivo absoluto: una web puede tener «mucho CSS no usado» y aun así cargar rápido si el above the fold está bien resuelto.

CSS no usado
CSS no usado

7) Qué comparar exactamente (para atribuir la mejora)

Si cambias 10 cosas a la vez, no sabes qué mejoró.

Cuando estés afinando el critical CSS, intenta comparar:

  • Misma URL.
  • Mismo dispositivo/viewport.
  • Mismo estado (cookies/banner).
  • Mismo stack (no cambies a la vez imágenes, JS, caché).

Si tu plugin de caché activa otras optimizaciones al activar el critical, apunta qué ha cambiado:

  • ¿también minificó?
  • ¿también retrasó JS?
  • ¿también combinó CSS?

Así podrás atribuir las mejoras con más seguridad.

Checklist de «ok, está bien hecho»

Si quieres una validación práctica:

  1. FCP mejora o, como mínimo, no empeora.
  2. LCP mejora en plantillas clave (home/product) o se mantiene.
  3. CLS no empeora.
  4. No hay FOUC visible.
  5. El CSS completo llega a tiempo (scroll corto sin roturas).

Errores comunes y antipatrones

El critical CSS funciona muy bien… hasta que se aplica «a lo bruto». Esta sección es para evitar los fallos típicos que veo con frecuencia en WordPress, especialmente cuando se activa una opción del plugin sin entender qué está haciendo.

1) Añadir demasiado inline: el «critical CSS» que es medio tema

Qué pasa

  • Añades CSS inline en un bloque enorme en el <head>.
  • El HTML pesa más.
  • El navegador tiene más trabajo de parseo temprano.
  • Pierdes caché eficiente (cada HTML incluye el CSS).

Señales

  • El <style> del critical parece una hoja completa.
  • El tiempo de «Parse HTML / Recalculate Style» sube.

Cómo evitarlo

  • Enfoque base + específico por plantilla.
  • Recorta componentes que no están en el fold.
  • No intentes cubrir «todas las páginas» con un critical único.

2) Confundir «remove unused CSS» con critical CSS

Qué pasa

  • Activas «eliminar CSS no usado» pensando que ya tienes critical.
  • En algunos plugins, se combinan técnicas; en otros, no.

Riesgo

  • El CSS resultante puede ser correcto para una carga, pero romper estados:
    • hover, focus, menús desplegables, modales, etc.

Cómo evitarlo

  • Trata «unused CSS» como una optimización aparte.
  • Si lo usas, valida los estados interactivos (menú, formularios, variaciones WooCommerce).

3) Defer agresivo del CSS completo: «arriba bien, abajo roto»

Qué pasa

  • Diferir el CSS completo con una técnica que retrasa demasiado su aplicación.

Síntoma

  • Scroll corto y empiezan estilos faltantes.

Cómo evitarlo

  • Asegura que el CSS completo empieza a descargar pronto.
  • No difieras las hojas pequeñas que son necesarias «ya».
  • Evita retrasar el CSS por interacciones (ej. «cargar CSS solo al scroll»), salvo casos muy controlados.

4) Duplicar optimizaciones: plugin + tema + CDN haciendo lo mismo

Qué pasa

  • El plugin inyecta critical.
  • El tema/child theme también.
  • La CDN reescribe preload.

Resultado

  • CSS duplicado.
  • Prioridades raras.
  • FOUC o estilos inconsistentes.

Cómo evitarlo

  • Una única «fuente de verdad» para critical y defer.
  • Si lo haces a mano, desactiva la función equivalente en el plugin.

5) Generar critical en un estado irreal (sin cookies, sin banners, sin variaciones)

Qué pasa

  • La herramienta genera critical en una vista «limpia».
  • El usuario real ve:
    • banner de cookies,
    • popups,
    • avisos,
    • barra sticky,
    • traducciones,
    • personalización.

Resultado

  • Te falta CSS crítico.
  • Aparecen saltos (CLS) o flashes.

Cómo evitarlo

  • Valida en condiciones reales (primera visita).
  • Si el banner es fijo, incluye su estilo mínimo en critical o reserva espacio.

6) No reservar espacio para imágenes/hero

Qué pasa

  • La imagen hero o la galería de producto cambia el layout al cargar.

Resultado

  • CLS, aunque el critical sea «correcto».

Cómo evitarlo

  • Define tamaños o aspect-ratio.
  • Asegura alturas mínimas en contenedores visibles.

7) Ignorar las fuentes: el critical «está bien» pero el layout baila

Qué pasa

  • El critical aplica font-family, pero la fuente tarda.
  • El fallback tiene métricas distintas.

Resultado

  • CLS o cambio visible de estilo.

Cómo evitarlo

  • Preload de WOFF2 crítico (solo si es realmente crítico).
  • font-display bien elegido.
  • Ajusta fallbacks para reducir cambios de métricas.

8) Critical por URL sin límites: escalado imposible

Qué pasa

  • Generas critical «por página» en un site grande.

Resultado

  • Miles de critical.
  • Regeneración eterna.
  • Caché inconsistente.

Cómo evitarlo

  • Mapear por plantilla.
  • Excepciones solo para URLs clave (landings, páginas de conversión).

9) Meter critical en el lugar equivocado

Qué pasa

  • El critical se inserta tarde en el head.
  • O se mete después de los scripts que bloquean.

Resultado

  • El navegador sigue sin tener estilos pronto.

Cómo evitarlo

  • Asegura que el <style> crítico está lo más arriba posible en el <head>.
  • Evita JS bloqueante antes del critical.

10) No validar estados interactivos

Muchos «rotos» aparecen solo al interactuar:

  • Menú desplegable.
  • Modal.
  • Sticky header al scroll.
  • Variaciones WooCommerce.
  • Formularios con validación.

Cómo evitarlo

  • Valida los estados clave en plantillas críticas.
  • Si usas «remove unused CSS», esto es obligatorio.

Resumen práctico: los antipatrones más peligrosos son dos:

  1. Critical enorme (pierdes rendimiento y caché).
  2. Defer agresivo (arriba bien, abajo roto).

Si evitas esos dos y validas FOUC/CLS por plantilla, el 90 % de implementaciones salen bien.

Automattic para Agencias: haz crecer tu agencia con ventajas únicas

Accede a descuentos exclusivos, herramientas avanzadas, soporte prioritario y beneficios por afiliación.

¡Me apunto!

Conclusión y checklist final

El critical CSS no es una casilla más de «optimización WPO». Bien aplicado, es una de las técnicas con mejor retorno, porque ataca un problema estructural: el CSS en el <head> bloquea el renderizado.

En WordPress, donde el CSS suele venir de varias capas (tema, bloques, plugins, WooCommerce, builders), el enfoque que mejor funciona a largo plazo no es el «critical universal», sino un sistema:

  • identificar qué se ve arriba,
  • generar el CSS mínimo para ese primer pantallazo,
  • aplicarlo por plantilla,
  • y mantenerlo con un proceso claro de regeneración.

Si te llevas una sola idea, que sea esta: critical CSS no es meter CSS inline, es meter solo lo imprescindible para pintar y estabilizar el above the fold.

Checklist final

1) Estrategia

  1. Define el enfoque:
    • Global (web simple)
    • Por plantilla (web realista)
    • Híbrido base + específico (mi opción favorita)
  2. Elige las plantillas objetivo:
    • Home
    • Single
    • Archive
    • (Woo) Product + Cart + Checkout

2) Above the fold y LCP

  1. Define viewports representativos (móvil + desktop mínimo).
  2. Identifica el elemento LCP por plantilla (DevTools Performance).
  3. Asegura qué bloques se ven sin scroll (incluyendo banner de cookies si aplica).

3) Generación

  1. Genera critical por plantilla usando tu método (plugin/herramienta/semimanual).
  2. Revisa el resultado:
    • ¿incluye tipografía base, header y layout del primer pantallazo?
    • ¿parece razonable o es un CSS enorme?

4) Implementación

  1. Inserta el critical muy arriba en el <head> (sin duplicidades).
  2. Carga el CSS completo de forma no bloqueante, pero pronto.
  3. Evita solapamientos: una sola herramienta/lógica debe gestionar critical + defer.

5) Validación

  1. Validación visual:
  • sin FOUC
  • sin CLS nuevo
  • scroll corto sin «zonas sin estilo»
  1. Validación técnica:
  • FCP y/o LCP mejoran o se mantienen
  • Network waterfall coherente (CSS completo descarga pronto)
  • Performance muestra menos bloqueo por CSS

6) Mantenimiento

  1. Define cuándo regenerar:
  • cambios de header/hero
  • cambios en theme.json
  • updates grandes de builder/WooCommerce
  1. Centraliza la lógica (idealmente MU-plugin) si vas por plantilla.
  2. Documenta:
  • plantillas cubiertas
  • URLs modelo
  • método de regeneración

Si tu web todavía carga una hoja de estilos grande y bloqueante en el head, el critical CSS suele ser el paso que marca la diferencia entre: «he optimizado un poco» y «la web pinta rápido y estable».

A partir de aquí, lo siguiente lógico es combinarlo con una buena estrategia de fuentes, optimización de imágenes del hero (si es tu LCP) y control del JS que bloquea.

Con eso, el impacto en Core Web Vitals es mucho más consistente y sostenible.

  1. LCP: Largest Contentful Paint ↩︎
  2. FCP: First Contentful Paint ↩︎
  3. CSSOM: CSS Object Model ↩︎
  4. TBT: Total Blocking Time. ↩︎
  5. INP: Interaction to Next Paint ↩︎
  6. TTFB: Time To First Byte ↩︎
  7. FOUC: Flash Of Unstyled Content ↩︎
  8. DOM: Document Object Model ↩︎