Les scripts tiers tuent-ils vraiment vos Core Web Vitals ?

Pourquoi Google pointe-t-il spécifiquement les scripts tiers ?

Les scripts tiers (analytics, tracking publicitaire, chatbots, widgets sociaux) représentent souvent 50 à 70 % du poids JavaScript total d'une page. Ils s'exécutent dans le thread principal du navigateur, bloquant le rendu et retardant l'interactivité. C'est exactement ce que mesure le Time to Interactive (TTI), métrique qui influence directement le First Input Delay et désormais l'Interaction to Next Paint.

Martin Splitt ne fait pas dans la dentelle : il affirme que placer ces scripts en bas du HTML et les différer réduit les interruptions du TTI. Concrètement, un script chargé en haut de page stoppe l'analyse du DOM jusqu'à son exécution complète. En le repoussant en fin de fichier avec defer, le navigateur parse le HTML, construit le DOM, puis exécute le script — dans l'ordre de déclaration.

Que signifie exactement l'attribut 'defer' ?

L'attribut defer ordonne au navigateur de télécharger le script en parallèle de l'analyse HTML, mais de ne l'exécuter qu'après le parsing complet du document. Il diffère de async, qui exécute le script dès qu'il est téléchargé, sans garantir l'ordre ni attendre la fin du DOM.

Pour un SEO praticien, la nuance est critique. Un script Google Tag Manager chargé avec async peut s'exécuter avant que vos dataLayer pushes soient prêts, générant des événements manquants. Avec defer, l'ordre d'exécution reste prévisible — mais le délai d'exécution augmente, ce qui peut poser problème pour des outils temps réel.

Cette recommandation s'applique-t-elle à tous les scripts tiers ?

Non, et c'est là que le bât blesse. Google ne distingue pas entre un script critique (par exemple un système d'A/B testing qui doit s'exécuter avant le rendu pour éviter le flash de contenu) et un tracker publicitaire facultatif. Différer un script de personnalisation ou un widget de chat peut casser l'expérience utilisateur si celui-ci apparaît avec 2 secondes de retard.

La déclaration de Splitt reste générique. Elle suppose que tous les scripts tiers sont non critiques, ce qui est rarement vrai sur des sites e-commerce ou SaaS. Un expert SEO doit donc auditer chaque script individuellement, identifier les dépendances, et décider au cas par cas de la stratégie de chargement.

• defer garantit l'ordre d'exécution et exécute après le parsing HTML complet
• async exécute dès que le script est téléchargé, sans garantir l'ordre ni attendre le DOM
• Placer les scripts en bas du HTML réduit le blocage du rendu, mais ne suffit pas sans defer/async
• Tous les scripts tiers ne peuvent pas être différés sans risquer de casser des fonctionnalités critiques
• L'impact sur le TTI et l'INP dépend du nombre, du poids et du temps d'exécution des scripts tiers

Cette directive est-elle cohérente avec les observations terrain ?

Oui, mais avec une grosse réserve. Sur des sites analysés avec WebPageTest et Lighthouse, différer les scripts tiers améliore effectivement le TTI de 20 à 40 % en moyenne — à condition que ces scripts ne soient pas critiques pour le rendu initial. Le gain est particulièrement visible sur des pages surchargées de trackers publicitaires (Criteo, Taboola, pixels Facebook).

Mais voilà le hic : Google ne dit rien sur les scripts auto-hébergés vs. externes. Un script chargé depuis un CDN tiers (maps.googleapis.com, connect.facebook.net) subit une latence DNS et TLS supplémentaire. Le placer en bas du HTML avec defer aide, mais le coût réseau reste incompressible. Dans certains cas, héberger le script sur son propre domaine avec un cache agressif apporte plus de gains qu'un simple defer. [À vérifier] sur vos propres données PageSpeed Insights.

Quelles nuances manquent à cette déclaration ?

