Lingue

Critical CSS: cos’è e come velocizzarlo

Critical CSS — estrarre gli stili above-the-fold, inserirli inline e rimandare il resto per velocizzare il primo paint. Perché Google lo definisce avanzato e facoltativo, i compromessi reali (cache persa, rischio di manutenzione, condizioni di gara) e come capire se il CSS è davvero il collo di bottiglia.

Prima pubblicazione: 3 lug 2026 · Ultimo aggiornamento: 3 ago 2026 · Advanced
Lingue
AIScritto daAI v2

Il Critical CSS è una tecnica di performance: estrai il CSS necessario a renderizzare una viewport above-the-fold scelta, inseriscilo nel <head> e rimanda asincronamente il resto del foglio di stile. Funziona perché il CSS è render-blocking per impostazione predefinita: il browser non esegue il paint finché non costruisce il CSSOM. Non esiste un’altezza above-the-fold universale (dispositivo, orientamento, zoom e stato della pagina la cambiano), quindi considera la separazione una decisione, non un taglio fisso in pixel. La cosa più importante: Google presenta il Critical CSS come tecnica avanzata e facoltativa, non come consiglio predefinito — la sua documentazione dice che la maggior parte dei siti può raggiungere gli obiettivi di performance senza implementarla. I compromessi sono reali: il CSS inline non è in cache per le visite ripetute, la separazione critical/non-critical si rompe quando cambiano template o stati, una policy CSP style-src può bloccare il blocco inline e il defer preload/onload può entrare in gara o causare spostamenti del layout. Diagnostica prima: conferma che il CSS, non JavaScript o il tempo di risposta del server, sia il collo di bottiglia. L’impatto SEO è indiretto tramite Core Web Vitals/LCP, non un fattore di ranking diretto. Non esiste una guida specifica di Bing. Questa pagina è annidata sotto l’hub critical rendering path.

TL;DR — Critical CSS = estrai gli stili above-the-fold, inseriscili nel <head> e rimanda asincronamente il resto del foglio di stile (rel="preload" + scambio onload, fallback <noscript> o loadCSS). Funziona perché il CSS è render-blocking per impostazione predefinita. Il punto centrale dell’accuratezza: Google lo presenta come avanzato e facoltativo, non come consiglio predefinito — “Most sites should be able to achieve all of our recommended performance targets without implementing this technique.” Mantieni piccolo il payload inserito. I compromessi sono reali: il CSS inline non viene memorizzato nella cache tra i caricamenti (le visite ripetute possono essere più lente), la separazione critical/non-critical si rompe quando cambiano i template e il defer può entrare in gara o causare FOUC/CLS. Diagnostica prima — conferma che il CSS, non JavaScript o il tempo di risposta del server, sia il vero collo di bottiglia. Fai attenzione alle insidie che una demo rapida non mostra: una policy CSP style-src può bloccare del tutto il tuo blocco inline <style>, “unused at capture” non significa “safe to defer” tra temi/personalizzazione/stati e l’inlining non risolve i tempi di caricamento dei font. L’impatto SEO è indiretto tramite Core Web Vitals/LCP. Non esiste una guida specifica di Bing.

Che cos’è davvero il Critical CSS

Il problema che risolve è il CSS render-blocking. web.dev di Google è esplicito: Per impostazione predefinita, il CSS è trattato come una risorsa che blocca il rendering, cioè il browser non renderizza alcun contenuto elaborato finché non viene costruito il CSSOM. È l’intero motivo per cui esiste la tecnica: il browser rifiuta di eseguire il paint finché non ha gli stili, quindi tutto ciò che ritarda il CSS ritarda il primo paint. (Per la pipeline completa sottostante, consulta l’hub critical rendering path sotto cui questa pagina è annidata e il suo argomento gemello, render-blocking resources.)

Il Critical CSS affronta il problema dividendo il CSS in due. La definizione di web.dev: “Critical CSS is a technique that extracts the CSS for above-the-fold content in order to render content to the user as fast as possible.” E i meccanismi: Inlining extracted styles in the head of the HTML document eliminates the need to make an additional request to fetch these styles. The remainder of the CSS can be loaded asynchronously (in italiano: inserire gli stili estratti nel <head> del documento HTML elimina la necessità di effettuare una richiesta aggiuntiva per recuperarli; il resto del CSS può essere caricato in modo asincrono).

Evidence for this claim Critical CSS extracts and inlines above-the-fold styles so the remaining CSS can load asynchronously. Scope: web.dev definition and implementation outline for critical CSS. Confidence: high · Verified: web.dev: Extract critical CSS

