Entres a la web d’un competidor i el menú i el titular apareixen a l’instant, mentre que a la teva el visitant mira tres segons una pantalla en blanc abans que surti la capçalera. Sovint no és el servidor: és el CSS bloquejant que retarda el primer render. El Critical CSS (CSS crític) és el conjunt mínim d’estils necessaris per pintar el que l’usuari veu sense fer scroll — el «above the fold».
Aquest article explica què és el CSS crític, com encaixa amb l’FCP, l’LCP i el Speed Index, com extreure-lo sense trencar el disseny i quins errors evitar en webs d’empresa el 2026.
Què és el Critical CSS i per què importa en una web corporativa
El navegador no pinta contingut fins que descarrega i analitza el CSS que bloqueja el renderitzat. Si la teva fulla d’estils principal pesa 400 KB i el visitant només necessita 8 KB per veure el hero i la navegació, estàs retardant la primera impressió sense necessitat.
- CSS crític: regles que afecten només el viewport inicial (capçalera, hero, tipografia base, graella principal).
- CSS no crític: estils de peu de pàgina, modals, pàgines internes, animacions below-the-fold.
- Objectiu: inline o servir el crític en la primera resposta HTML i carregar la resta de forma asíncrona.
- Benefici mesurable: millora l’FCP i sol baixar el Speed Index perquè el filmstrip s’omple abans.
La guia de web.dev sobre extracció de CSS crític descriu l’enfocament recomanat per l’equip de Chrome.
Com es relaciona amb altres mètriques de rendiment
El CSS crític no substitueix optimitzar imatges o reduir JavaScript, però desbloqueja el camí cap al primer pintat. Un TTFB alt continua sent un coll d’ampolla; però, amb HTML ràpid, el següent fre habitual és el CSS bloquejant.
Si l’LCP és un bloc de text estilitzat, el crític ha d’incloure aquestes classes. Si l’LCP és una imatge hero, prioritza dimensions i fetchpriority, però no oblidis els estils del contenidor que eviten el salt de layout (CLS).
Com extreure el CSS crític (enfocament pràctic)
Eines i automatització
- Critical (npm): genera CSS crític a partir d’URL i plantilles.
- Penthouse / critical-css: útils en pipelines de build (Vite, Webpack).
- Lighthouse: assenyala CSS no utilitzat; complementa, no substitueix, l’extracció manual.
- Chrome DevTools → Coverage: grava la càrrega i mostra quines regles no s’apliquen above-the-fold.
Extracció manual controlada
Per landings amb poc canvi, copiar a un <style> al <head> les regles de capçalera, tipografia, contenidor i hero pot ser fiable. Documenta quines plantilles usen aquest bloc per no duplicar manteniment sense criteri.
Carregar el CSS no crític sense bloquejar
Patró clàssic: <link rel="preload" href="app.css" as="style" onload="this.rel='stylesheet'"> més un <noscript> de reserva. Alternativa: dividir bundles per ruta (home vs. blog) perquè cada pàgina descarregui menys CSS bloquejant.
Quines millores esperar (referències 2026)
No hi ha un «nombre màgic» de kilobytes per al crític: depèn del disseny. Com orientació en webs d’empresa:
- Crític inline: apunta a < 14 KB comprimit a la home (menys és millor si el disseny ho permet).
- CSS bloquejant total: reducció visible en Lighthouse «Render-blocking resources».
- FCP / Speed Index: millores de 0,3–1,2 s en mòbil simulat són habituals després d’un bon crític i fonts optimitzades.
Mesura sempre la mateixa URL abans i després del desplegament; el tràfic real en Core Web Vitals confirma si el canvi val a producció.
Per què moltes webs d’empresa ho ajornen
- Un únic
app.cssde 500 KB generat pel tema de WordPress o el framework. - Frameworks que hidraten tard i amaguen contingut fins carregar tot el CSS.
- @import en cadena i fonts externes sense
font-display: swap. - Por que l’inline «embruti» l’HTML o compliqui la memòria cau (soluble amb build automatitzat).
- Equips de màrqueting que publiquen landings sense passar pel pipeline de front.
Accions que solen funcionar
Prioritzar plantilles amb tràfic
Home, serveis, contacte i landings de campanya primer. El blog pot usar un crític més lleuger si el disseny és més simple.
Eliminar CSS no utilitzat
PurgeCSS o equivalent al build, més auditoria periòdica. Combina amb la minificació — treure regles mortes impacta més que comprimir un fitxer enorme.
Fonts i text visible
Subconjunts, precàrrega només de la variant del hero i font-display: swap. El text llegible forma part del crític percebut.
Imatges i crític
Define width/height al hero i estils del contenidor al bloc crític. Usa WebP o AVIF i lazy loading per allò que queda sota el plec.
Xarxa i memòria cau
Serveix HTML i crític amb compressió Brotli o Gzip i capçaleres de caché coherents. Un CDN acosta el CSS no crític, però l’inline ja viatja amb l’HTML.
Errors freqüents en implementar Critical CSS
- Inline de 80 KB «per si de cas» que infla l’HTML i empitjora el TTFB percebut.
- Crític desactualitzat després d’un canvi de disseny: menú trencat o colors incorrectes a la primera pintura (FOUC).
- Dues versions del mateix component (inline + bundle) amb regles contradictòries.
- Oblidar estats responsive: el crític d’escriptori no serveix en mòbil.
- Confondre crític amb «treure tot el CSS» i perdre accessibilitat o contrast.
Checklist abans del proper desplegament
- Lighthouse mòbil a la home: anota FCP, LCP, Speed Index i recursos bloquejants.
- Genera o actualitza el crític per la plantilla que publicaràs.
- Verifica visualment en mòbil i escriptori que no hi ha FOUC ni menú col·lapsat.
- Comprova que el CSS diferit carrega (pestanya Xarxa sense errors 404).
- Repeteix la mesura després del desplegament i compara captures del filmstrip.
Conclusió
El Critical CSS és una de les palanques més rendibles perquè una web d’empresa «es vegi a punt» en el primer segon, sense esperar a descarregar estils de pàgines que el visitant potser no obrirà mai. Encaixa amb la resta de la teva estratègia de rendiment: mètriques de camp, imatges optimitzades i menys JavaScript bloquejant. Si vols prioritzar plantilles amb impacte en vendes i automatitzar el pipeline, a aatsoft podem ajudar-te a integrar-lo al teu build sense fricció amb màrqueting.
