JavaScript Defer vs Async e come questo influisce sui Core Web Vitals
Scopri quando applicare async al JavaScript e quando applicare defer per i migliori risultati sui Core Web Vitals
JavaScript Defer vs Async e come influisce sui Core Web Vitals
Ogni volta che controllo i Core Web Vitals di un cliente, trovo spesso che in una pagina c'è poca distinzione tra JavaScript parser-blocking (sync), asincrono o differito (deferred). È un peccato perché script diversi hanno timing ottimali diversi.
Ultima revisione di Arjen Karel nel marzo 2026
Table of Contents!
- JavaScript Defer vs Async e come influisce sui Core Web Vitals
- In breve
- 1. JavaScript sincrono (sync)
- 2. JavaScript asincrono (async)
- 3. JavaScript differito (defer)
- 4. Script di modulo (Module scripts)
- Tabella di confronto
- Domande comuni
- In che modo async e defer influenzano i Core Web Vitals
- Fare un passo avanti: caricare gli script su richiesta
Secondo il Web Almanac 2025, solo il 15% delle pagine mobile supera l'audit delle risorse che bloccano il rendering (render-blocking resources). La pagina mediana carica 22 script per un totale di oltre 630 KB, con 251 KB di questo JavaScript che rimangono completamente inutilizzati. La maggior parte dei siti carica troppo JavaScript e lo carica nel momento sbagliato.
In breve
Il JavaScript 'normale' nel head della pagina impedisce al browser di analizzare (parsing) l'HTML fino a quando non viene scaricato ed eseguito. Gli script Async vengono scaricati in background ma vengono eseguiti non appena sono pronti, il che può comunque interrompere il parsing. Gli script Deferred (differiti) vengono scaricati in background e attendono che il parsing sia completo prima di essere eseguiti, nell'ordine del documento.
Usa defer per tutto ciò che tocca il DOM. Usa async per gli script che sono completamente indipendenti (analytics, pixel di tracciamento). Non usarli (sync) solo se lo script deve essere eseguito prima del rendering della pagina. In caso di dubbio, usa defer.
1. JavaScript sincrono (sync)
Di default, gli script nell'head della pagina sono sincroni. Quando il browser incontra uno script sincrono, interrompe l'analisi dell'HTML, scarica lo script e lo esegue prima di continuare. Ciò significa che nessun pixel viene dipinto finché non sono terminati tutti gli script sync. Per gli script grandi o lenti, questo crea un ritardo visibile nel First Contentful Paint.
<!DOCTYPE html> <html> <head> <title>Esempio di JavaScript Sync</title> <script src="script1.js"></script> <script src="script2.js"></script> </head> <body> <!-- Contenuto della pagina qui --> </body> </html>
Il browser deve scaricare ed eseguire script1.js prima ancora di iniziare con script2.js. Nel frattempo, nulla viene renderizzato. La pagina mobile mediana ha già un Total Blocking Time di quasi 2 secondi nel 2025. Gli script sincroni nell'head peggiorano questa situazione.
2. JavaScript asincrono (async)
L'aggiunta dell'attributo async dice al browser di scaricare lo script in background mentre continua l'analisi dell'HTML. Lo script viene eseguito non appena finisce il download, ovunque si trovi il parser in quel momento. Il parsing si ferma solo durante l'esecuzione.
<!DOCTYPE html> <html> <head> <title>Esempio di JavaScript Async</title> <script src="script1.js" async></script> <script src="script2.js" async></script> </head> <body> <!-- Contenuto della pagina qui --> </body> </html>
Gli script Async non garantiscono l'ordine di esecuzione. Lo script che finisce di scaricarsi per primo viene eseguito per primo. Se script2.js dipende da script1.js, async causerà errori in modo imprevedibile. Usa async solo per gli script che sono completamente indipendenti l'uno dall'altro e dal DOM.
Una cosa di cui essere consapevoli: su Chrome, gli script async ottengono per impostazione predefinita una bassa priorità di rete (Low network priority). Ciò significa che il browser potrebbe iniziare a scaricarli più tardi di quanto ti aspetti. Se hai bisogno che uno script async si carichi rapidamente (senza bloccare il parsing), aggiungi fetchpriority="high".
3. JavaScript differito (defer)
L'attributo defer scarica anche lo script in background, ma l'esecuzione viene posticipata finché il documento HTML non è completamente analizzato. Gli script differiti vengono eseguiti nell'ordine del documento, appena prima che venga attivato l'evento DOMContentLoaded.
<!DOCTYPE html> <html> <head> <title>Esempio di JavaScript Defer</title> <script src="script1.js" defer></script> <script src="script2.js" defer></script> </head> <body> <!-- Contenuto della pagina qui --> </body> </html>
Defer è la scelta più sicura per la maggior parte degli script. Il DOM è completamente disponibile quando lo script viene eseguito, l'ordine di esecuzione è preservato e il primo paint (first paint) non viene bloccato. Il Telegraph ha differito tutti i suoi script e ha migliorato il tempo di caricamento degli annunci di 4 secondi.
4. Script di modulo (Module scripts)
Se utilizzi i moduli ES (<script type="module">), ottieni automaticamente il comportamento defer. Gli script di modulo vengono scaricati in background, eseguiti dopo il parsing e mantengono l'ordine. Aggiungere defer in modo esplicito non ha alcun effetto perché è già l'impostazione predefinita.
Puoi aggiungere async a uno script di modulo se vuoi che venga eseguito non appena viene risolto il suo grafico delle dipendenze, piuttosto che aspettare il completamento del parsing.
Tabella di confronto
| Attributo | Download | Esegue | Blocca il parsing? | Ordine preservato? |
|---|---|---|---|---|
nessuno (sync) |
Blocca il parsing durante il download | Immediatamente dopo il download | Sì (download + esecuzione) | Sì |
async |
In background | Non appena il download è completo | Solo durante l'esecuzione | No |
defer |
In background | Dopo il parsing HTML, prima di DOMContentLoaded | No | Sì |
type="module" |
In background | Dopo il parsing HTML (come defer) | No | Sì |
Domande comuni
Cosa succede se uso sia async che defer sullo stesso tag? Vince async. L'attributo defer viene completamente ignorato. Questo pattern esisteva in passato come fallback per IE9, ma nel 2026 non c'è motivo di usarli entrambi.
Async e defer funzionano sugli script in linea (inline)? No. Entrambi gli attributi vengono ignorati sui classici script inline (senza src). Funzionano solo su script esterni. L'eccezione è <script type="module">, che è differito per impostazione predefinita anche quando è inline.
È meglio usare defer piuttosto che mettere gli script alla fine del body? Sì. Uno script differito nell'<head> inizia a essere scaricato immediatamente (in parallelo con l'analisi dell'HTML). Uno script alla fine del body non può iniziare a essere scaricato finché il parser non lo raggiunge. Defer ti offre una scoperta anticipata e un'esecuzione successiva, che è il meglio di entrambi i mondi.
In che modo async e defer influenzano i Core Web Vitals
Gli script sincroni danneggiano direttamente il FCP perché non viene dipinto nulla finché non terminano. Danneggiano anche l'LCP se l'elemento LCP non può essere renderizzato finché non vengono completati gli script.
Gli script async migliorano l'FCP (il primo paint non è bloccato dal download) ma possono comunque causare problemi di INP se eseguiti durante l'interazione dell'utente e bloccano il thread principale (main thread).
Gli script defer offrono le migliori metriche di painting perché non interferiscono in alcun modo con il rendering iniziale. Il compromesso: se la tua pagina dipende da JavaScript per visualizzare i contenuti (single-page app), il defer può in realtà ritardare l'LCP perché il contenuto non appare finché non viene eseguito lo script dopo il parsing.
Nei dati di monitoraggio di CoreDash, i siti che hanno spostato tutti gli script non critici da sync a defer hanno visto migliorare il loro FCP in media di [CD:placeholder] ms.
Fare un passo avanti: caricare gli script su richiesta
Async e defer possono velocizzare una pagina non bloccando il parser, ma è importante notare che differire gli script non risolverà tutti i tuoi problemi. Ad esempio, l'elemento largest contentful paint è vulnerabile alla competizione per rete e CPU causata da script differiti e async. Anche l'interaction to next paint è influenzata dagli script che vengono eseguiti all'inizio del caricamento della pagina. Ecco perché, quando possibile, dovresti caricare gli script su richiesta (on demand) per avere maggiore controllo sul loro impatto sulle prestazioni della pagina. Leggi come carichiamo gli script su richiesta.
Per una panoramica completa di tutte le strategie di caricamento di JavaScript, vedi 16 metodi per differire il JavaScript. Se hai a che fare con l'avviso sulle risorse che bloccano il rendering di Lighthouse, quella guida copre la soluzione. Puoi anche ottimizzare il caricamento con i livelli di priorità del JavaScript e scegliere il posizionamento ottimale dello script nel head rispetto al footer.
Search Console flagged your site?
When Google flags your Core Web Vitals you need a clear diagnosis fast. I deliver a prioritized fix list within 48 hours.
Request Urgent Audit