Una cosa che web.dev dichiara apertamente e che molte guide secondarie sorvolano: non esiste un’unica altezza universale above-the-fold — dimensioni e orientamento del dispositivo, chrome del browser, livello di zoom e stato della pagina (menu aperto, personalizzazione caricata, stato di errore) cambiano tutto ciò che deve rientrare nell’insieme “critical”. Considera il Critical CSS una decisione su una specifica viewport/stato iniziale, non una soglia fissa in pixel, e convalidalo rispetto ai breakpoint e agli stati reali, non a un solo screenshot desktop.

Quindi i lavori sono due, in quest’ordine:

  1. Inserisci il CSS above-the-fold minimo nel <head> — nessun round trip aggiuntivo prima del primo paint.
  2. Rimanda il resto del foglio di stile — caricalo asincronamente perché non blocchi mai quel primo paint.

È esattamente così che l’ho diviso nei miei interventi sulla page experience. Nel deck What’s Next for Page Experience (SMX Next 2021) ho messo il lavoro CSS in due contenitori: un percorso early/critical (rimuovi CSS inutilizzato → minimizza CSS → inserisci il Critical CSS) e un percorso late/deferred (rimanda il CSS non critical). La forma è quella di web.dev, solo ordinata nel modo in cui la penso.

Come implementarlo

Passaggio 1 — inserisci il Critical CSS. Le indicazioni di Lighthouse dicono di inserire gli stili critical necessari al primo paint dentro un blocco <style> nell’head della pagina HTML. Il target dimensionale di Google per quel payload inline, dalla stessa pagina, è mantenere il contenuto above-the-fold sotto i 14 KB (compresso), così entra nel primo round trip di rete. Considera il numero una guida storica al trasporto, non una specifica eterna: la pagina sorgente è del 2019 e precede l’ampia diffusione odierna di HTTP/2 e HTTP/3, che cambiano entrambi la matematica del primo round trip. È ancora il numero citato dalla documentazione Google, ma se stai ottimizzando in modo serrato verificalo rispetto al protocollo e al comportamento attuali del server invece di trattare 14 KB come un dogma.

Passaggio 2 — rimanda il resto. Il pattern che web.dev raccomanda per rimandare il CSS non critical è un preload con scambio onload più un fallback <noscript>:

<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>

Per la produzione, web.dev consiglia di usare funzioni che rimandano il CSS, come loadCSS, che incapsulano questo comportamento e funzionano bene tra i browser invece di costruire lo scambio a mano. Se rimandi con JavaScript, web.dev nota che aspettare l’esecuzione di JavaScript prima di caricare il CSS non critical può ritardare il rendering quando gli utenti scorrono, motivo per cui si usa preload per avviare prima il download.

Strumenti. Raramente si estrae il Critical CSS a mano. L’implementazione di riferimento di Google è il pacchetto npm critical (Addy Osmani), “a tool that extracts, minifies and inlines above-the-fold CSS.” Tra le alternative ci sono Penthouse e CriticalCSS, oltre a numerosi generatori SaaS/plugin per WordPress e Shopify. Per individuare le regole critical, Google rimanda alla scheda Coverage in Chrome DevTools per identificare CSS e JS non critical.

Se usi un plugin o un generatore (WP Rocket, Autoptimize e simili), non prendere un walkthrough dell’interfaccia del vendor o uno screenshot del punteggio prima/dopo come garanzia per la piattaforma: quelle pagine mescolano liberamente versioni del prodotto e risultati di siti specifici, e le differenze di punteggio non sono riprodotte in modo indipendente. Prima di fidarti in produzione, conferma il comportamento nella documentazione e nel numero di versione attuali del plugin e sottoponilo alla stessa matrice di test che useresti per un’implementazione manuale: caricamenti a freddo e ripetuti, breakpoint/temi/stati reali e policy CSP, se ne usi una.

Nota che il Critical CSS è solo una delle correzioni al CSS render-blocking. Le altre sono limitare i fogli di stile con l’attributo media (così vengono scaricati ma non bloccano il paint) e inviare semplicemente meno CSS in primo luogo: l’articolo di web.dev sul render-blocking punta in realtà sull’approccio dell’attributo media invece che sull’inlining, quindi Google ha più di una prescrizione ufficiale a seconda del documento che leggi.

La posizione effettiva di Google (il filo dell’accuratezza)

È la parte che quasi ogni articolo concorrente nasconde, ed è il motivo per cui ho voluto scrivere questo. Google non presenta il Critical CSS come consiglio predefinito. Il suo codelab è netto sul rischio: Questo codelab descrive una tecnica avanzata di performance che può migliorare le prestazioni, ma può anche causare bug se non viene implementata correttamente. E, in due punti della documentazione, Google dice che la maggior parte dei siti non dovrebbe preoccuparsene: La maggior parte dei siti dovrebbe riuscire a raggiungere tutti i nostri obiettivi di performance consigliati senza implementare questa tecnica.

