Corriger les scripts tiers dans Next.js pour de meilleurs Core Web Vitals

Corriger les scripts tiers dans Next.js

Les scripts tiers sont la cause la plus courante d'échecs des Core Web Vitals sur des sites Next.js par ailleurs optimisés. Vous avez tout fait correctement : optimisé les images, implémenté la génération statique, intégré le CSS critique. Mais votre Interaction to Next Paint échoue toujours. La cause est presque toujours du JavaScript tiers. Selon le Web Almanac 2025, 92 % des pages chargent au moins une ressource tierce. Les scripts représentent 24,8 % de toutes les requêtes tierces, plus que tout autre type de ressource.

Dernière révision par Arjen Karel en mars 2026

Cela peut être dû à des scripts tiers comme des publicités, des analytics, des boutons de réseaux sociaux, des widgets, des scripts de test A/B, des lecteurs vidéo, etc.

Comment les scripts tiers impactent les Core Web Vitals

Les scripts tiers peuvent perturber vos Core Web Vitals de plus de façons que vous ne pouvez probablement l'imaginer. Voici quelques-uns des problèmes que je rencontre sur des sites web en production.

• Ralentir le réseau. Les scripts tiers peuvent envoyer de multiples requêtes à de multiples serveurs, télécharger de gros fichiers non optimisés comme des images et des vidéos, télécharger des frameworks et des bibliothèques plusieurs fois.
• Le JavaScript tiers peut bloquer le DOM à tout moment (ou même plusieurs fois lors d'une visite de page), retardant la rapidité de rendu des pages et utilisant trop de temps processeur, ce qui peut retarder l'interaction de l'utilisateur et causer une décharge de la batterie.
• Les scripts tiers bloquant le rendu peuvent constituer un point de défaillance unique (SPOF).
• Les scripts tiers peuvent causer des problèmes de réseau en raison d'un cache HTTP mal configuré, d'un manque de compression serveur suffisante et de protocoles HTTP lents ou obsolètes.
• Nuire à l'user experience de bien d'autres manières, comme en masquant du contenu, en bloquant des événements du navigateur (comme l'événement window load) ou en utilisant des API obsolètes comme document.write.

Les chiffres donnent à réfléchir. L'équipe Chrome Aurora a découvert qu'un conteneur Google Tag Manager avec 18 balises augmente le Total Blocking Time de près de 20 fois. Le Web Almanac 2025 rapporte un TBT médian sur mobile de 1 916 ms, soit près de 10 fois la bonne pratique fixée à 200 ms. Les scripts tiers contribuent grandement à ce chiffre.

Corriger les scripts tiers et les Core Web Vitals dans Next.js

Idéalement, vous voulez vous assurer qu'aucun script tiers n'impacte le chemin de rendu critique. Votre premier réflexe serait d'utiliser l'attribut defer ou async. Malheureusement, d'un point de vue temporel, ce n'est pas une bonne option pour la plupart des sites Next.js. Un site Next.js s'appuie fortement sur le JavaScript pour hydrater la page.

Cela signifie que dès que les bundles Next.js ont été téléchargés, le navigateur exécutera ce JavaScript. Cela prend du temps et des ressources. Ce processus ralentira lorsque le navigateur sera trop occupé à compiler et à exécuter du JavaScript tiers.

Le composant Script de Next.js

Le composant Script de Next.js (next/script) vous donne le contrôle sur le moment où les scripts tiers se chargent par rapport au code de votre application. Au lieu de lutter contre le comportement de chargement par défaut du navigateur, vous choisissez une stratégie qui correspond à l'importance du script.

Importez-le dans n'importe quel composant :

import Script from 'next/script'

Stratégie

Avec next/script, vous décidez quand charger votre script tiers en utilisant la propriété strategy. Il existe quatre stratégies de chargement :

• beforeInteractive : Charger un script avant que la page ne soit interactive
• afterInteractive : Charger un script immédiatement après que la page devient interactive
• lazyOnload : Charger un script pendant le temps d'inactivité (idle time)
• worker : Charger un script dans un web worker (expérimental, Pages Router uniquement)

Stratégie beforeInteractive

Les scripts qui se chargent avec la stratégie beforeInteractive sont injectés dans le HTML initial depuis le serveur avec l'attribut defer activé et s'exécutent avant l'exécution du JavaScript de vos propres bundles.

D'un point de vue des Core Web Vitals, c'est exactement le type de comportement que nous souhaitons éviter ! La stratégie beforeInteractive ne devrait être utilisée que sur les scripts absolument critiques pour la page. Les scripts tiers ne sont jamais censés être critiques !

<Script
  id="bootstrap-cdn"
  src="https://cdn.jsdelivr.net/npm/bootstrap@5.1.3/dist/js/bootstrap.bundle.min.js"
  strategy="beforeInteractive"
 />

Dans ce cas, la bibliothèque JavaScript bootstrap est ajoutée au HTML généré avec l'attribut defer juste avant les bundles Next.js. Cela signifie que le navigateur va probablement récupérer et exécuter la bibliothèque bootstrap avant le bundle Next.js. Cela retardera l'hydratation de Next.js et bloquera probablement le thread principal alors que le navigateur devrait télécharger et exécuter les chunks Next.js. Pour les Core Web Vitals, cela signifie que l'Interaction to Next Paint sera probablement affectée.

Stratégie afterInteractive

Les scripts qui utilisent la stratégie afterInteractive sont injectés côté client et seront téléchargés après que Next.js ait hydraté la page.

Du point de vue des Core Web Vitals, c'est un bien meilleur endroit (mais pas encore parfait) pour injecter des scripts tiers. Cette stratégie doit être utilisée pour les scripts qui n'ont pas besoin de se charger le plus tôt possible et qui peuvent être récupérés et exécutés immédiatement après que la page soit interactive.

<Script
  strategy="afterInteractive"
  dangerouslySetInnerHTML={{
    __html: `
    (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
    j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
    'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
    })(window,document,'script','dataLayer', 'GTM-XXXXXX');
  `,
  }}
/>

Pour Google Tag Manager et Google Analytics, il existe désormais une meilleure option. Voir la section @next/third-parties ci-dessous.

Stratégie lazyOnload

Avec la stratégie lazyOnload, les choses deviennent enfin intéressantes ! Ma façon de concevoir les scripts tiers est simple : 'ils ne devraient pas être critiques pour une page'. Si vous ne pouvez pas vous passer d'un certain script tiers, vous ne devriez probablement pas dépendre d'un tiers.

Les scripts qui utilisent la stratégie lazyOnload sont chargés tardivement, après que toutes les ressources ont été récupérées et pendant les périodes d'inactivité. Cela signifie que le script tiers n'interférera pas avec les chunks Next.js et minimisera l'impact que ce script a sur l'Interaction to Next Paint (INP).

<Script
  id="some-chat-script"
  src="https://example.com/chatscript.js"
  strategy="lazyOnload"
 />

Stratégie worker

La stratégie worker est une fonctionnalité expérimentale qui utilise Partytown pour exécuter des scripts dans un web worker au lieu du thread principal. Le concept est intéressant : l'équipe Chrome Aurora a mesuré une réduction du TBT de 92 % en déplaçant GTM vers un web worker. Mais la stratégie worker ne fonctionne qu'avec le Pages Router. Elle ne prend pas en charge l'App Router. Mon conseil : tenez-vous en éloigné jusqu'à ce que le projet mûrisse ou que le DOM devienne disponible pour les web workers.

@next/third-parties : l'approche moderne

Next.js fournit désormais le package @next/third-parties avec des composants optimisés pour les services tiers les plus courants. Ces composants gèrent la stratégie de chargement en interne, vous n'avez donc pas besoin de la configurer vous-même.

Installez-le :

npm install @next/third-parties

Pour Google Tag Manager, ajoutez le composant à votre root layout :

import { GoogleTagManager } from '@next/third-parties/google'

export default function RootLayout({ children }) {
  return (
    <html>
      <GoogleTagManager gtmId="GTM-XXXXXX" />
      <body>{children}</body>
    </html>
  )
}

Pour Google Analytics :

import { GoogleAnalytics } from '@next/third-parties/google'

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        {children}
        <GoogleAnalytics gaId="G-XXXXXX" />
      </body>
    </html>
  )
}

