Guide

«Eliminare le risorse che bloccano il rendering» è l'audit più frequente di un report Lighthouse, e il meno spiegato. Nomina i file e si ferma lì. Dietro quell'unica riga si nascondono due meccanismi diversi, che richiedono correzioni diverse.

Gli script: che cosa fa davvero ogni attributo

**Uno script classico senza attributo ferma il parser.** MDN lo dice senza giri di parole: gli script senza `async`, `defer` o `type="module"` vengono *«recuperati ed eseguiti immediatamente, prima che il browser continui ad analizzare la pagina»*. Il browser sta costruendo il documento, incontra il tag e si ferma: scaricare, eseguire, poi riprendere. Tutto ciò che sta sotto aspetta.

**`defer` è la risposta nella maggior parte dei casi.** L'attributo indica che lo script *«deve essere eseguito dopo l'analisi del documento, ma prima dell'evento DOMContentLoaded»*. L'analisi prosegue senza interruzioni, e gli script differiti *«vengono eseguiti nell'ordine in cui appaiono nel documento»*: uno script che dipende da un altro lo ottiene comunque.

**`async` è quello che si usa male.** Viene recuperato *«in parallelo all'analisi e valutato non appena è disponibile»*, il che suona strettamente migliore. Quel che si omette è la frase subito dopo: *«una volta completato il download, lo script viene eseguito, il che impedisce alla pagina di essere renderizzata»*.

Async elimina dunque il blocco durante il **download**, non durante l'**esecuzione**. Uno script grande caricato con async arriva quando arriva, in mezzo all'analisi, e blocca il rendering in quel momento. E poiché l'ordine di esecuzione segue quello di arrivo, MDN avverte che non c'è *«alcuna garanzia che gli script vengano eseguiti in un ordine preciso»*, il che rompe tutto ciò che ha dipendenze.

La regola breve: **defer per i propri script, async solo per terze parti davvero indipendenti**, come un beacon di analytics che non parla con nessuno.

Il CSS blocca per un altro motivo

**Il CSS blocca per un altro motivo, e la correzione non è un attributo.** Un foglio di stile non ferma il parser HTML, ma il browser non disegnerà finché non ha il CSS che gli serve, perché disegnare prima e ristilizzare poi mostrerebbe un lampo di contenuto non stilizzato. È un blocco del rendering, non dell'analisi.

• Senza attributo: recuperato ed eseguito subito, l'analisi si ferma
• defer: esegue dopo l'analisi, nell'ordine del documento, prima di DOMContentLoaded
• async: nessun blocco al download, ma l'esecuzione blocca il rendering, e l'ordine non è garantito
• CSS: non blocca l'analisi, blocca il disegno - limitane l'ambito con media
• I tag di terze parti sono spesso la quota maggiore dell'audit

Qui la leva è l'ambito, non il momento. Un foglio che si applica a un solo contesto può portare un attributo `media`, e il browser lo recupererà senza lasciargli bloccare il primo disegno - `media="print"` è il caso noto. Resta il CSS di cui la prima schermata ha davvero bisogno, ed è quello che conviene tenere piccolo.

Dove sta il peso, e come confermarlo

**I tag di terze parti sono di solito il peso reale.** Il tuo bundle è sotto i tuoi occhi e finisce ottimizzato; il tag manager, il widget di chat e il banner di consenso arrivano come script che non hai scritto, spesso caricandone altri a loro volta. Verificare quanto costano davvero - e se ciascuno se lo merita - sposta il numero molto più che limare kilobyte dal proprio codice.

**E poi misura sul campo, non sul report.** Lighthouse ti dice che una risorsa bloccava il rendering; non ti dice se rimuoverla ha cambiato qualcosa per i tuoi visitatori. Quella differenza tra un audit di laboratorio e utenti reali è [un argomento a sé](/it/articles/dati-sul-campo-vs-dati-di-laboratorio), ed è quella che decide se il lavoro è valso la pena.