Richieste render-blocking in Lighthouse: come risolverle

Le richieste render-blocking danneggiano il punteggio?

Lighthouse elenca ogni foglio di stile e script che la pagina ha atteso prima del first paint nell'insight Render-blocking requests ("Requests are blocking the page's initial render, which may delay LCP"), chiamato "Eliminate render-blocking resources" prima di Lighthouse 13. L'insight non incide sul punteggio, ma mentre la pagina attende il CSS e gli script rimane bianca, ritardando FCP e LCP, soprattutto su mobile. Riduci e combina il CSS e differisci gli script.

Cosa controlla l'insight Render-blocking requests?

La descrizione di Lighthouse dice: "Requests are blocking the page's initial render, which may delay LCP. Deferring or inlining can move these network requests out of the critical path." L'inlining non è la soluzione: vedi sotto. La tabella ha tre colonne: URL, Transfer Size e Duration. Transfer Size è il file così com'è stato inviato, compresso. Duration è la stima di Lighthouse sul tempo impiegato dalla richiesta su uno smartphone lento, inclusa una nuova connessione a un altro dominio.

Mentre carica una pagina, Chrome contrassegna ogni richiesta come render-blocking o meno e lo registra nel proprio trace. Lighthouse legge il trace ed elenca ogni richiesta nel frame principale che Chrome ha contrassegnato come bloccante e che è terminata prima del first paint. In pratica si tratta dei fogli di stile e degli script sincroni nell'<head> e dei file richiamati tramite @import. Un foglio di stile nel body conta solo alla priorità più alta di Chrome, uno script con priorità alta; dopo la prima immagine entrambi scendono di priorità e vengono saltati. Non c'è alcuna soglia: basta un solo file in elenco per fallire l'insight.

Alcuni file non compaiono mai, anche quando rallentano la pagina: script async, file aggiunti alla pagina da uno script (gtm.js, gtag.js), stili e script inline, qualsiasi elemento in un iframe e i font.

L'insight su una pagina prodotto di WooCommerce, Lighthouse 13.5.0, throttling simulato come in PageSpeed Insights.

Cosa rende un file render-blocking?

Render-blocking significa che il browser non renderizza nulla finché quel file non è arrivato: ogni foglio di stile nell'<head> deve arrivare e ogni script sincrono presente lì deve essere scaricato ed eseguito.

• Uno script dopo un foglio di stile attende quel foglio di stile. Chrome non esegue uno script sincrono finché il CSS sovrastante non è arrivato, e il parser attende lo script. Entrambi i file possono essere scaricati in parallelo, ma paghi comunque prima il CSS e poi lo script.
• Un @import parte in ritardo. Il preload scanner di Chrome rileva subito tutti i link nell'HTML, mentre un @import all'interno di un file CSS viene trovato solo quando quel file è arrivato. Nella pagina prodotto qui sotto, il foglio di stile importato del tema è partito a 1,28 s, contro 0,59 s quando era collegato dall'HTML.
• Un altro dominio richiede una connessione. Un foglio di stile su fonts.googleapis.com o su una CDN richiede DNS, TCP e TLS prima che arrivi il primo byte.

Le richieste render-blocking influiscono su FCP e LCP?

L'ho misurato su una pagina prodotto di WooCommerce con nove fogli di stile e due script nell'head, su smartphone con connessione Slow 4G. Nella versione corretta il CSS è ridotto e combinato in un unico foglio di stile da 6,6 kB ed entrambi gli script sono differiti. Una volta caricata, la pagina è esattamente identica.

FCP

L'originale ha effettuato il first paint a 2,12 s, la versione corretta a 1,39 s.

Entrambe le versioni a 1,4 s sullo smartphone con throttling: l'originale è ancora bianco.

LCP

Il LCP non può avvenire prima del first paint. Qui l'elemento LCP è la foto del prodotto, che non può apparire prima che sia arrivato anche il CSS: con il fix il LCP è passato da 2,25 s a 1,91 s. Nella scomposizione del LCP quell'attesa figura come element render delay. Lighthouse non lo mostra: con un'immagine come elemento LCP stima sempre il risparmio su LCP a 0 ms, quindi non interpretarlo come assenza di impatto sul LCP.

Quanti siti sono interessati e quando si può ignorare?

Quasi tutti. State of CWV analizza le home page di 114.526 siti con dati CrUX: il 92,8% ha almeno una richiesta render-blocking, il 91,2% un foglio di stile bloccante e il 62,5% uno script bloccante. Nei siti che ne hanno, la mediana è di 8 richieste e 110 kB, e un sito su cinque ne ha più di 20. (State of CWV conta i fogli di stile e gli script sincroni nell'head, ricalcando da vicino l'elenco di Lighthouse.)

