NextJS Core Web Vitals - corriger les scripts tiers

Corriger les scripts tiers dans NextJS

Les scripts tiers sont des scripts qui ajoutent des fonctionnalités tierces à vos sites web. Souvent, ces scripts sont hébergés par un tiers, bien que cela ne soit généralement pas strictement nécessaire (vous pouvez, par exemple, auto-héberger le fichier javascript d'analytics). Les scripts tiers fournissent un large éventail de fonctionnalités utiles, rendant le web plus dynamique, interactif et interconnecté. Ces scripts peuvent être cruciaux pour la fonctionnalité ou les revenus de votre site. Mais les scripts tiers comportent également de nombreux risques qui doivent être pris en compte pour minimiser leur impact tout en apportant de la valeur.

Imaginez un instant : vous êtes l'heureux propriétaire d'un site Next.js optimisé. Vous avez optimisé tout votre code, implémenté une forme de génération statique, optimisé toutes vos images, implémenté le Critical CSS, mais votre site ne valide toujours pas les Core Web Vitals. Que se passe-t-il ?

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

Comment les scripts tiers impactent les Core Web Vitals

Les scripts tiers peuvent perturber vos Core Web Vitals de bien plus de façons que vous ne pouvez l'imaginer. Voici quelques-uns des problèmes que j'ai rencontrés sur des sites en production.

• Ralentissement du réseau. Les scripts tiers peuvent envoyer plusieurs requêtes à plusieurs serveurs, télécharger de gros fichiers non optimisés comme des images et des vidéos, ou télécharger des frameworks et des bibliothèques plusieurs fois.
• Le JavaScript tiers peut bloquer le DOM à tout moment (voire plusieurs fois au cours d'une visite), retardant le rendu des pages et utilisant trop de temps CPU, ce qui peut retarder l'interaction utilisateur et vider 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'une mise en cache HTTP mal configurée, d'un manque de compression serveur suffisante et de protocoles http lents/anciens
• Nuire à l'user experience de bien d'autres manières, comme masquer du contenu, bloquer des événements du navigateur (comme l'événement window load) ou utiliser des API obsolètes comme document.write

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

Idéalement, vous voudrez vous assurer que les scripts tiers n'impactent pas le chemin de rendu critique. Votre solution privilégiée serait d'utiliser l'attribut defer ou async. Malheureusement, en termes de timing, ce n'est pas une bonne option pour la plupart des sites Next.js. Un site Next.js dépend fortement de JavaScript pour hydrater la page.

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

Présentation du composant Next.js Script

Le composant Next.js Script, next/script, est une extension de l'élément HTML <script>. Il permet aux développeurs de définir la priorité de chargement des scripts tiers n'importe où dans leur application, en dehors de next/head, ce qui fait gagner du temps aux développeurs tout en améliorant les performances de chargement.

Pour ajouter un script tiers à votre application, importez le composant next/script :

import Script from 'next/script'

Strategy

Avec next/script, vous décidez quand charger votre script tiers en utilisant la propriété strategy :

Il existe trois stratégies de chargement différentes qui peuvent être utilisées :

• beforeInteractive : Charger un script avant que la page ne soit interactive
• afterInteractive : Charger un script immédiatement après que la page soit devenue interactive
• lazyOnload : Charger un script pendant les temps d'inactivité
• worker : Charger un script dans un web worker

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 que le JavaScript auto-paqueté ne soit exécuté.

Du point de vue des Core Web Vitals, c'est exactement le type de comportement que nous voudrions éviter ! La stratégie beforeInteractive ne devrait être utilisée que pour des 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 next.js et bloquera probablement le main thread alors que le navigateur devrait être en train de télécharger et d'exécuter les chunks next.js. Pour les Core Web Vitals, cela signifie que le First Input Delay sera probablement affecté.

Stratégie afterInteractive

Les scripts qui utilisent la stratégie afterInteractive sont injectés côté client et seront téléchargés et exécuté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 devrait être utilisée pour les scripts qui n'ont pas besoin de 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');
  `,
  }}
/>

Stratégie lazyOnload

Avec la stratégie lazyOnload, les choses deviennent enfin intéressantes ! Ma façon de penser aux scripts tiers est simple : 'ils ne devraient pas être critiques pour une page'. Si vous ne pouvez pas vivre sans 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 aient été récupérées et pendant les temps 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 le first input delay (FID)

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

Stratégie worker