Entras en la web de un competidor y ves el menú y el titular al instante, pero en la tuya el visitante mira tres segundos una pantalla en blanco antes de que aparezca el header. A menudo no es el servidor: es el CSS bloqueante que retrasa el primer render. El Critical CSS (CSS crítico) es el conjunto mínimo de estilos necesarios para pintar lo que el usuario ve sin hacer scroll — el «above the fold».
Este artículo explica qué es el CSS crítico, cómo encaja con FCP, LCP y Speed Index, cómo extraerlo sin romper el diseño y qué errores evitar en webs de empresa en 2026.
Qué es el Critical CSS y por qué importa en una web corporativa
El navegador no pinta contenido hasta que descarga y analiza el CSS que bloquea el renderizado. Si tu hoja de estilos principal pesa 400 KB y el visitante solo necesita 8 KB para ver el hero y la barra de navegación, estás retrasando la primera impresión sin necesidad.
- CSS crítico: reglas que afectan solo al viewport inicial (header, hero, tipografía base, grid principal).
- CSS no crítico: estilos de pie de página, modales, páginas internas, animaciones below-the-fold.
- Objetivo: inline o servir el crítico en la primera respuesta HTML y cargar el resto de forma asíncrona.
- Beneficio medible: mejora FCP y suele bajar el Speed Index porque el filmstrip se rellena antes.
La guía de web.dev sobre extracción de CSS crítico describe el enfoque recomendado por el equipo de Chrome.
Cómo se relaciona con otras métricas de rendimiento
El CSS crítico no sustituye a optimizar imágenes o reducir JavaScript, pero desbloquea el camino al primer pintado. Un TTFB alto sigue siendo un cuello de botella; sin embargo, con HTML rápido, el siguiente freno habitual es el CSS bloqueante.
Si el LCP es un bloque de texto estilizado, el crítico debe incluir esas clases. Si el LCP es una imagen hero, prioriza dimensiones y fetchpriority, pero no olvides los estilos del contenedor que evitan saltos de layout (CLS).
Cómo extraer el CSS crítico (enfoque práctico)
Herramientas y automatización
- Critical (npm): genera CSS crítico a partir de URL y plantillas.
- Penthouse / critical-css: útiles en pipelines de build (Vite, Webpack).
- Lighthouse: señala CSS no usado; complementa, no sustituye, la extracción manual.
- Chrome DevTools → Coverage: graba la carga y muestra qué reglas no se aplican above-the-fold.
Extracción manual controlada
Para landings con poco cambio, a veces es más fiable copiar a un <style> en el <head> las reglas del header, tipografía, contenedor y hero. Documenta qué plantillas usan ese bloque para no duplicar mantenimiento sin criterio.
Cargar el CSS no crítico sin bloquear
Patrón clásico: <link rel="preload" href="app.css" as="style" onload="this.rel='stylesheet'"> más un <noscript> de respaldo. Alternativa: dividir bundles por ruta (home vs. blog) para que cada página descargue menos bloqueante.
Qué mejoras esperar (referencias 2026)
No hay un «número mágico» de kilobytes para el crítico: depende del diseño. Como orientación en webs de empresa:
- Crítico inline: apunta a < 14 KB comprimido en la home (menos es mejor si el diseño lo permite).
- CSS bloqueante total: reducir de forma visible en Lighthouse «Render-blocking resources».
- FCP / Speed Index: mejoras de 0,3–1,2 s en móvil simulado son habituales tras un buen crítico + fuentes optimizadas.
Mide siempre la misma URL antes y después del despliegue; el tráfico real en Core Web Vitals confirma si el cambio vale en producción.
Por qué muchas webs de empresa lo posponen
- Un único
app.cssde 500 KB generado por el tema de WordPress o el framework. - Frameworks que hidratan tarde y ocultan contenido hasta cargar todo el CSS.
- @import en cadena y fuentes externas sin
font-display: swap. - Miedo a que el inline «ensucie» el HTML o complique el cacheo (soluble con build automatizado).
- Equipos de marketing que publican landings sin pasar por el pipeline de front.
Acciones que suelen funcionar
Priorizar plantillas con tráfico
Home, servicios, contacto y landings de campaña primero. El blog puede usar un crítico más ligero si el diseño es más simple.
Eliminar CSS no usado
PurgeCSS o equivalente en el build, más auditoría periódica. Combina con minificación — quitar reglas muertas impacta más que comprimir un archivo enorme.
Fuentes y texto visible
Subconjuntos, precarga solo de la variante del hero y font-display: swap. El texto legible forma parte del crítico percibido.
Imágenes y crítico
Define width/height en el hero y estilos del contenedor en el bloque crítico. Usa WebP o AVIF y lazy loading para lo que queda bajo el pliegue.
Red y caché
Sirve HTML y crítico con compresión Brotli o Gzip y cabeceras de caché coherentes. Un CDN acerca el CSS no crítico, pero el inline ya viaja con el HTML.
Errores frecuentes al implementar Critical CSS
- Inline de 80 KB «por si acaso» que hincha el HTML y empeora el TTFB percibido.
- Crítico desactualizado tras un cambio de diseño: menú roto o colores incorrectos en la primera pintura (FOUC).
- Dos versiones del mismo componente (inline + bundle) con reglas contradictorias.
- Olvidar estados responsive: el crítico de desktop no sirve en móvil.
- Confundir crítico con «quitar todo el CSS» y perder accesibilidad o contraste.
Checklist antes del próximo despliegue
- Lighthouse móvil en home: anota FCP, LCP, Speed Index y recursos bloqueantes.
- Genera o actualiza el crítico para la plantilla que vas a publicar.
- Verifica visualmente en móvil y desktop que no hay FOUC ni menú colapsado.
- Comprueba que el CSS diferido carga (pestaña Red sin errores 404).
- Repite la medición tras el despliegue y compara capturas del filmstrip.
Conclusión
El Critical CSS es una de las palancas más rentables para que una web de empresa «se vea lista» en el primer segundo, sin esperar a descargar estilos de páginas que el visitante quizá nunca abra. Encaja con el resto de tu estrategia de rendimiento: métricas de campo, imágenes optimizadas y menos JavaScript bloqueante. Si quieres priorizar plantillas con impacto en ventas y dejar el pipeline automatizado, en aatsoft podemos ayudarte a integrarlo en tu build sin fricción con marketing.
