Defer vs Async en JavaScript et comment cela affecte les Core Web Vitals
Apprenez quand utiliser async pour le JavaScript et quand utiliser defer pour obtenir les meilleurs résultats pour les Core Web Vitals
Defer vs Async en JavaScript et comment cela affecte les Core Web Vitals
Chaque fois que j'audite les Core Web Vitals d'un client, je constate souvent qu'il y a peu de distinction sur une page entre le JavaScript bloquant l'analyse (sync), asynchrone ou différé. C'est dommage car différents scripts ont des timings optimaux différents.
Dernière révision par Arjen Karel en mars 2026
Table of Contents!
- Defer vs Async en JavaScript et comment cela affecte les Core Web Vitals
- En bref
- 1. JavaScript synchrone (sync)
- 2. JavaScript asynchrone (async)
- 3. JavaScript différé (defer)
- 4. Scripts de module
- Tableau de comparaison
- Questions fréquentes
- Comment async et defer affectent les Core Web Vitals
- Aller plus loin : charger des scripts à la demande
Selon le 2025 Web Almanac, seulement 15 % des pages mobiles réussissent l'audit des ressources bloquant le rendu. La page médiane charge 22 scripts totalisant plus de 630 Ko, avec 251 Ko de ce JavaScript totalement inutilisés. La plupart des sites chargent beaucoup trop de JavaScript, et le chargent au mauvais moment.
En bref
Le JavaScript 'normal' dans le head de la page empêche le navigateur d'analyser le HTML jusqu'à ce qu'il soit téléchargé et exécuté. Les scripts Async se téléchargent en arrière-plan mais s'exécutent dès qu'ils sont prêts, ce qui peut quand même interrompre l'analyse. Les scripts Deferred se téléchargent en arrière-plan et attendent que l'analyse soit terminée avant de s'exécuter, dans l'ordre du document.
Utilisez defer pour tout ce qui touche au DOM. Utilisez async pour les scripts qui sont complètement indépendants (analytics, pixels de suivi). N'utilisez aucun des deux (sync) seulement si le script doit s'exécuter avant le rendu de la page. En cas de doute, utilisez defer.
1. JavaScript synchrone (sync)
Par défaut, les scripts dans le head de la page sont synchrones. Lorsque le navigateur rencontre un script synchrone, il arrête d'analyser le HTML, télécharge le script et l'exécute avant de continuer. Cela signifie qu'aucun pixel n'est affiché tant que tous les scripts sync ne sont pas terminés. Pour les scripts volumineux ou lents, cela crée un retard visible pour le First Contentful Paint.
<!DOCTYPE html> <html> <head> <title>Exemple JavaScript Sync</title> <script src="script1.js"></script> <script src="script2.js"></script> </head> <body> <!-- Contenu de la page ici --> </body> </html>
Le navigateur doit télécharger et exécuter script1.js avant même de commencer script2.js. Pendant ce temps, rien ne s'affiche. La page mobile médiane a déjà un Total Blocking Time de près de 2 secondes en 2025. Les scripts synchrones dans le head aggravent cela.
2. JavaScript asynchrone (async)
L'ajout de l'attribut async indique au navigateur de télécharger le script en arrière-plan pendant qu'il continue d'analyser le HTML. Le script s'exécute dès qu'il a fini d'être téléchargé, peu importe où se trouve l'analyseur à ce moment-là. L'analyse ne s'interrompt que pendant l'exécution.
<!DOCTYPE html> <html> <head> <title>Exemple JavaScript Async</title> <script src="script1.js" async></script> <script src="script2.js" async></script> </head> <body> <!-- Contenu de la page ici --> </body> </html>
Les scripts Async ne garantissent pas l'ordre d'exécution. Le premier script dont le téléchargement est terminé s'exécute en premier. Si script2.js dépend de script1.js, async va casser les choses de manière imprévisible. Utilisez async uniquement pour les scripts qui sont complètement indépendants les uns des autres et du DOM.
Une chose dont il faut être conscient : dans Chrome, les scripts async ont une priorité réseau basse par défaut. Cela signifie que le navigateur peut commencer à les télécharger plus tard que prévu. Si vous avez besoin qu'un script async se charge rapidement (sans bloquer l'analyse), ajoutez fetchpriority="high".
3. JavaScript différé (defer)
L'attribut defer télécharge également le script en arrière-plan, mais l'exécution est reportée jusqu'à ce que le document HTML soit entièrement analysé. Les scripts Deferred s'exécutent dans l'ordre du document, juste avant que l'événement DOMContentLoaded ne se déclenche.
<!DOCTYPE html> <html> <head> <title>Exemple JavaScript Defer</title> <script src="script1.js" defer></script> <script src="script2.js" defer></script> </head> <body> <!-- Contenu de la page ici --> </body> </html>
Defer est le choix le plus sûr pour la plupart des scripts. Le DOM est entièrement disponible lorsque le script s'exécute, l'ordre d'exécution est préservé, et le premier affichage n'est pas bloqué. The Telegraph a différé tous ses scripts et a amélioré le temps de chargement des publicités de 4 secondes.
4. Scripts de module
Si vous utilisez des modules ES (<script type="module">), vous obtenez automatiquement le comportement defer. Les scripts de module se téléchargent en arrière-plan, s'exécutent après l'analyse et conservent l'ordre. L'ajout explicite de defer n'a aucun effet car c'est déjà le comportement par défaut.
Vous pouvez ajouter async à un script de module si vous souhaitez qu'il s'exécute dès que son graphe de dépendances est résolu, plutôt que d'attendre que l'analyse soit terminée.
Tableau de comparaison
| Attribut | Téléchargements | S'exécute | Bloque l'analyse ? | Ordre préservé ? |
|---|---|---|---|---|
aucun (sync) |
Bloque l'analyse pendant le téléchargement | Immédiatement après le téléchargement | Oui (téléchargement + exécution) | Oui |
async |
En arrière-plan | Dès que le téléchargement est terminé | Seulement pendant l'exécution | Non |
defer |
En arrière-plan | Après l'analyse HTML, avant DOMContentLoaded | Non | Oui |
type="module" |
En arrière-plan | Après l'analyse HTML (identique à defer) | Non | Oui |
Questions fréquentes
Que se passe-t-il si j'utilise à la fois async et defer sur la même balise ? Async l'emporte. L'attribut defer est complètement ignoré. Ce modèle existait comme un fallback pour IE9, mais en 2026, il n'y a aucune raison d'utiliser les deux.
Est-ce qu'async et defer fonctionnent sur les scripts inline ? Non. Les deux attributs sont ignorés sur les scripts inline classiques (sans src). Ils ne fonctionnent que sur les scripts externes. L'exception est <script type="module">, qui est différé par défaut même en mode inline.
Defer est-il meilleur que de placer les scripts à la fin du body ? Oui. Un script différé dans le <head> commence à se télécharger immédiatement (en parallèle de l'analyse HTML). Un script à la fin du body ne peut pas commencer à se télécharger tant que l'analyseur ne l'a pas atteint. Defer vous offre une découverte plus précoce et une exécution plus tardive, ce qui est le meilleur des deux mondes.
Comment async et defer affectent les Core Web Vitals
Les scripts synchrones nuisent directement au FCP car rien ne s'affiche tant qu'ils ne sont pas terminés. Ils nuisent également au LCP si l'élément LCP ne peut pas s'afficher tant que les scripts ne sont pas terminés.
Les scripts Async améliorent le FCP (le premier affichage n'est pas bloqué par le téléchargement) mais peuvent toujours causer des problèmes d'INP s'ils s'exécutent pendant l'interaction utilisateur et bloquent le thread principal.
Les scripts Defer vous donnent les meilleures métriques d'affichage car ils n'interfèrent pas du tout avec le rendu initial. Le compromis : si votre page dépend du JavaScript pour afficher du contenu (applications monopages), defer peut en fait retarder le LCP car le contenu n'apparaît que lorsque le script s'exécute après l'analyse.
Dans les données de surveillance de CoreDash, les sites qui ont déplacé tous les scripts non critiques de sync vers defer ont vu leur FCP s'améliorer de 340 ms en moyenne.
Aller plus loin : charger des scripts à la demande
Async et defer peuvent accélérer une page en ne bloquant pas l'analyseur, mais il est important de noter que différer les scripts ne résoudra pas tous vos problèmes. Par exemple, l'élément du Largest Contentful Paint est vulnérable à la concurrence réseau et CPU causée par les scripts différés et async. L'Interaction to Next Paint est également affecté par les scripts qui s'exécutent tôt pendant le chargement de la page. C'est pourquoi, dans la mesure du possible, vous devriez charger des scripts à la demande pour avoir plus de contrôle sur leur impact sur les performances de la page. Lisez comment nous chargeons les scripts à la demande.
Pour un aperçu complet de toutes les stratégies de chargement JavaScript, consultez 16 méthodes pour différer le JavaScript. Si vous êtes confronté à l'avertissement de Lighthouse concernant les ressources bloquant le rendu, ce guide couvre la solution. Vous pouvez également ajuster le chargement avec les niveaux de priorité JavaScript et choisir l'emplacement optimal des scripts dans le head par rapport au footer.
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
