Defer vs Async JavaScript e come questo influisce sui Core Web Vitals
Scopri quando rendere async il JavaScript e quando usare defer per ottenere i migliori risultati sui Core Web Vitals
Defer vs Async JavaScript e come questo influisce sui Core Web Vitals
Ogni volta che analizzo i Core Web Vitals di un cliente, scopro spesso che c'è poca distinzione su una pagina tra JavaScript che blocca il parser (sync), asincrono o differito. È un peccato perché script diversi hanno tempistiche ottimali diverse.
Ultima revisione a cura di Arjen Karel a marzo 2026
Table of Contents!
- Defer vs Async JavaScript e come questo influisce sui Core Web Vitals
- In breve
- 1. JavaScript sincrono (sync)
- 2. JavaScript asincrono (async)
- 3. JavaScript differito (defer)
- 4. Script di tipo modulo
- Tabella di confronto
- Domande comuni
- Come async e defer influiscono sui Core Web Vitals
- Fare un passo avanti: caricare gli script su richiesta
Secondo il Web Almanac 2025, solo il 15% delle pagine mobili supera l'audit delle risorse che bloccano il rendering. La pagina mediana carica 22 script per un totale di oltre 630 KB, con 251 KB di quel JavaScript che rimangono completamente inutilizzati. La maggior parte dei siti carica troppo JavaScript e lo fa nel momento sbagliato.
In breve
Il JavaScript "normale" nell'head della pagina impedisce al browser di analizzare l'HTML finché non viene scaricato ed eseguito. Gli script async vengono scaricati in background ma eseguiti non appena sono pronti, il che può comunque interrompere l'analisi (parsing). Gli script defer vengono scaricati in background e attendono il completamento dell'analisi prima di essere eseguiti, in ordine di documento.
Usa defer per tutto ciò che tocca il DOM. Usa async per gli script che sono completamente indipendenti (analytics, pixel di tracciamento). Non usare nessuno dei due (sync) solo se lo script deve essere eseguito prima del rendering della pagina. Nel dubbio, usa defer.
1. JavaScript sincrono (sync)
Per impostazione predefinita, 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. Questo significa che nessun pixel viene dipinto finché non sono completati tutti gli script sync. Per gli script grandi o lenti, questo crea un ritardo visibile nel First Contentful Paint.
<!DOCTYPE html> <html> <head> <title>Sync JavaScript Example</title> <script src="script1.js"></script> <script src="script2.js"></script> </head> <body> <!-- Page content here --> </body> </html>
Il browser deve scaricare ed eseguire script1.js prima ancora di iniziare con script2.js. Nel frattempo, non viene renderizzato nulla. Nel 2025 la pagina mobile mediana ha già un Total Blocking Time di quasi 2 secondi. Gli script sincroni nell'head peggiorano ulteriormente la situazione.
2. JavaScript asincrono (async)
L'aggiunta dell'attributo async indica al browser di scaricare lo script in background mentre continua ad analizzare l'HTML. Lo script viene eseguito non appena termina il download, indipendentemente da dove si trova il parser in quel momento. L'analisi si interrompe solo durante l'esecuzione.
<!DOCTYPE html> <html> <head> <title>Async JavaScript Example</title> <script src="script1.js" async></script> <script src="script2.js" async></script> </head> <body> <!-- Page content here --> </body> </html>
Gli script async non garantiscono l'ordine di esecuzione. Qualunque script finisca di scaricarsi per primo, viene eseguito per primo. Se script2.js dipende da script1.js, async romperà le cose 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 priorità di rete bassa per impostazione predefinita. Ciò significa che il browser potrebbe iniziare a scaricarli più tardi del previsto. Se hai bisogno che uno script async si carichi rapidamente (senza bloccare l'analisi), aggiungi fetchpriority="high".
3. JavaScript differito (defer)
Anche l'attributo defer scarica lo script in background, ma l'esecuzione viene posticipata finché il documento HTML non è completamente analizzato. Gli script defer vengono eseguiti nell'ordine del documento, appena prima che venga attivato l'evento DOMContentLoaded.
<!DOCTYPE html> <html> <head> <title>Defer JavaScript Example</title> <script src="script1.js" defer></script> <script src="script2.js" defer></script> </head> <body> <!-- Page content here --> </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 viene mantenuto e il first paint non viene bloccato. The Telegraph ha differito tutti i suoi script e ha migliorato il tempo di caricamento degli annunci di 4 secondi.
4. Script di tipo modulo
Se utilizzi i moduli ES (<script type="module">), ottieni automaticamente il comportamento defer. Gli script di tipo modulo si scaricano in background, vengono eseguiti dopo l'analisi e mantengono l'ordine. Aggiungere esplicitamente defer non ha alcun effetto perché è già l'impostazione predefinita.
Puoi aggiungere async a uno script di tipo modulo se vuoi che venga eseguito non appena il suo grafico delle dipendenze si risolve, invece di aspettare che l'analisi sia completa.
Tabella di confronto
| Attributo | Download | Esecuzione | Blocca il parsing? | Ordine mantenuto? |
|---|---|---|---|---|
nessuno (sync) |
Blocca il parsing durante il download | Immediatamente dopo il download | Sì (download + esecuzione) | Sì |
async |
In background | Non appena il download è completato | Solo durante l'esecuzione | No |
defer |
In background | Dopo l'analisi HTML, prima di DOMContentLoaded | No | Sì |
type="module" |
In background | Dopo l'analisi HTML (come defer) | No | Sì |
Domande comuni
Cosa succede se utilizzo sia async che defer sullo stesso tag? Vince async. L'attributo defer viene ignorato del tutto. Questo pattern esisteva in passato come fallback per IE9, ma nel 2026 non c'è alcun motivo per usarli entrambi.
Async e defer funzionano sugli script inline? No. Entrambi gli attributi vengono ignorati sugli script inline classici (senza src). Funzionano solo su script esterni. L'eccezione è <script type="module">, che è differito di default anche se inline.
Defer è meglio che inserire gli script alla fine del body? Sì. Uno script deferito nell'<head> inizia il download immediatamente (in parallelo con l'analisi HTML). Uno script alla fine del body non può iniziare il download finché il parser non lo raggiunge. Defer ti offre una scoperta anticipata e un'esecuzione ritardata, che è il meglio di entrambi i mondi.
Come async e defer influiscono sui Core Web Vitals
Gli script sincroni danneggiano direttamente il FCP perché nulla viene dipinto finché non terminano. Danneggiano anche il LCP se l'elemento LCP non può essere renderizzato fino al completamento degli script.
Gli script async migliorano il FCP (il primo paint non è bloccato dal download) ma possono comunque causare problemi all'INP se vengono eseguiti durante l'interazione dell'utente e bloccano il thread principale.
Gli script defer offrono le migliori metriche di paint perché non interferiscono affatto con il rendering iniziale. Il compromesso: se la tua pagina dipende dal JavaScript per visualizzare i contenuti (app a pagina singola), defer può effettivamente ritardare il LCP perché il contenuto non appare finché lo script non viene eseguito dopo l'analisi.
Nei dati di monitoraggio di CoreDash, i siti che hanno spostato tutti gli script non critici da sync a defer hanno visto il loro FCP migliorare in media di 340ms.
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 defer e async. Anche l'Interaction to Next Paint è influenzato dagli script che vengono eseguiti in anticipo durante il caricamento della pagina. Ecco perché, ove possibile, dovresti caricare gli script su richiesta per avere un 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 del JavaScript, consulta i 16 metodi per differire il JavaScript. Se stai affrontando l'avviso di Lighthouse sulle risorse che bloccano il rendering, questa guida copre la soluzione. Puoi anche ottimizzare il caricamento con i livelli di priorità del JavaScript e scegliere il posizionamento ottimale degli script nell'head rispetto al footer.
I built CoreDash for my own audits.
Under 1KB. EU hosted. No consent banner. Now with MCP support.
Try CoreDash free
