Performance
CSS critico: quanto cambia il primo paint
Un foglio da 183.789 byte in testa dà FCP 1.308 ms; con le regole del primo schermo inline e il resto differito il FCP scende a 276 ms, con gli stessi byte totali. Misura e limiti.
In sintesi
- Con 183.789 byte di CSS in testa il FCP è 1.308 ms; con il critico inline e il resto differito è 276 ms.
- I byte totali non cambiano: cambia solo l'ordine in cui il browser li usa.
- Il CLS è passato da 0 a 0,0001 perché il foglio differito arriva dopo il primo paint.
- La home carica 5 fogli per 22.486 byte compressi: il critico vale quando il foglio è uno solo e grande.
Inlinare il CSS critico ha anticipato il primo paint di 1.032 ms: con un foglio da 183.789 byte in testa il FCP è 1.308 ms, con le regole del primo schermo inline e il resto differito scende a 276 ms. I byte totali sono gli stessi, cambia l'ordine.
Le due misure
| Variante | CSS trasferito | FCP | LCP | CLS |
|---|---|---|---|---|
| Foglio bloccante in testa | 183.789 B | 1.308 ms | 1.308 ms | 0 |
| Critico inline + resto differito | 183.789 B | 276 ms | 276 ms | 0,0001 |
Il browser non dipinge finché non ha scaricato e applicato il foglio bloccante: 1.032 ms di attesa su una rete lenta. Con il critico inline dipinge subito e tratta il resto come un foglio che non serve al primo schermo.
Il codice
/* regole del primo schermo, non il framework intero */
.hero { font: 600 28px/1.2 system-ui; }
media="print" rende il foglio non bloccante e onload lo riporta a all appena arriva. Il noscript copre chi non esegue JavaScript, che altrimenti resterebbe senza stili.
Quanto costa inline
Le regole critiche finiscono nell'HTML di ogni pagina: 2 KB su una pagina sono 2 KB su mille pagine, e non si mettono in cache come un file. Il resto resta un file unico con cache lunga, quindi 183.789 byte si scaricano una volta sola. È un compromesso, non un guadagno gratuito.
Come si estrae
- Parti dalle regole che servono davvero al primo schermo, non dall'intero reset: la home carica 5 fogli, 22.486 byte. Fonte: web.dev, CC BY 4.0.
- Tieni un solo file per il resto, con hash nel nome e cache lunga. Fonte: web.dev, CC BY 4.0.
- Non usare
media="print"senzanoscript: senza JavaScript la pagina perde gli stili. Fonte: MDN, CC BY-SA 2.5. - Rimisura dopo ogni cambio: 276 ms contro 1.308 ms è il divario di questa prova, non una costante.
Il limite da dichiarare
La prova ha un foglio solo e nessuna cache: alla seconda visita il foglio bloccante arriva dal disco o dal service worker, e il guadagno si riduce a pochi millisecondi. Il critico inline alza l'HTML e quindi il TTFB, e se dimentichi una regola il CLS peggiora: nella nostra prova il foglio differito ha spostato il layout di 0,0001.
Dove continuare
Il catalogo EneUI indicizza 111.985 componenti, per esempio pricing, e la griglia 1.556 blocchi: ogni blocco aggiunge CSS al foglio. Leggi come si fissa un performance budget, cosa sono i Core Web Vitals, il bundle splitting e il confronto framework frontend a confronto.
Domande frequenti
Cos'è il CSS critico?
È la parte di CSS che serve a disegnare ciò che si vede senza scroll. Si mette inline nell'HTML, il resto si carica dopo il primo paint.
Quanto si guadagna davvero?
Nella nostra prova 1.032 ms di FCP su una rete lenta. Su una connessione veloce o con il foglio in cache il guadagno scende a poche decine di millisecondi.
media=print con onload è sicuro?
Funziona, ma richiede il noscript e un onload che scatti davvero. In alternativa si usa rel=preload seguito da un cambio di rel, con gli stessi rischi.
Il CSS critico peggiora il CLS?
Può peggiorare se il critico non copre le regole del primo schermo: il resto arriva dopo e sposta il layout. Nella prova il CLS è passato da 0 a 0,0001.
Si può fare tutto in build?
Sì. Gli strumenti che estraggono il critico analizzano l'HTML e il CSS e generano il blocco inline: la parte difficile è scegliere quali viewport considerare.