Css critico: cos’è e come funziona il critical CSS

Css critico in sintesi

• Cosa contiene: solo le regole CSS che stilizzano l’area visibile senza scroll, non l’intero foglio di stile del sito.
• Dove si inserisce: dentro un tag <style> inline, subito sotto il <title> nell’<head> del documento.
• Come si genera: tramite tool online, pacchetti npm (Critical, Penthouse) o plugin specifici per CMS, raramente a mano.
• Effetto atteso: riduzione del render blocking e miglioramento di metriche come Largest Contentful Paint e First Contentful Paint.
• Rischio principale: l’over-inlining, che appesantisce l’HTML e peggiora il Time To First Byte percepito e la cache del browser.
• Quando serve davvero: quando il CSS è la principale risorsa che blocca il rendering iniziale, non in ogni scenario.

Cos’è il css critico e il contenuto above the fold

Il termine above the fold indica la parte di pagina che un visitatore vede appena il browser completa il primo render, prima di scorrere verso il basso: intestazione, menu di navigazione, titolo principale e il blocco di testo o immagine immediatamente sotto. Il css critico isola esattamente le dichiarazioni necessarie a quella porzione, lasciando fuori stili per footer, modali, animazioni o sezioni più in basso nella pagina.

La distinzione tra CSS critico e CSS non critico nasce da un comportamento del browser: ogni foglio di stile collegato tramite <link> è render-blocking, cioè sospende la costruzione della pagina finché non viene scaricato e processato interamente, anche se contiene regole che non servono al primo frame visibile. Isolare solo le regole indispensabili permette al browser di disegnare l’interfaccia iniziale senza attendere il resto del foglio di stile.

Nel 2022 la pagina desktop con il maggior peso CSS ha raggiunto 62.631 KB, un volume che se caricato per intero prima del render iniziale produce ritardi percepibili dall’utente — CSS | 2022 | Il Web Almanac di HTTP Archive (2022). Separare le poche regole necessarie al primo paint dal resto del foglio di stile riduce drasticamente la quantità di codice che il browser deve processare prima di mostrare qualcosa all’utente.

Il meccanismo tecnico si articola in due fasi distinte: l’estrazione, in cui uno strumento analizza il DOM e i fogli di stile della pagina per individuare le regole che riguardano il viewport iniziale, e l’inlining, in cui quelle regole vengono incollate direttamente nell’HTML anziché restare in un file esterno. Il resto del CSS continua a esistere come file separato, ma viene caricato in modo da non bloccare più il rendering.

Perché il css critico migliora le performance

Il css critico migliora le performance percepite perché elimina il tempo di attesa dovuto al download di un foglio di stile esterno prima che il browser possa disegnare la pagina. Quando un documento HTML dipende da uno o più file CSS collegati, il motore di rendering interrompe la costruzione della render tree finché quei file non sono completamente scaricati e analizzati; su connessioni lente questo blocco può superare i 100 millisecondi per ogni risorsa in coda.

L’impatto si misura soprattutto su due metriche dei Core Web Vitals: il FCP, cioè il momento in cui compare il primo elemento di contenuto, e il LCP, il tempo necessario a renderizzare l’elemento più grande visibile nel viewport. Riducendo le regole da scaricare prima del primo render, entrambi i tempi si accorciano in modo diretto.

Il peso crescente dei fogli di stile rende il problema più rilevante negli anni recenti: il CSS mobile più pesante è passato da 17.823 KB a 78.543 KB, e al 90° percentile la dimensione dei file CSS è cresciuta di quasi il 7% in un solo anno — CSS | 2022 | Il Web Almanac di HTTP Archive (2022). Un foglio di stile che aumenta di dimensione senza una strategia di caricamento differenziato penalizza proporzionalmente il tempo di primo render su ogni pagina che lo richiama per intero.

Oltre al beneficio tecnico, il miglioramento del tempo di rendering iniziale incide sull’esperienza percepita dall’utente: una pagina che mostra contenuto stilizzato entro i primi istanti viene percepita come più reattiva, anche se il tempo totale di caricamento completo resta invariato. Questo effetto è distinto dal beneficio in termini di posizionamento, che dipende dal superamento delle soglie dei Core Web Vitals definite da Google.

Come funziona il flusso di generazione e applicazione del css critico

Il flusso parte dal download dell’HTML da parte del browser: appena incontra il blocco <style> inline con il css critico, il motore di rendering procede subito a disegnare la pagina senza attendere risorse esterne. Il resto del foglio di stile, quello non critico, viene caricato in parallelo in modo da non interrompere questa prima fase di render.

Esempio pratico di css critico

In una pagina composta da intestazione, titolo principale e un paragrafo visibile all’apertura, il css critico contiene soltanto le regole che definiscono colore di sfondo, tipografia e posizionamento di questi tre elementi: nessuna regola per footer, gallerie fotografiche o sezioni più in basso.

