defer e async cambiano quando uno script esterno <script> scarica ed esegue rispetto al parsing dell'HTML. Entrambi permettono lo scaricamento dello script in parallelo senza bloccare il parser — la differenza è il tempismo dell'esecuzione.
Normal: parse──stop──[download+exec]──parse──────── (slowest)
async: parse──────────────────exec──parse──────── (runs whenever it arrives)
defer: parse───────────────────────────parse──exec (after parsing, before DOMContentLoaded)
defer — per script che toccano il DOM o dipendono l'uno dall'altro/dall'ordine (il codice della tua app). Vengono eseguiti dopo che il DOM esiste, in sequenza, poco prima di DOMContentLoaded.async — per script indipendenti di terze parti che non dipendono dal DOM o da altri script (analytics, ads). L'ordine non importa, eseguili il prima possibile.<script src="analytics.js" async></script> <!-- independent → async -->
<script src="app.js" defer></script> <!-- app logic, ordered → defer -->
Nota: entrambi si applicano solo a script esterni (src); vengono ignorati su script inline. I moduli ES (type="module") sono differiti per impostazione predefinita.
Usare defer/async impedisce agli script di bloccare il parsing dell'HTML, il che migliora direttamente le prestazioni di caricamento e il First Contentful Paint.
Scegliere quello giusto (defer per codice app ordinato dipendente dal DOM, async per script di terze parti fire-and-forget) evita sia i caricamenti lenti che i bug di dipendenza dell'ordine.
async | defer |
|---|
| Scaricamento | parallelo | parallelo |
| Esecuzione | appena scaricato | dopo il parsing completo dell'HTML |
| Ordine preservato? | No (chi finisce prima) | Sì (ordine del documento) |
| Blocca il parser? | solo brevemente durante l'exec | mai |