I siti che ne hanno molte ottengono risultati peggiori nei field data. L'84,0% dei siti senza alcuna richiesta ha un buon FCP su mobile, contro il 54,1% dei siti con più di 20. Ma è il server a spiegare gran parte di questo calo: nello stesso intervallo il TTFB mediano raddoppia, passando da 538 ms a 1.114 ms. Suddiviso per velocità del server:

Siti con un buon FCP su mobile in base al numero di richieste render-blocking e al tempo di risposta del server. State of CWV, ottobre 2026, CrUX p75 su mobile, buon FCP a 1,8 s o meno.

• Server veloce (TTFB sotto i 600 ms): dal 94 al 97% ha un buon FCP, indipendentemente dal numero di richieste. Il ritardo c'è comunque: dal primo byte al first paint servono circa 150-200 ms in più con 21 o più richieste bloccanti rispetto a zero.
• Server lento (TTFB da 900 ms in su): la percentuale con un buon FCP scende da circa metà dei siti (47-53%) con fino a due richieste bloccanti al 30% con 21 o più. Con un TTFB di 900 ms o più, restano meno di 0,9 s prima della soglia di 1,8 s per un buon FCP, quindi ogni richiesta extra che il paint deve attendere può far sforare il FCP.

I siti WordPress ne hanno di più: il 57% ha 16 o più richieste bloccanti (mediana 19, 163 kB). A parità di velocità del server, questo costa 3 punti di buon FCP rispetto a una o cinque richieste su un hosting veloce, e circa 10 punti su un hosting lento.

È una correlazione, ma definisce le priorità: con un TTFB lento, sistema prima il server. Su un server veloce, recuperare quei 150-200 ms vale comunque la pena quando si tratta del proprio CSS. Puoi ignorare l'avviso quando:

• Lighthouse elenca solo uno o due piccoli fogli di stile propri, ciascuno sotto i 15 kB circa;
• il file in elenco è uno strumento di consenso, uno snippet di A/B test o un file della piattaforma che non puoi modificare (vedi sotto).

Come individuare le richieste render-blocking nei field data?

Lighthouse carica la pagina una sola volta, a freddo. Dopo la prima pagina i visitatori hanno il CSS in cache, quindi nei field data l'impatto si manifesta soprattutto sulla prima pagina caricata da un visitatore. In CoreDash osserva due elementi su mobile:

• FCP accanto a TTFB. I file render-blocking consumano tempo tra il primo byte e il first paint. Un template in cui questo divario è più ampio rispetto agli altri ne carica di più.
• Render delay di LCP. Cerca i template in cui il render delay costituisce una parte consistente di LCP. Il CSS bloccante è una delle cause di quell'attesa; DevTools (nella sezione successiva) mostra se la pagina ne contiene.

CrUX fornisce le stesse metriche al p75 per l'intera origine o per un URL, senza però indicare quale template sia lento.

CoreDash su un negozio di esempio, acme-pagespeed.com, mobile, p75: le pagine prodotto e di categoria sono quelle lente.

Come trovare i file bloccanti in DevTools?

Apri la pagina in Chrome, vai nel pannello Performance, imposta la rete su Slow 4G e la CPU su 4x slowdown, quindi registra un ricaricamento. La barra laterale Insights elenca Render-blocking requests. Cliccaci sopra e DevTools evidenzierà ogni richiesta bloccante nella traccia Network.

Ogni barra va dal momento in cui la richiesta è partita fino all'arrivo dell'ultimo byte. Cerca la richiesta che termina per ultima prima del marcatore FCP: è quella che il paint ha atteso. Una richiesta CSS che parte solo quando un'altra finisce è un @import. Quando non c'è alcun blocco, la barra laterale mostra "No render-blocking requests for this navigation".

Come risolvere le richieste render-blocking?

L'URL nella tabella di Lighthouse indica la provenienza di ciascun file, determinando dove intervenire.

CSS e script proprietari

Nei tuoi template, punta a un head strutturato così: un unico foglio di stile piccolo e ripulito, e tutti gli script differiti. In questo modo il first paint attenderà soltanto quell'unico file.

<link rel="stylesheet" href="/css/main.min.css">
<script src="/js/jquery.min.js" defer></script>
<script src="/js/gallery.min.js" defer></script>

La procedura dettagliata si trova più in basso, a partire da Riduci e combina il CSS.

WordPress

I file sotto /wp-content/plugins/ appartengono a un plugin, /wp-content/themes/ al tema e /wp-includes/ a WordPress stesso.