Evidence for this claim web.dev presents critical CSS as an advanced technique that can cause bugs and says most sites can meet performance targets without it. Scope: web.dev codelab guidance; not a universal recommendation. Confidence: high · Verified: web.dev: Extract and inline critical CSS

Anche il vantaggio ha un avvertimento. web.dev segnala che l’inlining ha anche alcuni svantaggi perché impedisce al browser di memorizzare il CSS nella cache per riutilizzarlo nei caricamenti successivi, quindi è meglio usarlo con parsimonia — e, quando si esagera, se tutto ha la priorità, nulla ce l’ha. Inserisci troppo CSS inline e gonfi l’HTML che stai cercando di consegnare rapidamente.

La formulazione onesta è quindi: il Critical CSS è una tecnica reale, documentata e talvolta potente, ma è avanzata, facoltativa e da ultima risorsa; Google dice che la maggior parte dei siti non ne ha bisogno per raggiungere i propri obiettivi. Trattalo come tale.

I compromessi reali

Gli ingegneri indipendenti delle performance sono stati le voci più insistenti su questo punto e le loro osservazioni coincidono con le cautele di Google.

Cache persa nelle visite ripetute. Matt Zeunert di DebugBear lo afferma chiaramente: il Critical CSS non può essere riutilizzato tra diversi caricamenti di pagina sul sito, quindi le visite successive possono essere effettivamente più lente di quanto sarebbero senza Critical CSS. Un foglio di stile esterno normale viene memorizzato una volta e riutilizzato ovunque; il CSS inline viene scaricato di nuovo dentro ogni risposta HTML.

Rischio di manutenzione e regressioni. Il pezzo controcorrente di Harry Roberts è il punto di vista più citato e il suo avvertimento è che adattare il Critical CSS a posteriori è difficile e soggetto a errori: una volta identificato il CSS come collo di bottiglia, “you need to keep it that way… One wrong decision can undo everything.” Non esiste una rivalidazione automatica: una modifica al template o al design può rompere silenziosamente la separazione critical/non-critical.

Condizioni di gara nel defer. Roberts osserva anche che lo scambio preload/onload può ritorcersi contro sul piano dei tempi: se servono 1s per analizzare il tuo <head> e 0,5s per recuperare asincronamente il CSS non-Critical, il CSS tornerà a essere un file sincrono 0,5s prima che tu sia comunque pronto a partire. E quando il CSS non critical arriva tardi, rischi un flash di contenuto senza stile e uno spostamento del layout.

Spesso non è affatto il collo di bottiglia. La tesi centrale di Roberts è: il Critical CSS aiuta solo se il CSS è il tuo più grande collo di bottiglia nel blocco del rendering, e molto spesso non lo è. DebugBear concorda: prima dell’inlining, controlla che il CSS sia davvero il problema, perché se hai ancora codice JavaScript render-blocking, è improbabile che l’inlining del CSS aiuti, e “often it’s not the most impactful optimization.”

Insidie di produzione: CSP, stato e font

Tre ulteriori modalità di errore che non emergono in una demo rapida ma colpiscono quando la tecnica è online:

Una policy CSP può bloccare del tutto il tuo blocco inline <style>. Una policy Content-Security-Policy style-src può bloccare un blocco critical inline <style> se la policy non lo autorizza esplicitamente, di solito tramite nonce o hash corrispondente. MDN documenta i casi di violazione e i meccanismi nonce/hash. Ricorrere a unsafe-inline per far sparire l’errore della console indebolisce la policy sull’intero sito e non è una correzione predefinita: collega la generazione di nonce/hash allo strumento che estrae il Critical CSS e controlla la console del browser per le violazioni dopo il rilascio.

“Unused at capture” non significa “safe to defer”. La scheda Coverage mostra quale CSS è stato eseguito durante una registrazione. Una separazione sicura deve preservare l’ordine della cascata e le regole necessarie per breakpoint responsive, varianti del tema, contenuti personalizzati, stati di focus, menu/modali aperti e stati di errore, non solo ciò che è stato renderizzato in quel singolo passaggio. Roberts pone la stessa domanda da un’altra prospettiva: quale viewport e quali elementi fuori schermo o non interagiti (dropdown, flyout) deve effettivamente coprire la tua estrazione?

Non risolve il problema dei font e può aggiungere lavoro al rendering. Inserire gli stili degli elementi non rende di per sé un web font scopribile prima né garantisce che il testo venga renderizzato in tempo: scoperta del font, preload, font-display e metriche di fallback sono dipendenze separate che il Critical CSS non tocca. E applicare un sottoinsieme inline seguito da un foglio di stile più grande può significare ricalcolo aggiuntivo degli stili, layout e paint; ridurre il ritardo di recupero non significa automaticamente ridurre il lavoro totale di rendering. Misura entrambi, non solo il waterfall di rete.

