Cette page a été traduite par l'API Cloud Translation.

Package Next.js permettant de gérer les bibliothèques tierces

Houssein Djirdeh

En 2021, l'équipe Chrome Aurora a lancé le Script pour améliorer les performances de chargement des scripts tiers dans Next.js. Depuis son lancement, nous avons a développé ses fonctionnalités pour faciliter le chargement des ressources tierces pour les développeurs.

Cet article de blog offre un aperçu des nouvelles fonctionnalités que nous avons lancées, et notamment @next/third-parties bibliothèque, ainsi que les grandes lignes des futures initiatives sur notre feuille de route.

Implications des scripts tiers sur les performances

41% de toutes les requêtes tierces sur les sites Next.js sont des scripts. Retirer le like sur d'autres contenus le téléchargement et l'exécution des scripts peuvent prendre un certain temps, ce qui peut bloquer l'affichage et retarder l'interactivité de l'utilisateur. Données de Chrome Le rapport d'expérience utilisateur (CrUX) indique que les sites Next.js qui chargent davantage de sites scripts présentent une interaction avec le tableau suivant moins élevé (INP) et Largest Contentful Paint (LCP).

Graphique à barres montrant une baisse du pourcentage de Next.js atteignant de bons scores INP et LCP proportionnellement au nombre de tiers chargés — </ph> Rapport CrUX de décembre 2023 (110 823 sites)

La corrélation observée dans ce graphique n'implique pas de causalité. Toutefois, en local les tests montrent de nouvelles preuves que les scripts tiers sur les performances des pages. Par exemple, le tableau ci-dessous compare différents ateliers dans le cas d'un conteneur Google Tag Manager, soit 18 éléments sélectionnés au hasard. sont ajoutées à Taxonomy, un exemple populaire de Next.js l'application.

Graphique à barres montrant les différences entre les différentes métriques de laboratoire lorsqu'un site est chargé avec et sans Google Tag Manager — </ph> WebPageTest (Mobile 4G - Virginie États-Unis)

La documentation WebPageTest fournit des détails sur la façon dont ces délais sont mesurés. En bref, il est que toutes ces métriques d'atelier sont affectées par le conteneur Google Tag Manager. Pour Exemple : Total Blocking Time (TBT), un atelier utile qui se rapproche de l'INP, a presque doublé.

Composant de script

Lorsque nous avons lancé le composant <Script> dans Next.js, nous avons veillé à introduire via une API conviviale qui ressemble beaucoup au <script> traditionnel . Grâce à lui, les développeurs peuvent colocaliser un script tiers dans n'importe quelle dans son application, et Next.js se charge de séquencer le après le chargement des ressources critiques.

<!-- By default, script will load after page becomes interactive -->
<Script src="https://example.com/sample.js" />

<!-- Script is injected server-side and fetched before any page hydration occurs -->
<Script strategy=”beforeInteractive” src="https://example.com/sample.js" />

<!-- Script is fetched later during browser idle time -->
<Script strategy=”lazyOnload” src="https://example.com/sample.js" />

Des dizaines de milliers d'applications Next.js, y compris des sites populaires tels que Patreon, Target et Notion : utilisez le composant <Script>. Malgré son efficacité, certains développeurs ont exprimé des inquiétudes sur les points suivants choses:

Où placer le composant <Script> dans une application Next.js tout en respectant aux instructions d'installation de différents fournisseurs tiers. (expérience développeur).
Quelle est la stratégie de chargement la plus adaptée scripts tiers (expérience utilisateur).

Pour répondre à ces deux préoccupations, nous avons lancé @next/third-parties, un bibliothèque spécialisée proposant un ensemble de composants et d'utilitaires optimisés spécialement conçu pour les tiers populaires.

Expérience développeur: simplification de la gestion des bibliothèques tierces

De nombreux scripts tiers sont utilisés dans un pourcentage significatif de sites Next.js, avec Google Tag Manager est l'outil le plus utilisé, 66% des sites respectivement. @next/third-parties s'appuie sur <Script> en introduisant des wrappers de niveau supérieur conçus pour simplifier l'utilisation ces cas d'utilisation courants.

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

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

Google Analytics, un autre script tiers couramment utilisé (52% des sites Next.js). Elle dispose également d'un composant dédié.

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

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

@next/third-parties simplifie le processus de chargement de scripts couramment utilisés, mais cela étend également notre capacité à développer des fournisseurs d'énergie pour d'autres comme les intégrations. Par exemple, les intégrations Google Maps et YouTube utilisé dans 8% et 4% des sites Web Next.js, et nous avons également expédié des composants pour les rendre plus facile à charger.