Il blocco di css critico da inserire nell’head

Le poche righe di css critico vanno incollate dentro un tag <style> posizionato subito dopo il tag <title>, nella sezione <head> del documento HTML. Questa porzione minima definisce lo stile essenziale dell’intestazione e del primo blocco di testo, evitando che l’utente veda uno sfarfallio o una pagina bianca durante il caricamento.

Caricamento asincrono del css non critico

Il resto del foglio di stile, che include footer, sezioni inferiori e animazioni, viene caricato in modo non bloccante tramite l’attributo rel="preload" oppure con un foglio marcato media="print" che viene convertito in media="all" una volta scaricato. In entrambi i casi il browser scarica il file in background senza fermare il rendering già avviato con il css critico.

Per approfondire la gestione del caricamento differito degli script associati a questa stessa logica di performance, vedi la pagina dedicata agli attributi defer e async negli script HTML.

Come implementare il css critico passo dopo passo

L’implementazione segue una sequenza di tre operazioni, indipendentemente dallo strumento usato per generare il codice.

1. Genera il css critico per la pagina target usando un tool di estrazione o un plugin del proprio CMS, indicando l’URL della pagina da analizzare.
2. Inserisci il codice risultante dentro un tag <style> posizionato subito sotto il <title>, nell’<head> dell’HTML.
3. Rinvia il caricamento del foglio di stile originale con rel="preload" seguito dallo swap del rel al termine del download, oppure con la tecnica media="print".

Se la pagina viene modificata nella struttura visibile all’apertura — ad esempio cambia l’header o lo slider in evidenza — il css critico va rigenerato, perché le regole estratte in precedenza non corrispondono più al nuovo layout above the fold.

Strumenti per generare il css critico in automatico

Estrarre il css critico a mano è praticabile solo su pagine molto piccole con pochi selettori; su siti con fogli di stile complessi si ricorre a strumenti automatizzati, integrati in task runner o in piattaforme dedicate.

Generator online e gratuiti

Un generator online riceve in input l’URL della pagina, la visita con un browser headless basato su Chrome, analizza il rendering su diversi viewport e restituisce il css critico già pronto da incollare. Alcuni strumenti combinano più URL o più risoluzioni in un’unica estrazione per coprire sia desktop sia mobile.

Librerie e pacchetti npm

Tra i pacchetti Node.js più diffusi, Critical estrae e inserisce automaticamente il css critico supportando il rendering su viewport reale, mentre Penthouse si concentra sulla precisione dell’estrazione tramite rendering headless, con opzioni per includere o escludere selettori specifici tramite classi forzate.

Plugin WordPress per il css critico

Su WordPress l’estrazione viene gestita da plugin dedicati che generano il css critico al momento della creazione della cache e lo inseriscono automaticamente nella pagina, rendendo asincrono il caricamento del resto del foglio di stile. In alcuni sistemi la generazione in background richiede fino a 30 secondi prima che il risultato venga riflesso nella cache attiva.

Integrazione con Webpack, Vite e Gulp

Nei progetti con build pipeline personalizzata, l’estrazione del css critico viene integrata come task dentro Webpack, Vite o Gulp: lo script compila i fogli di stile sorgente, li passa a una libreria di estrazione come Penthouse impostando uno snapshot del viewport (ad esempio 1300×900 pixel) e un timeout di generazione, quindi salva il risultato come file separato da iniettare nell’head al momento del build.

È utile distinguere il css critico dalla rimozione del CSS inutilizzato: strumenti di tipo “unused CSS remover” o “purge CSS” eliminano selettori mai applicati in nessuna pagina del sito, mentre il css critico seleziona, tra le regole effettivamente usate, solo quelle necessarie al primo render di una pagina specifica. Sono tecniche complementari, non alternative.

Quando conviene usare il css critico e quando no

L’efficacia del css critico dipende dalla composizione del collo di bottiglia della pagina: non ogni sito trae lo stesso beneficio dalla tecnica.

Se il sito ha poche pagine statiche con layout fisso

Se gestisci un sito con poche pagine e layout stabile nel tempo, puoi generare il css critico una sola volta per ogni tipologia di pagina (home, articolo, categoria) e riutilizzarlo finché non cambi la struttura visibile above the fold, senza bisogno di rigenerazione automatica continua.

Se il sito è un e-commerce con migliaia di pagine dinamiche

Se il catalogo genera migliaia di pagine prodotto con layout condiviso, conviene generare il css critico su un campione rappresentativo per tipologia di template (prodotto, categoria, archivio) anziché per singola URL, integrando la generazione nel processo di build o di creazione della cache.

Se il CSS non è il principale collo di bottiglia