L'équipe Chrome Aurora rapporte que 66 % des sites Next.js utilisent Google Tag Manager et 52 % utilisent Google Analytics. Si vous chargez l'un ou l'autre, utilisez les composants dédiés au lieu du composant générique Script avec dangerouslySetInnerHTML. Si vous utilisez le dataLayer de GTM, consultez également le pattern yield INP dataLayer pour empêcher les événements push de bloquer les interactions.

Quelle stratégie pour quel script ?

• GTM et GA : Utilisez les composants @next/third-parties. Ils gèrent la synchronisation en interne.
• Widgets de chat (Intercom, HubSpot, Drift) : Utilisez lazyOnload. Un widget de chat n'est jamais critique pour la première interaction.
• Tests A/B (Optimizely, VWO) : Utilisez beforeInteractive uniquement si le test affecte le contenu au-dessus de la ligne de flottaison. Sinon, utilisez afterInteractive.
• Intégrations sociales et lecteurs vidéo : Utilisez lazyOnload.
• Scripts publicitaires : Utilisez afterInteractive. Les publicités doivent se charger raisonnablement vite pour les revenus mais ne doivent pas bloquer l'hydratation.

Parmi les sites Next.js surveillés par CoreDash, ceux utilisant lazyOnload pour les scripts d'analytics montrent une amélioration médiane de l'INP de 27 ms par rapport à afterInteractive. C'est la différence entre réussir ou échouer au seuil de l'INP.

Quelle que soit la stratégie que vous choisissez, vérifiez les résultats avec le Real User Monitoring. Les scores de laboratoire vous disent ce qui pourrait arriver. Les données de terrain vous disent ce qui s'est réellement passé. Et parfois la meilleure optimisation est de supprimer les scripts dont vous n'avez pas besoin.

Pour en savoir plus sur la mesure de l'impact, consultez le guide sur la mesure des Core Web Vitals dans Next.js. Si vous avez également affaire à du CSS bloquant le rendu dans Next.js, corrigez cela en premier. Pour un aperçu plus large de la façon dont le navigateur décide quoi récupérer et quand, consultez le guide de priorisation des ressources.