Async et defer sur vos scripts : gain réel ou optimisation de façade ?

Pourquoi Google insiste-t-il autant sur le chargement asynchrone ?

Le navigateur, quand il rencontre une balise <script> classique, stoppe tout. Il télécharge le fichier JavaScript, l'exécute, puis seulement reprend le parsing HTML. Ce comportement bloque le rendu de la page : l'utilisateur voit un écran blanc plus longtemps, les Core Web Vitals (FCP, LCP) plongent, et l'expérience dégringole.

Les attributs async et defer cassent ce blocage. Avec defer, le navigateur télécharge le script en parallèle du parsing HTML, puis l'exécute seulement une fois le DOM complet. Avec async, le téléchargement est aussi parallèle, mais l'exécution se fait dès que le fichier est prêt, sans attendre la fin du parsing. La déclaration de Google vise à réduire le temps de blocage du thread principal, un critère central pour le ranking sur mobile.

Quelle différence concrète entre async et defer ?

Defer garantit un ordre d'exécution : si vous avez trois scripts avec defer, ils s'exécutent dans l'ordre d'apparition dans le HTML. C'est idéal pour des scripts qui dépendent les uns des autres (une librairie puis un plugin qui l'utilise). L'exécution se fait juste avant le déclenchement de l'événement DOMContentLoaded.

Async, lui, ne garantit aucun ordre. Le premier script téléchargé s'exécute en premier. Utilisez-le pour des scripts totalement indépendants : analytics, pixels publicitaires, widgets sociaux. Si vous avez des dépendances entre fichiers, async peut casser votre code de manière intermittente, selon les conditions réseau.

Est-ce que cette recommandation s'applique à tous les scripts ?

Non. Les scripts critiques pour le rendu initial (ceux qui modifient le DOM visible au-dessus de la ligne de flottaison, ou qui injectent du CSS critique) ne doivent pas être différés. Sinon, vous risquez un flash de contenu non stylé ou des éléments qui apparaissent en décalé.

De même, les scripts qui initialisent des composants interactifs nécessaires immédiatement (menu déroulant, carrousel en hero) posent problème avec async/defer. L'utilisateur peut cliquer sur un élément avant que le JavaScript ne soit chargé, provoquant une frustration immédiate. Google ne détaille jamais ces nuances dans ses communications officielles.

• Defer : scripts avec dépendances, exécution après parsing HTML complet, ordre garanti
• Async : scripts indépendants, exécution dès téléchargement, ordre non garanti
• Scripts critiques pour le rendu initial : à laisser en chargement bloquant ou à inliner
• Impact mesurable sur FCP, LCP, TBT (Total Blocking Time)
• Google PageSpeed Insights signale les scripts bloquants comme opportunité d'optimisation

Cette déclaration est-elle alignée avec les observations terrain ?

Oui, dans l'ensemble. Les audits que je mène montrent systématiquement un gain de 0,5 à 1,5 secondes sur le LCP après migration vers defer sur les scripts non critiques. Les sites e-commerce avec beaucoup de tracking tiers (Facebook Pixel, Google Ads, Hotjar) voient leur TBT (Total Blocking Time) chuter de 40 à 60 % en passant ces scripts en async.

Le problème, c'est que Google ne dit jamais lesquels différer. En pratique, 80 % des sites web chargent au moins un script qui casse l'interface s'il est différé. J'ai vu des menus de navigation entiers disparaître, des sliders rester figés, des pop-ups de consentement RGPD ne jamais s'afficher. [À vérifier] : Google ne fournit aucune méthodologie pour identifier les scripts critiques vs. non critiques de manière automatisée.

Quelles nuances faut-il apporter à cette recommandation ?

D'abord, l'ordre des opérations compte. Si vous mettez defer sur jQuery puis sur un plugin jQuery, ça fonctionne. Inversement, c'est la catastrophe. Avec async, même problème mais imprévisible : ça peut marcher en développement, planter en production selon la latence réseau.

Ensuite, les frameworks modernes (React, Vue, Angular) utilisent déjà du code-splitting et du lazy-loading natifs. Ajouter async/defer sur des bundles générés par Webpack ou Vite peut créer des conflits de timing. Je recommande de tester sur un environnement de staging avec des throttling réseau 3G avant de déployer en production.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Les scripts inline (code JavaScript directement dans le HTML) ne peuvent pas recevoir async ou defer. Si vous avez du code critique inline, la seule option est de le minimiser ou de le déplacer en fin de <body>.

Les modules ES6 (<script type="module">) se comportent déjà comme defer par défaut. Ajouter l'attribut defer est redondant. Si vous utilisez des modules, l'attribut async reste pertinent pour les scripts totalement indépendants.

Que faut-il faire concrètement pour implémenter async et defer ?

Commencez par un audit de vos scripts. Ouvrez Chrome DevTools, onglet Performance, enregistrez le chargement de la page. Regardez la waterfall : tous les scripts qui bloquent le main thread plus de 50 ms sont des candidats. Pour chaque script, posez-vous la question : est-ce que la page fonctionne si ce script s'exécute après le rendu initial ?

Pour les scripts de tracking (Google Analytics, Facebook Pixel, Hotjar, etc.), utilisez async sans hésiter. Pour les librairies avec dépendances (jQuery + plugins, Bootstrap JS, etc.), passez à defer en conservant l'ordre d'insertion dans le HTML. Testez ensuite sur mobile avec un throttling 3G : c'est là que les gains de LCP sont les plus visibles.

Quelles erreurs éviter lors de la migration ?

Ne mettez jamais defer ou async sur des scripts qui modifient le DOM critique au-dessus de la ligne de flottaison. J'ai vu un site e-commerce perdre 20 % de conversions en une semaine parce que le bouton "Ajouter au panier" ne fonctionnait plus : le script était différé, l'utilisateur cliquait avant l'exécution, rien ne se passait.

Évitez de mélanger async et defer sur des scripts dépendants. Si un script A doit s'exécuter avant un script B, utilisez defer sur les deux dans le bon ordre. Avec async, l'ordre est imprévisible. Méfiez-vous aussi des scripts tiers qui injectent d'autres scripts : certains pixels publicitaires chargent des dizaines de sous-ressources, et async peut créer des race conditions.

Comment vérifier que l'implémentation fonctionne correctement ?

Utilisez Google PageSpeed Insights et WebPageTest pour mesurer FCP, LCP et TBT avant/après. Un gain de 0,5 seconde sur LCP est significatif. Testez aussi manuellement : cliquez sur tous les éléments interactifs dès que la page apparaît. Si quelque chose ne réagit pas, c'est que vous avez différé un script critique.

Mettez en place un monitoring RUM (Real User Monitoring) pour capter les erreurs JavaScript en production. Des outils comme Sentry ou LogRocket vous alertent si des scripts ne se chargent pas dans le bon ordre. Enfin, vérifiez que vos Core Web Vitals dans la Search Console progressent après déploiement. Si rien ne bouge après 28 jours, c'est qu'il y a un problème ailleurs.

• Auditer les scripts avec Chrome DevTools (onglet Performance)
• Passer les scripts de tracking en async
• Passer les librairies avec dépendances en defer (dans l'ordre)
• Tester sur mobile avec throttling 3G
• Monitorer les erreurs JavaScript en production
• Mesurer FCP, LCP, TBT avant/après avec PageSpeed Insights