JavaScript Defer vs Async 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 de Core Web Vitals

Arjen Karel - linkedin

Last update: 2026-03-02

JavaScript Defer vs Async 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'analyseur (sync), asynchrone ou différé (deferred). 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!

JavaScript Defer vs Async 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 courantes
Comment async et defer affectent les Core Web Vitals
Aller plus loin : charger des scripts à la demande

Selon le Web Almanac 2025, seulement 15 % des pages mobiles réussissent l'audit des ressources bloquant le rendu (render-blocking resources). La page médiane charge 22 scripts totalisant plus de 630 Ko, dont 251 Ko de ce JavaScript restent complètement 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 toujours interrompre l'analyse. Les scripts différés (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 ni l'un ni l'autre (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 peint tant que tous les scripts sync ne sont pas terminés. Pour les scripts volumineux ou lents, cela crée un retard visible dans le 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>

Le navigateur doit télécharger et exécuter script1.js avant même de commencer avec script2.js. Pendant ce temps, rien n'est rendu. 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 tout en continuant l'analyse du HTML. Le script s'exécute dès qu'il a fini de se télécharger, peu importe où l'analyseur se trouve à ce moment-là. L'analyse ne s'arrête que pendant l'exécution.

<!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>

Les scripts Async ne garantissent pas l'ordre d'exécution. Le script qui finit de se télécharger en premier s'exécute en premier. Si script2.js dépend de script1.js, async cassera 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 à savoir : dans Chrome, les scripts async obtiennent une priorité réseau basse (Low network priority) 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 différés s'exécutent dans l'ordre du document, juste avant que l'événement DOMContentLoaded ne se déclenche.

<!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 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 rendu (first paint) 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 les modules ES (<script type="module">), vous obtenez le comportement defer automatiquement. Les scripts de module se téléchargent en arrière-plan, s'exécutent après l'analyse, et maintiennent l'ordre. L'ajout de defer explicitement 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 la fin de l'analyse.

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 (comme defer)	Non	Oui

Questions courantes

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 entièrement ignoré. Ce modèle existait auparavant comme solution de secours (fallback) pour IE9, mais en 2026 il n'y a aucune raison d'utiliser les deux.

Async et defer fonctionnent-ils 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 lorsqu'il est inline.

Defer est-il meilleur que de mettre des scripts à la fin du body ? Oui. Un script différé dans le <head> commence à se télécharger immédiatement (en parallèle avec 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 donne 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 se peint 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 rendu 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 de l'utilisateur et bloquent le thread principal (main thread).

Les scripts defer vous donnent les meilleures métriques de peinture (paint metrics) car ils n'interfèrent pas du tout avec le rendu initial. Le compromis : si votre page dépend du JavaScript pour afficher le contenu (single-page apps), defer peut en fait retarder le LCP car le contenu n'apparaît pas tant que le script ne s'est pas exécuté 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 à defer ont vu leur FCP s'améliorer de [CD:placeholder] 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 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ée 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 les 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 avez affaire à l'avertissement de ressources bloquant le rendu de Lighthouse, ce guide couvre la solution. Vous pouvez également affiner le chargement avec les niveaux de priorité JavaScript et choisir le placement optimal des scripts dans le head vs footer.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.