Se il tempo di caricamento della pagina dipende soprattutto da immagini pesanti, JavaScript bloccante o risposta lenta del server, il css critico produce un guadagno marginale: in questo caso conviene intervenire prima sulle risorse che pesano di più sul Time To First Byte e sul Largest Contentful Paint, e valutare il css critico come ottimizzazione successiva.

Errori comuni e rischi del css critico

L’applicazione scorretta della tecnica può peggiorare le performance invece di migliorarle, soprattutto quando si eccede nella quantità di codice inserito inline.

Over-inlining e peso dell’HTML

Quando il blocco di css critico contiene troppe regole, il documento HTML aumenta di peso e il tempo necessario a scaricarlo e processarlo cresce di conseguenza, con un impatto negativo sul Time To First Byte percepito dal browser. Inoltre il codice inline non può essere memorizzato nella cache del browser come un file esterno, quindi ogni modifica al CSS invalida l’intera pagina anziché un singolo file statico.

CSS duplicato e doppio parsing

Un errore frequente consiste nell’inserire una porzione di regole sia inline sia all’interno del foglio di stile esterno caricato successivamente: il browser analizza due volte le stesse dichiarazioni, con un overhead inutile che riduce parte del beneficio ottenuto con l’estrazione.

Errori di sintassi durante la generazione

Se il foglio di stile sorgente contiene errori di sintassi, alcuni strumenti di estrazione interrompono il processo e segnalano il file e la riga coinvolti: la generazione del css critico richiede quindi che il CSS della pagina sia sintatticamente valido prima di procedere.

Quando il CSS non è realmente il collo di bottiglia

Applicare il css critico su una pagina il cui rallentamento dipende da altre risorse produce un guadagno marginale rispetto allo sforzo di manutenzione richiesto per mantenere aggiornato il blocco inline a ogni modifica del layout.

Casi particolari: desktop, mobile e visitatori ricorrenti

Il css critico non è identico per ogni condizione di visualizzazione: viewport e cronologia di visita dell’utente cambiano l’efficacia della tecnica.

Css critico per desktop e per mobile

Poiché il viewport iniziale cambia tra dispositivo desktop e mobile, alcuni strumenti generano due file distinti di css critico, uno per ciascuna categoria di schermo, così da riflettere con precisione quali elementi risultano visibili senza scroll su ciascun dispositivo.

Nuovi visitatori rispetto ai visitatori ricorrenti

Il vantaggio del css critico è massimo per i nuovi visitatori, che non hanno ancora il foglio di stile completo nella cache del browser. Per i visitatori ricorrenti, che caricano il CSS già salvato in cache locale, il beneficio percepito si riduce, perché il file esterno viene recuperato senza una nuova richiesta di rete.

Quando unire più fogli di stile dopo l’estrazione

Se la pagina carica più di cinque risorse ad alta priorità oltre al css critico inline, accorpare alcuni fogli di stile non critici in un unico file riduce il numero di connessioni aperte dal browser e può velocizzare ulteriormente il caricamento complessivo; con un numero inferiore di risorse l’accorpamento porta benefici meno evidenti.

Domande frequenti sul css critico

Cos’è il css critico?

È il sottoinsieme minimo di regole CSS necessario a disegnare correttamente la porzione di pagina visibile prima dello scroll, inserito inline nell’HTML per evitare l’attesa di un foglio di stile esterno durante il primo render.

Dove va inserito il css critico nell’HTML?

Va inserito dentro un tag <style> posizionato subito dopo il <title>, all’interno della sezione <head> del documento, prima di qualsiasi riferimento al foglio di stile completo.

Come si genera il css critico in automatico?

Si genera con tool online che analizzano l’URL della pagina, con pacchetti npm come Critical o Penthouse integrati in una pipeline di build, oppure con plugin specifici del proprio CMS che lo creano al momento della cache.

Come funziona il css critico su WordPress?

Su WordPress l’estrazione viene gestita da plugin che generano il css critico alla creazione della cache o su richiesta manuale, lo inseriscono inline nella pagina e rendono asincrono il caricamento del resto del foglio di stile, con un tempo di aggiornamento che può arrivare a 30 secondi.

Quali sono i rischi dell’over-inlining?

Un blocco di css critico troppo esteso aumenta il peso dell’HTML, peggiora il tempo di risposta percepito e impedisce il salvataggio in cache separata del CSS, rendendo ogni modifica di stile un’invalidazione dell’intera pagina.

Che differenza c’è tra css critico e purge CSS?

Il css critico seleziona, tra le regole usate nel sito, solo quelle necessarie al primo render di una pagina specifica; il purge CSS invece elimina in modo permanente i selettori mai applicati in nessuna pagina, indipendentemente dal viewport iniziale.

Il css critico serve sempre?

No: se il rallentamento della pagina dipende principalmente da immagini pesanti, JavaScript bloccante o risposta lenta del server, il css critico produce un guadagno marginale rispetto ad altre ottimizzazioni prioritarie.