Se non scrivi codice, usa un plugin di ottimizzazione con queste impostazioni:

• Attiva il differimento degli script: Load JavaScript deferred in WP Rocket, Defer JavaScript in Perfmatters, Load JS Deferred in LiteSpeed Cache. Uno script con defer non blocca più il first paint. Con jQuery serve cautela, vedi sotto.
• Lascia disattivati Load CSS Asynchronously e il critical CSS, a prescindere da cosa dica il vecchio consiglio di WordPress sotto questo insight a proposito dei plugin che inseriscono "inline critical assets". Il critical CSS funziona, ma il resto del CSS arriva dopo il first paint, quindi la pagina applica gli stili due volte e spesso subisce layout shift. I costi aggiuntivi dell'inlining sono spiegati in Riduci e combina il CSS.
• Lascia disattivato Remove Unused CSS (Generate UCSS in LiteSpeed Cache). Genera un CSS separato per ogni URL (WP Rocket lo inserisce inline nell'HTML) e mantiene solo le regole che trova nella pagina durante il caricamento, col rischio che un elemento modificato in seguito da uno script (un menu aperto, uno slider) perda i propri stili. WP Rocket ha un'intera guida dedicata ai problemi di visualizzazione che ne derivano. Il gioco non vale la candela: riduci e combina i fogli di stile manualmente. Richiede più lavoro, ma ripaga lo sforzo.

Molti plugin caricano il proprio CSS su ogni pagina, incluse quelle in cui non fanno nulla: Contact Form 7 su pagine senza form, WooCommerce fuori dallo shop. Ogni foglio di stile stampato da WordPress ha un id come contact-form-7-css: la parte prima di -css è l'handle da usare per rimuoverlo dove non serve:

add_action( 'wp_enqueue_scripts', function () {
  if ( ! is_page( 'contact' ) ) {
    wp_dequeue_style( 'contact-form-7' );
  }
}, 20 );

WooCommerce dispone di un proprio filtro per i suoi tre fogli di stile, woocommerce_enqueue_styles. Per i tuoi script, da WordPress 6.3 in poi puoi aggiungere defer:

wp_enqueue_script( 'acme-gallery', get_stylesheet_directory_uri() . '/js/gallery.min.js', array( 'jquery' ), '2.3.0', array( 'strategy' => 'defer' ) );

WordPress rimuove automaticamente quell'attributo defer, senza alcun avviso, se uno script che dipende dal tuo è ancora bloccante, oppure se viene aggiunto uno script inline dopo di esso. Controlla il tag script nel sorgente della pagina.

Imposta defer su jQuery solo con uno strumento che gestisca anche le chiamate inline jQuery(...). WordPress registra jQuery senza defer, quindi blocca l'head non appena un elemento dipende da esso; aggiungere defer manualmente rompe ogni chiamata inline jQuery(...) eseguita prima dello script. Load JavaScript deferred di WP Rocket applica defer a jQuery e incapsula quelle chiamate inline. Defer JavaScript di Perfmatters esclude jQuery finché non attivi Include jQuery; quando lo fai, naviga nella pagina (menu, galleria, carrello) per verificare che nulla si sia rotto.

Un child theme il cui style.css inizia con @import url("../storefront/style.css") crea una catena di @import. Rimuovi quella riga e carica il foglio di stile genitore con wp_enqueue_style.

Shopify

Le app aggiungono i propri file tramite app embed (Negozio online, Modifica tema, App embed). Il file di script di un embed viene caricato con async (a meno che il codice Liquid non generi un proprio tag script), mentre il foglio di stile è bloccante. Disattiva gli embed inutilizzati e, dopo aver disinstallato un'app, cerca in theme.liquid e negli snippet il codice residuo che ha lasciato.

I temi caricano il CSS con il filtro stylesheet_tag in theme.liquid, che genera un link bloccante. Per l'unico foglio di stile di base va bene. Il filtro script_tag genera invece uno script senza defer, quindi scrivi il tag a mano:

<!-- blocks the first paint -->
{{ 'gallery.js' | asset_url | script_tag }}

<!-- doesn't -->
<script src="{{ 'gallery.js' | asset_url }}" defer></script>

Shopify invia già i 103 Early Hints per un massimo di 10 file render-blocking nell'head, quindi quei file partono comunque in anticipo; ciò che puoi ancora controllare è quanti sono e quanto pesano. Aspettati che il foglio di stile dell'accelerated checkout rimanga nella lista (vedi sotto).

Next.js

Nell'App Router ogni import CSS diventa un link a un foglio di stile in cima all'head, e React non esegue il paint finché non è stato caricato. Next.js li unisce in pochi chunk, quindi la soluzione è ridurre il CSS. Sposta il CSS usato solo da alcune route fuori dal CSS globale e inseriscilo nei CSS Modules: il CSS globale importato nel root layout finisce in ogni route, un CSS Module solo nelle route che lo importano. Maggiori dettagli su come Next.js genera i propri file CSS.

Next.js carica i propri script con async o defer. Uno script bloccante su un sito Next.js è solitamente uno script aggiunto manualmente al layout. Caricalo con next/script, che per impostazione predefinita lo carica solo quando Next.js ha iniziato l'idratazione della pagina:

import Script from 'next/script'

<Script src="https://example.com/widget.js" strategy="afterInteractive" />

Google Fonts e altri domini

Il link a Google Fonts è un foglio di stile bloccante su fonts.googleapis.com, e i file dei font provengono da un secondo dominio, fonts.gstatic.com. Lighthouse ha assegnato a quel file da 0,5 kB la Duration più lunga perché conteggia la nuova connessione. Ospita i font in locale e inserisci le regole @font-face nel tuo foglio di stile: la richiesta ed entrambe le connessioni scompariranno. Su Next.js, next/font lo fa già in automatico.

Strumenti di consenso, A/B test e altri file da non toccare

• Uno strumento di consenso con blocco automatico (Cookiebot, OtAutoBlock di OneTrust, l'autoblocker di Usercentrics): deve essere eseguito prima di qualsiasi altro script per poterlo bloccare, quindi è sincrono per progettazione. L'alternativa è la modalità manuale, in cui contrassegni manualmente ogni script dei cookie. Se valga la pena farlo è prima di tutto una questione legale. Un preconnect al dominio dello strumento serve almeno ad avviare la connessione in anticipo.
• Uno snippet di A/B test (Optimizely, AB Tasty, Convert): è sincrono di proposito, affinché i visitatori non vedano un lampo del contenuto originale prima della variante. Rimuovilo quando non ci sono test attivi.
• Il content_for_header di Shopify: ogni tema ne ha bisogno e non è possibile modificarlo. In tutti e cinque i negozi esaminati per questo articolo ha aggiunto un foglio di stile bloccante per l'accelerated checkout, accelerated-checkout-backwards-compat.css. Lascialo stare.

Riduci e combina il CSS

Limita il CSS render-blocking a pochi fogli di stile, ciascuno sotto i 15 kB circa (compresso). 15 kB corrispondono all'incirca a ciò che una nuova connessione trasferisce nel suo primo round trip.

Sei fogli di stile render-blocking su Slow 4G nel pannello Network di DevTools. Il verde è l'attesa per il primo byte, identica per ogni file. Il blu è il download, che cresce con la dimensione del file.

• Combina i file minuscoli aggiunti dal tema e dai plugin. Ogni foglio di stile attende un round trip completo prima che arrivi il primo byte: circa 0,6 s su Slow 4G, indipendentemente dalle sue dimensioni. Un file da 0,3 kB paga l'intera attesa per quasi nulla.
• Riduci o dividi i file grandi. Dopo la stessa attesa, il file da 14 kB è arrivato 0,4 s dopo. Il file da 60 kB ha richiesto un altro secondo per il download, e la pagina è rimasta bianca finché non è arrivato.
• Rimuovi le regole non utilizzate dalla pagina. La scheda Coverage in DevTools mostra per ciascun file quanto CSS la pagina non utilizzi mai. Nel sito mediano si tratta dell'89% (State of CWV, dati di copertura di Chrome sulla home page).
• Non inserire tutto il CSS in un unico file enorme. Tutto il CSS non ripulito, racchiuso in un unico file da 68 kB, ha eseguito il paint più tardi rispetto ai nove file separati. Il file di grandi dimensioni ha condiviso la larghezza di banda con gli script differiti e la hero image, mentre con nove file le richieste render-blocking ne hanno ottenuta la maggior parte.
• Non fare inlining del CSS. Il CSS inline finisce nell'HTML, e l'HTML è il primo file di cui il browser ha bisogno: tutto il resto lo attende. Fare inlining rende quindi più pesante e più lento proprio l'unico file atteso da tutto il resto. Aspetto ancor più importante: il browser di solito non può memorizzare l'HTML in cache, quindi ogni visualizzazione di pagina scarica nuovamente quel CSS, mentre un foglio di stile separato viene memorizzato in cache dopo la prima pagina. Tra i siti con un TTFB inferiore a 900 ms e da una a cinque richieste bloccanti, il 95,9% di quelli senza CSS inline ha un buon FCP, contro il 90,8% di quelli che inseriscono inline più di 300 kB (State of CWV).
• Non separare "il resto" del CSS per caricarlo dopo. Il vecchio trucco con media="print" funziona solo per il CSS che non compare mai nella prima schermata, cosa che raramente si può prevedere per ogni pagina e su ogni dimensione di schermo: se sbagli la stima, la pagina mostrerà inizialmente contenuti non formattati.

Sostituisci ogni @import

Assegna a ciascun file importato un link dedicato nell'HTML, oppure uniscilo al file genitore. Rimuovere l'@import sulla pagina prodotto ha anticipato il first paint di 137 ms una volta differiti gli script. Con gli script ancora bloccanti il risparmio è stato di 33 ms: jQuery è arrivato all'incirca nello stesso momento del foglio di stile importato, quindi il paint ha comunque atteso jQuery.

Differisci gli script

Aggiungi defer a ogni script nell'head non necessario per il first paint. Gli script module sono già differiti di default. Anche async rimuove uno script dall'elenco, ma può comunque essere eseguito prima del first paint e bloccare il main thread; per questo defer rappresenta la scelta predefinita migliore. Oggi gli script costituiscono la parte minore di questo insight: differire entrambi gli script ha fatto guadagnare 24 ms, perché il CSS è terminato comunque più tardi. Approfondimenti in async vs defer, JavaScript nell'head vs nel footer e 14 metodi per differire JavaScript.

Anticipa il foglio di stile principale con 103 Early Hints

Con i 103 Early Hints il server indica al browser quali file recuperare mentre sta ancora generando l'HTML. Invia come hint il foglio di stile principale:

HTTP/2 103
link: </css/main.min.css>; rel=preload; as=style

È vantaggioso quando il server impiega tempo per generare la pagina. Il foglio di stile viene scaricato in quell'intervallo, quindi il guadagno massimo corrisponde al think time del server; una pagina servita dalla cache di una CDN ne trae ben poco beneficio. Cloudflare offre un'opzione apposita (Speed, Settings, Content Optimization) e genera gli hint dagli header Link inviati dal server. Apache 2.4.58 e versioni successive supportano H2EarlyHint.

Controlla il LCP successivamente. Con il CSS anticipato, anche i font dichiarati al suo interno partono in anticipo: sulla pagina prodotto il font da 156 kB di Font Awesome ha sottratto larghezza di banda alla foto del prodotto, ritardando il LCP. Lighthouse mantiene comunque il file con hint nel proprio elenco, indicando 0,0 KiB. Maggiori dettagli su 103 Early Hints e sul perché un semplice preload di un foglio di stile già collegato non serva a nulla.

Evita fetchpriority="low" sui fogli di stile

Un consiglio diffuso suggerisce di assegnare fetchpriority="low" al CSS non necessario per la prima schermata. È un anti-pattern. Nell'head, Chrome abbassa quel foglio di stile di un solo livello, da highest a high priority, e continua ad attenderlo prima del first paint. Lighthouse stabilisce cosa sia bloccante in base alla priorità nella sua simulazione, quindi tratta il file come se non ci fosse: niente Duration e un FCP simulato più rapido.

L'ho impostato su quattro fogli di stile. Con il throttling simulato Lighthouse ha abbassato il FCP da 2,03 s a 1,60 s e alzato il punteggio da 96 a 97. In Chrome il first paint è passato da 2.122 ms a 2.114 ms: i visitatori aspettano esattamente quanto prima.

Nel momento indicato da Lighthouse come FCP, Chrome mostra ancora una schermata bianca.

Come verificare che il fix abbia funzionato?

Esegui nuovamente Lighthouse su mobile. Con il fix il punteggio è passato da 96 a 100 e il FCP simulato da 2,0 s a 1,1 s; l'insight è passato da rosso con dodici file ad arancione con uno solo: il foglio di stile da 6,6 kB.

Lighthouse 13.5.0, mobile, throttling simulato.

Esegui il test tre volte e prendi il valore mediano: sulla stessa pagina il FCP simulato variava di 1,5 s tra una scansione e l'altra.

CoreDash mostra il FCP e il render delay di LCP a partire dalle visite successive. CrUX e Search Console mostrano gli ultimi 28 giorni, quindi due settimane dopo il fix la metà di ciò che mostrano riguarda ancora il vecchio sito.

Vuoi sapere se è il CSS bloccante a mantenere in rosso il tuo FCP o LCP su mobile? In una Core Web Vitals power hour analizziamo insieme i tuoi field data e il trace della pagina, e te ne andrai con l'elenco esatto dei file da ridurre, combinare o differire.