Correggere l'avviso Lighthouse eliminate render-blocking resources
Sbarazzati delle risorse render-blocking e migliora i Core Web Vitals
'Eliminate render-blocking resources' in breve
Quando un browser incontra CSS o JavaScript render-blocking (che bloccano il rendering) nel <head>, ferma tutto. Nessun pixel viene dipinto finché quelle risorse non finiscono di essere scaricate ed eseguite. È questo che ti sta dicendo l'avviso 'Eliminate render-blocking resources' in Lighthouse: qualcosa nel tuo <head> sta ritardando il primo paint.
Risolvi questo avviso di Lighthouse rimuovendo o differendo (deferring) queste risorse render-blocking. Secondo il Web Almanac 2025, solo il 15% delle pagine mobile supera questo audit. Si tratta dell'85% del web con ritardi di rendering non necessari.
Cos'è l'avviso Lighthouse 'Eliminate render-blocking resources'?
Ultima revisione di Arjen Karel nel marzo 2026
Cosa causa l'avviso Eliminate render-blocking resources in Lighthouse? Lighthouse segnala le pagine che hanno alternativamente:
- Un tag script nel head che non è differito (deferred).
Gli script nel head della pagina sono render-blocking per impostazione predefinita se non hanno l'attributo defer o async. - Un foglio di stile (stylesheet) collegato che corrisponde ai supporti del dispositivo (device media).
Un <link rel="stylesheet"> bloccherà il rendering della pagina se non è disabilitato e corrisponde ai media del browser. Ad esempio <link rel="stylesheet" media="print"> non bloccherà il rendering sui dispositivi con schermo.
Troppe risorse render-blocking influenzeranno molto probabilmente il First Contentful Paint (FCP) e il Largest Contentful Paint (LCP) direttamente. Vodafone ha ridotto il JavaScript render-blocking e ha visto un miglioramento del 31% nell'LCP, che si è tradotto in un aumento dell'8% delle vendite.
Secondo il Web Performance Calendar, il 67,7% dei siti web carica almeno una terza parte render-blocking. Solo i Google Fonts sono responsabili di richieste render-blocking su oltre 5,8 milioni di siti.
Cosa causa 'render-blocking resources'?
Le risorse render-blocking sono sempre fogli di stile e JavaScript nel head della pagina. Ciò significa che possono essere aggiunti solo dal tuo CMS, dal tuo web developer o da un plugin. Quando cerchi di trovare l'origine di una risorsa render-blocking, prova a guardare in questi posti:
- Il template. Il template del tuo sito web è il primo posto in cui guardare. Trova il punto in cui si trova il codice <head> e cerca stili e script hardcoded.
- Il CMS. A volte il CMS stesso richiede alcuni script (ad esempio jQuery) per funzionare correttamente.
- I plugin. I plugin sono noti per iniettare stili e script nella pagina. Anche quando un plugin viene utilizzato solo su una pagina, spesso carica le sue risorse su ogni pagina.
Il capitolo JavaScript del Web Almanac 2024 (l'edizione più recente con dati a livello di script) ha rilevato che, sebbene l'87% delle pagine utilizzi async su almeno uno script, solo il 49% dei singoli tag script lo possiede effettivamente. E solo il 13% degli script utilizza defer. La maggior parte degli script sul web viene ancora caricata senza nessuno dei due attributi, il che significa che bloccano il rendering.
Come risolvere 'Eliminate render-blocking resources'
Per risolvere le risorse render-blocking devi assicurarti che non blocchino più il rendering. La soluzione migliore è rimuovere completamente la risorsa. Vecchi script e fogli di stile inutilizzati che si trovano ancora nel <head> sono più comuni di quanto pensi. Se non puoi rimuoverli, differiscili (defer).
Differire JavaScript
Il JavaScript può essere differito aggiungendo l'attributo defer o async al tag dello script.
<!-- deferred: scarica in parallelo, viene eseguito dopo il parsing HTML, in ordine --> <script defer src="script.js"></script> <!-- async: scarica in parallelo, viene eseguito immediatamente quando è pronto (in qualsiasi ordine) --> <script async src="script.js"></script>
Per la maggior parte degli script, defer è la scelta più sicura perché preserva l'ordine di esecuzione. Usa async per gli script che sono completamente indipendenti, come l'analytics. Se utilizzi moduli ES (<script type="module">), ottieni automaticamente il comportamento defer. Gli script dei moduli non bloccano mai il rendering.
Per una guida completa su tutti i modi per controllare il timing di JavaScript, vedi 16 metodi per differire JavaScript. Se vuoi capire come async e defer influenzino in modo diverso i Core Web Vitals, abbiamo un articolo dedicato anche a questo.
Differire i fogli di stile
Differire i fogli di stile è più complicato che differire gli script. Quando un foglio di stile viene differito, la pagina viene prima renderizzata senza quegli stili, quindi il browser li applica una volta caricati. Questo causa sfarfallio (flickering) e layout shift. Ecco perché è necessario associare i fogli di stile differiti al critical CSS inline.
Passaggio 1: Metti inline il tuo critical CSS. Il critical CSS è il set minimo di stili necessario per renderizzare la parte visibile della pagina. Mettilo inline direttamente in un tag <style> nel <head>. Questo fornisce al browser tutto ciò di cui ha bisogno per dipingere il contenuto above-the-fold senza dover aspettare un file esterno. Estrarre il critical CSS a mano è noioso. Puoi utilizzare il nostro Generatore di Critical CSS per automatizzare questa operazione.
<style>/* critical CSS qui */</style>
Passaggio 2: Carica il resto a bassa priorità. Per il foglio di stile non critico, aggiungi fetchpriority="low" per dire al browser che questa risorsa non dovrebbe competere con i contenuti critici:
<link rel="stylesheet"
href="styles.css"
fetchpriority="low">
Potresti vedere vecchi articoli che raccomandano un hack media="print" che passa a media="all" al caricamento. Non lo raccomando. Abusa dell'attributo media per qualcosa per cui non è stato progettato, dipende da un fragile gestore onload e, se quel gestore fallisce, i tuoi stili non verranno mai applicati. L'utilizzo di fetchpriority="low" è l'approccio corretto e semantico: dice al browser esattamente cosa intendi senza trucchi.
Per i fogli di stile di cui non hai affatto bisogno nella pagina corrente (ad esempio stili utilizzati solo su un tipo di pagina specifico), la soluzione più pulita è rimuovere completamente il CSS inutilizzato da quella pagina.
Riduci l'impatto delle risorse render-blocking
A volte non è possibile eliminare le risorse render-blocking. Potresti non avere accesso al template o il tuo CMS potrebbe richiedere determinati script. Ci sono alcuni modi per ridurne l'impatto:
- Minifica e comprimi i tuoi stili e script.
Le risorse più piccole hanno un impatto minore sulle prestazioni di caricamento rispetto alle risorse più grandi. Assicurati che la compressione gzip o brotli sia abilitata sul tuo server. - Evita di concatenare richieste critiche (chaining critical requests).
Se un foglio di stile render-blocking carica un altro foglio di stile tramite@import, hai creato una catena di richieste (request chain). Il secondo file non può iniziare il download finché il primo non è completamente caricato e analizzato. Usa invece tag<link>separati in modo che entrambi vengano scaricati in parallelo. - Scarica (Unload) le risorse per pagina.
Quando una risorsa non può essere rimossa da una pagina, non significa che sia necessaria su tutte le pagine. I plugin di WordPress tendono ad aggiungere script e stili a tutte le pagine, anche quando il plugin è attivo solo su alcune. - Dai priorità a ciò che conta.
Usa la prioritizzazione delle risorse (resource prioritization) per assicurarti che le risorse critiche vengano caricate per prime e che le risorse non critiche non competano per la larghezza di banda.
Nei dati di monitoraggio di CoreDash, i siti che hanno eliminato tutte le risorse render-blocking hanno visto migliorare il loro FCP in media di [CD:placeholder] ms.
Pinpoint the route, device, and connection that fails.
CoreDash segments every metric by route, device class, browser, and connection type. Real time data. Not the 28 day average Google gives you.
Explore Segmentation