Come diagnosticare se ti serve davvero

Dato tutto questo, non iniziare con “aggiungi Critical CSS”: inizia con “conferma che il CSS sia il mio collo di bottiglia nel rendering” e non fermarti lì. Ci sono quattro cancelli e tutti devono essere superati prima che valga la pena farlo:

1. Il CSS è un blocco dimostrato, non un’ipotesi.

  • Apri il report PageSpeed Insights / Lighthouse. A partire da Lighthouse 13, il vecchio audit “Eliminate render-blocking resources” è confluito nell’insight Render-blocking requests: gli articoli più vecchi che citano il vecchio nome dell’audit sono obsoleti.
  • Usa la scheda Coverage in Chrome DevTools per vedere quanto del tuo CSS (e JS) è davvero inutilizzato al primo paint.
  • Separa le cause. Se il collo di bottiglia è JavaScript render-blocking o una risposta lenta del server (TTFB), inserire il CSS inline non risolverà il problema: ottimizzeresti la cosa sbagliata.

2. Puoi costruire una copertura di estrazione davvero stabile — attraverso breakpoint, temi, personalizzazione e stati interattivi reali, non un solo screenshot desktop (vedi le insidie sopra).

3. Il costo delle visite ripetute e della CSP è accettabile. Il CSS inline non viene memorizzato nella cache, quindi soppesa il costo rispetto alla profondità della sessione tipica. Se usi una policy CSP style-src, la generazione di nonce/hash deve essere collegata alla pipeline prima del rilascio, non scoperta dopo.

4. Lo manterrai davvero. Rigeneralo a ogni modifica di template o design e riesegui la matrice di test completa — caricamenti a freddo e ripetuti, ogni route/viewport/stato supportato — non un singolo controllo a occhio dopo il deploy.

Se tutti e quattro i cancelli tengono, il Critical CSS vale il costo di manutenzione. Se anche uno solo non tiene, le correzioni più economiche — rimuovere CSS inutilizzato, minimizzare, limitare i fogli di stile non critical con media — sono la scelta migliore.

Un problema attuale del 2026

C’è una complicazione attuale da segnalare: esiste un report aperto e non risolto secondo cui l’esatto pattern <link rel="preload" as="style"> che la documentazione Google raccomanda per rimandare il CSS ha ricominciato a essere segnalato come render-blocking dopo un aggiornamento dei punti Lighthouse/PSI. L’issue #17031 su GitHub documenta CSS precaricato che appare verde in Lighthouse 13.0.1 e poi viene segnalato come render-blocking in 13.3.0. Al momento non esiste una risoluzione Google pubblica, quindi trattalo come un tema in sviluppo, ma la lezione pratica resta: se PSI segnala il tuo CSS correttamente rimandato, l’audit può essere sbagliato; leggi il report criticamente invece di presumere che l’implementazione sia rotta.

Il Critical CSS aiuta la SEO?

Indirettamente e in misura modesta. Occorre separare due cose:

  • Il CSS non è un segnale di ranking diretto. Martin Splitt ha detto dei nomi delle classi CSS: “I don’t think we care because the CSS class names are just that.” Si riferisce nello specifico ai nomi delle classi, ma smentisce il mito più ampio secondo cui le tue scelte CSS vengono lette come input di ranking.
  • La velocità è un segnale piccolo, tramite i Core Web Vitals. Il Critical CSS può migliorare il primo paint, che può migliorare LCP, una metrica dei Core Web Vitals che alimenta i segnali di page experience di Google. Questo è tutto il collegamento SEO: un paint più veloce, non un bonus per la tecnica in sé.

Il caso SEO del Critical CSS è esattamente forte quanto il suo impatto sull’LCP del tuo sito, che, secondo Google e la comunità delle performance, è spesso più piccolo di quanto suggeriscano i tool dei vendor che lo vendono.

E Bing?

Niente di specifico per Bing. A differenza di Google, che ha più pagine web.dev e un codelab sulla tecnica, non ho trovato alcun documento Bing/Microsoft dedicato al Critical CSS. Si applicano le indicazioni generali di Bing su performance e UX (mantieni le cose veloci e i contenuti critical raggiungibili), ma non esiste un equivalente Bing del codelab Critical CSS di web.dev. Chi sostiene che Bing abbia una raccomandazione specifica sul Critical CSS la sta inventando.

Dove si colloca

Questa pagina è annidata sotto l’hub critical rendering path: il Critical CSS è una tattica per accorciare quel percorso — ed è il fratello pratico di render-blocking resources. Il beneficio, quando c’è, appare in Largest Contentful Paint (LCP), First Contentful Paint (FCP) e nell’insieme più ampio dei Core Web Vitals. Per il quadro più ampio della performance, vedi il cluster web performance.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.