Risolvi l'avviso di Lighthouse 'Elimina le risorse che bloccano il rendering'
Sbarazzati delle risorse che bloccano il rendering e migliora i Core Web Vitals
'Elimina le risorse che bloccano il rendering' in breve
Quando un browser incontra CSS o JavaScript che bloccano il rendering in <head>, ferma tutto. Nessun pixel viene disegnato finché quelle risorse non terminano il download e l'esecuzione. Questo è ciò che l'avviso 'Elimina le risorse che bloccano il rendering' di Lighthouse ti sta dicendo: qualcosa in <head> sta ritardando il primo paint.
Risolvi questo avviso di Lighthouse rimuovendo o differendo queste risorse che bloccano il rendering. 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 di Lighthouse 'Elimina le risorse che bloccano il rendering'?
Ultima revisione di Arjen Karel a Marzo 2026
Cosa causa l'avviso Elimina le risorse che bloccano il rendering in Lighthouse? Lighthouse segnala le pagine che hanno alternativamente:
- Un tag script nell'head che non è differito.
Gli script nell'head della pagina bloccano il rendering di default se non hanno l'attributo defer o async. - Un foglio di stile collegato che corrisponde al dispositivo (media).
Un <link rel="stylesheet"> bloccherà il rendering della pagina se non è disabilitato e corrisponde al media del browser. Per esempio <link rel="stylesheet" media="print"> non bloccherà il rendering sui dispositivi con schermo.
Troppe risorse che bloccano il rendering influiranno molto probabilmente e direttamente sul First Contentful Paint (FCP) e sul Largest Contentful Paint (LCP). Vodafone ha ridotto il JavaScript che blocca il rendering e ha visto un miglioramento del 31% nell'LCP, il che si è tradotto in un aumento delle vendite dell'8%.
Secondo il Web Performance Calendar, il 67,7% dei siti web carica almeno una terza parte che blocca il rendering. Google Fonts da solo è responsabile delle richieste che bloccano il rendering su oltre 5,8 milioni di siti.
Cosa causa le 'risorse che bloccano il rendering'?
Le risorse che bloccano il rendering sono sempre fogli di stile e JavaScript nell'head della pagina. Questo significa che possono essere aggiunti solo dal tuo CMS, dal tuo sviluppatore web o da un plugin. Quando cerchi di trovare l'origine di una risorsa che blocca il rendering, prova a guardare in questi punti:
- 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 codificati manualmente.
- 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 in una pagina, spesso carica le sue risorse in ogni pagina.
Il capitolo sul JavaScript del Web Almanac 2024 (l'edizione più recente con dati a livello di script) ha scoperto che, mentre l'87% delle pagine usa async su almeno uno script, solo il 49% dei singoli tag script in realtà ce l'ha. E solo il 13% degli script usa 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 'Elimina le risorse che bloccano il rendering'
Per risolvere il problema delle risorse che bloccano il rendering devi assicurarti che non blocchino più il rendering. La soluzione migliore è rimuovere completamente la risorsa. Script e fogli di stile vecchi e non utilizzati che si trovano ancora in <head> sono più comuni di quanto pensi. Se non puoi rimuoverli, differiscili.
Differire JavaScript
Il JavaScript può essere differito aggiungendo l'attributo defer o async al tag script.
<!-- deferred: scarica in parallelo, esegue dopo il parsing HTML, in ordine --> <script defer src="script.js"></script> <!-- async: scarica in parallelo, esegue immediatamente appena pronto (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 script che sono completamente indipendenti, come le analytics. Se usi i moduli ES (<script type="module">), ottieni il comportamento di differimento (defer) automaticamente. I moduli script non bloccano mai il rendering.
Per una guida completa su tutti i modi per controllare le tempistiche del JavaScript, vedi 16 metodi per differire JavaScript. Se vuoi capire in che modo async e defer influenzano in modo diverso i Core Web Vitals, abbiamo anche un articolo dedicato a quello.
Differire i fogli di stile
Differire i fogli di stile è più complicato rispetto a differire gli script. Quando un foglio di stile viene differito, la pagina esegue il rendering senza prima quegli stili, poi il browser li applica una volta caricati. Questo causa sfarfallio e spostamenti del layout. Ecco perché devi associare i fogli di stile differiti con CSS critico in linea.
Passo 1: Inserisci in linea il tuo CSS critico. Il CSS critico è il set minimo di stili necessario per eseguire il rendering della parte visibile della pagina. Inseriscilo direttamente in un tag <style> in <head>. Questo fornisce al browser tutto il necessario per dipingere i contenuti "above-the-fold" senza aspettare un file esterno. Estrarre il CSS critico a mano è noioso. Puoi usare il nostro Generatore di CSS Critico per automatizzare tutto questo.
<style>/* CSS critico qui */</style>
Passo 2: Carica il resto con priorità bassa. Per il foglio di stile non critico, aggiungi fetchpriority="low" per dire al browser che questa risorsa non deve competere con i contenuti critici:
<link rel="stylesheet"
href="styles.css"
fetchpriority="low">
Potresti vedere vecchi articoli che consigliano un trucco 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. Usare fetchpriority="low" è l'approccio semantico corretto: dice esattamente al browser cosa intendi senza usare trucchi.
Per i fogli di stile di cui non hai affatto bisogno nella pagina corrente (ad esempio stili usati solo in un tipo di pagina specifico), la soluzione più pulita è rimuovere il CSS inutilizzato completamente da quella pagina.
Riduci l'impatto delle risorse che bloccano il rendering
A volte non puoi eliminare le risorse che bloccano il rendering. Potresti non avere accesso al template o il tuo CMS potrebbe richiedere certi script. Ci sono alcuni modi per ridurne l'impatto:
- Minifica e comprimi i tuoi stili e script.
Risorse più piccole hanno un impatto minore sulle prestazioni di caricamento rispetto a risorse più grandi. Assicurati che la compressione gzip o brotli sia abilitata sul tuo server. - Evita di concatenare richieste critiche.
Se un foglio di stile che blocca il rendering carica un altro foglio di stile tramite@import, hai creato una catena di richieste. Il secondo file non può iniziare il download finché il primo non è completamente caricato e analizzato. Usa tag<link>separati, invece, così che entrambi vengano scaricati in parallelo. - Scarica le risorse per singola pagina.
Quando una risorsa non può essere rimossa da una pagina, non significa che sia richiesta 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 per assicurarti che le risorse critiche vengano caricate per prime e che quelle non critiche non competano per la larghezza di banda.
Nei dati di monitoraggio di CoreDash, i siti che hanno eliminato tutte le risorse che bloccano il rendering hanno visto migliorare il loro FCP in media di 420ms.
CoreDash has MCP built in.
Connect it to Claude or any AI agent. Ask it why your INP spiked last Tuesday.
See how it works