import { GoogleMapsEmbed } from "@next/third-parties/google";
import { YouTubeEmbed } from "@next/third-parties/google";

export default function Page() {
  return (
    <>
      <GoogleMapsEmbed
        apiKey="XYZ"
        height={200}
        width="100%"
        mode="place"
        q="Brooklyn+Bridge,New+York,NY"
      />
      <YouTubeEmbed videoid="ogfYd705cRs" height={400} params="controls=0" />
    </>
  );
}

Expérience utilisateur: accélérer le chargement des bibliothèques tierces

Dans un monde parfait, chaque bibliothèque tierce largement adoptée serait entièrement optimisés, ce qui rend inutiles les abstractions qui améliorent leurs performances. Toutefois, en attendant que cela devienne réalité, nous pouvons essayer d'améliorer une expérience utilisateur lorsqu'elle est intégrée via des frameworks populaires comme Next.js. Nous pouvons tester différentes techniques de chargement, vérifier que les scripts sont séquencés de la bonne manière et partager nos commentaires avec des tiers pour encourager les changements en amont.

Prenons l'exemple des intégrations YouTube. Lorsque d'autres implémentations ont de bien meilleures performances que l'intégration native. Actuellement, les <YouTubeEmbed> que le composant exporté par @next/third-parties utilise lite-youtube-embed, qui, lorsqu'il s'agit d'une application "Hello, World" Next.js charge considérablement plus rapidement.

GIF montrant une comparaison du chargement de la page entre le composant d'intégration YouTube et un iFrame YouTube standard — </ph> WebPageTest (Mobile 4G - Virginie États-Unis)

De même, pour Google Maps, nous incluons loading="lazy" comme attribut par défaut pour l'intégration pour garantir que la carte se charge uniquement à une certaine distance la fenêtre d'affichage. Cet attribut peut sembler évident, depuis que Google Maps documentation l'inclut dans leur exemple d'extrait de code, mais seulement 45% des sites Next.js qui intègrent Google Maps utilisent loading="lazy".

Exécuter des scripts tiers dans un nœud de calcul Web

Une technique avancée que nous explorons dans @next/third-parties est de la rendre plus facile de décharger les scripts tiers vers un nœud de calcul Web. Popularité par des bibliothèques telles que Partytown, ce qui peut réduire l'impact des scripts tiers sur les performances des pages de façon significative en les déplaçant complètement hors du thread principal.

Le GIF animé suivant montre les variations dans les tâches longues et le thread principal temps de blocage lors de l'application de différentes stratégies <Script> à un conteneur GTM sur un site Next.js. Notez que si vous passez d'une stratégie à l'autre retarde l'exécution de ces scripts et les transfère vers un nœud de calcul Web. élimine complètement le temps passé sur le thread principal.

GIF montrant les différences de temps de blocage du thread principal pour les différentes stratégies de script — </ph> WebPageTest (Mobile 4G - Virginie États-Unis)

Dans cet exemple, déplacer l'exécution du conteneur GTM et scripts de tag associés à un nœud de calcul Web a réduit de 92% la durée du traitement des données.

Si elle n'est pas gérée avec précaution, cette technique peut en arrière-plan casser de nombreux scripts tiers, ce qui complique le débogage. Dans mois, nous vérifierons si les composants tiers proposés @next/third-parties fonctionne correctement lorsqu'il est exécuté dans un nœud de calcul Web. Si c’est le cas, nous s'efforcent de proposer aux développeurs un moyen simple et facultatif d'utiliser technique.

Étapes suivantes

Au cours du développement de ce package, il est devenu évident des recommandations de chargement tiers afin que les autres frameworks pourraient également tirer parti des mêmes techniques sous-jacentes que celles utilisées. Cela nous a amenés à créer des applications Capital, une bibliothèque qui utilise JSON pour décrire les techniques de chargement tierces, qui sont actuellement sert de base à @next/third-parties.

Lors des prochaines étapes, nous continuerons à nous concentrer sur l'amélioration des composants fournis pour Next.js et nous nous efforçons d'inclure des utilitaires similaires dans d'autres des frameworks et des plates-formes CMS populaires. Nous travaillons actuellement en collaboration avec Nuxt et ont l'intention de lancer des utilitaires tiers similaires, adaptés à leur écosystème dans un avenir proche.

Si l'un des tiers que vous utilisez dans votre application Next.js est compatible avec @next/third-parties, installer le package et essayez ! Nous aimerions connaître votre avis sur GitHub