Splitt omet de parler du resource hints (preconnect, dns-prefetch, preload). Si vous différez un script tiers, vous perdez le bénéfice d'un chargement précoce — mais rien ne vous empêche d'utiliser <link rel="preconnect" href="https://www.googletagmanager.com"> pour préparer la connexion DNS et TLS pendant que le DOM se construit. Combiné à defer, ça réduit la latence d'exécution.

Il ne mentionne pas non plus le script type="module" avec defer implicite. Les modules ES6 sont automatiquement différés, ce qui les rend idéaux pour du code tiers moderne. Si votre stack le permet, migrer vers des modules plutôt que des scripts legacy peut simplifier la gestion du chargement. Mais attention : IE11 ne les supporte pas, donc à évaluer selon votre audience.

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

Trois scénarios critiques. Premier cas : les scripts anti-flicker pour l'A/B testing. Google Optimize, VWO, AB Tasty doivent s'exécuter avant le rendu pour masquer le contenu original. Les différer provoque un flash de contenu non optimisé, ruinant l'expérience. Ici, on charge en bloquant, en haut du head, avec un timeout de 500 ms max.

Deuxième cas : les scripts de personnalisation temps réel (recommandations produits, widgets de prix dynamiques). Si l'utilisateur voit d'abord un contenu générique puis un contenu personnalisé 2 secondes après, le Cumulative Layout Shift explose. Là encore, différer est contre-productif. Troisième cas : les scripts qui modifient le DOM avant le rendu initial (polyfills critiques, CSS-in-JS). Les exécuter après le parsing génère du reflow et dégrade les performances au lieu de les améliorer.

Que faut-il faire concrètement pour appliquer cette directive ?

Première étape : auditer tous les scripts tiers de votre site. Ouvrez Chrome DevTools, onglet Coverage, et rechargez la page. Vous verrez le poids exact de chaque script et le pourcentage de code réellement exécuté. Tout script avec moins de 50 % de couverture est un candidat prioritaire pour le defer ou le chargement différé.

Ensuite, classez vos scripts en trois catégories : critiques (doivent s'exécuter avant le rendu), importants (nécessaires mais peuvent attendre le DOM), et secondaires (analytics, publicité). Les critiques restent en bloquant dans le head. Les importants passent en defer en bas du body. Les secondaires sont chargés via JavaScript après l'événement window.load ou au scroll, selon le contexte.

Quelles erreurs éviter lors de la mise en œuvre ?

Erreur classique : ajouter defer à un script inline. L'attribut defer ne fonctionne que sur les scripts externes avec un attribut src. Un script inline s'exécute toujours immédiatement, peu importe où vous le placez. Si vous devez initialiser des variables globales, faites-le dans un script externe différé ou utilisez un module.

Autre piège : mélanger defer et async sur des scripts qui dépendent les uns des autres. Si le script B nécessite une fonction déclarée dans le script A, et que A est en async tandis que B est en defer, vous risquez une race condition. Gardez tous les scripts interdépendants en defer, dans l'ordre de déclaration, ou regroupez-les en un seul bundle.

Comment vérifier que l'optimisation fonctionne vraiment ?

Utilisez WebPageTest avec un profil mobile 3G simulé. Comparez le TTI avant et après l'ajout de defer. Si le gain est inférieur à 10 %, vos scripts tiers ne sont probablement pas le goulot d'étranglement — cherchez ailleurs (images non optimisées, render-blocking CSS, long tasks JavaScript).

Surveillez aussi le Interaction to Next Paint (INP) dans la Search Console et dans Google Analytics 4 via les événements web-vitals. Un INP qui se dégrade après avoir différé des scripts signale souvent qu'un script critique pour l'interactivité a été repoussé trop tard. Dans ce cas, revenez en arrière ou chargez-le de manière conditionnelle.

• Auditer tous les scripts tiers avec Chrome DevTools Coverage
• Ajouter defer aux scripts non critiques chargés depuis un src externe
• Placer les scripts différés en bas du body, juste avant la fermeture </body>
• Utiliser preconnect pour les domaines tiers afin de réduire la latence DNS/TLS
• Tester en staging avec WebPageTest et RUM avant déploiement production
• Surveiller l'INP et le TTI dans la Search Console après mise en ligne