Diese Seite wurde von der Cloud Translation API übersetzt.

Ein Next.js-Paket zum Verwalten von Bibliotheken von Drittanbietern

Houssein Djirdeh

2021 führte das Chrome Aurora-Team die Script- Komponente zur Verbesserung der Laden der Leistung von Drittanbieter-Skripts in Next.js. Seit der Einführung haben wir erweiterte Funktionen, um das Laden von Drittanbieter-Ressourcen für Entwickelnde schneller.

Dieser Blog-Post bietet einen Überblick über die neuen Funktionen, die wir veröffentlicht haben, die meisten insbesondere die @next/third-parties Bibliothek sowie einen Überblick über zukünftige Initiativen in unserer Roadmap.

Auswirkungen von Drittanbieter-Scripts auf die Leistung

41% aller Anfragen von Drittanbietern auf Next.js-Websites sind Skripts. „Gefällt mir“-Angabe für andere Inhalte das Herunterladen und Ausführen von Skripts, was das Rendering blockieren und die Nutzerinteraktion verzögern kann. Daten aus Chrome Der Bericht zur Nutzererfahrung (CrUX) zeigt, dass Next.js-Websites, die mehr Drittanbieter-Websites laden, Skripts haben eine geringere Interaktion mit dem nächsten Paint (INP) und Largest Contentful Paint Erfolgsquoten (LCP) an.

Balkendiagramm, das einen Rückgang des Prozentsatzes von Next.js mit guten INP- und LCP-Werten im Verhältnis zur Anzahl der geladenen Drittanbieter zeigt — </ph> Bericht zur Nutzererfahrung in Chrome im Dezember 2023 (110.823 Websites)

Die in diesem Diagramm beobachtete Korrelation impliziert keine Kausalität. Lokale Anzeigen Tests liefern zusätzliche Belege dafür, dass Skripts von Drittanbietern die Seitenleistung beeinflussen. In der folgenden Tabelle werden beispielsweise verschiedene Labs verglichen. wenn ein Google Tag Manager-Container – mit 18 zufällig ausgewählten Containern – Tags: Wird zu Taxonomy hinzugefügt, einem beliebten Next.js-Beispiel.

Balkendiagramm, das die Unterschiede bei verschiedenen Lab-Messwerten zeigt, wenn eine Website mit und ohne Google Tag Manager geladen wird — </ph> WebPageTest (4G für Mobilgeräte – Virginia, USA)

WebPageTest-Dokumentation finden Sie Details dazu, wie diese Timings gemessen werden. Sie sehen auf einen Blick, dass alle Lab-Messwerte vom GTM-Container betroffen sind. Für Beispiel: Total Blocking Time (TBT) – ein nützliches Lab Proxy, der ungefähr dem INP entspricht, einen Anstieg um das 20-Fache verzeichnen konnte.

Skriptkomponente

Als wir die <Script>-Komponente in Next.js veröffentlicht haben, haben wir darauf geachtet, über eine nutzerfreundliche API, die dem herkömmlichen <script> -Elements. Damit können Entwickler das Skript eines Drittanbieters an jedem beliebigen Ort Komponente in der Anwendung und Next.js übernimmt die Sequenzierung der nachdem wichtige Ressourcen geladen wurden.

<!-- 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" />

Zehntausende Next.js-Anwendungen – darunter beliebte Websites wie Patreon, Target und Notion: Verwenden Sie die Komponente <Script>. Trotz der Effektivität, haben einige Entwickler Bedenken zu Folgendem geäußert: Dinge:

Platzierung der <Script>-Komponente in einer Next.js-App der unterschiedlichen Installationsanleitungen verschiedener Drittanbieter, (Entwicklererfahrung).
Welche Ladestrategie eignet sich am besten für verschiedene Drittanbieter-Skripts (Nutzererfahrung).

Um diesen beiden Problemen entgegenzuwirken, haben wir @next/third-parties eingeführt – ein Spezialbibliothek mit einer Reihe optimierter Komponenten und Dienstprogrammen die auf beliebte Drittanbieter zugeschnitten sind.

Verwaltung von Drittanbieterbibliotheken für Entwickler

Auf Next.js-Websites kommen viele Drittanbieter-Skripts zum Einsatz, wobei Google Tag Manager ist am beliebtesten und wird von 66% der Websites. @next/third-parties baut auf <Script> auf Komponente, indem übergeordnete Wrapper eingeführt wurden, die die Nutzung für diesen gängigen Anwendungsfällen.

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 – ein weiteres gängiges Drittanbieter-Skript (52% der Next.js-Websites) haben ebenfalls eine eigene Komponente.

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 vereinfacht das Laden häufig verwendeter Skripts Es erweitert aber auch unsere Fähigkeit, Dienstprogramme für andere Drittanbieter etwa Einbettungen. Eingebettete Google Maps- und YouTube-Inhalte verwendet in 8% und 4% der Next.js-Websites. Wir haben auch Komponenten geliefert, einfacher zu laden.

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" />
    </>
  );
}

Nutzererfahrung: Bibliotheken von Drittanbietern werden schneller geladen

In einer perfekten Welt wäre jede weit verbreitete Bibliothek von Drittanbietern in vollem Umfang verfügbar, optimiert, sodass Abstraktionen, die die Leistung verbessern, überflüssig werden. Bis das der Fall ist, können wir versuchen, wenn sie über gängige Frameworks wie Next.js integriert werden. Wir können verschiedene Ladetechniken testen und sicherstellen, dass die Skripts sequenziert sind auf die richtige Weise zukommen lassen und unser Feedback letztlich an Dritte weitergeben. um Upstream-Änderungen zu fördern.

Nehmen wir zum Beispiel YouTube-Einbettungen. Bei einigen alternativen Implementierungen als die native Einbettung. Aktuell ist die <YouTubeEmbed> Komponente, die von @next/third-parties Verwendungen exportiert wurde lite-youtube-embed, bei Darstellung in einem Next.js-Vergleich, lädt erheblich schneller.

GIF, das den Vergleich des Seitenaufbaus zwischen der YouTube Embed-Komponente und einem normalen YouTube-iFrame zeigt — </ph> WebPageTest (4G für Mobilgeräte – Virginia, USA)

Ebenso nehmen wir für Google Maps loading="lazy" als Standardattribut für um sicherzustellen, dass die Karte nur geladen wird, wenn sie sich in einer bestimmten Entfernung Darstellungsbereich. Dies mag als ein offensichtliches Attribut erscheinen, das Sie einbeziehen sollten, insbesondere seit der Einführung von Google Maps Dokumentation in ihr Beispiel-Code-Snippet einfügt, aber nur 45% der Next.js-Websites, auf denen Google Maps eingebettet ist, verwenden loading="lazy".

Drittanbieterskripts in einem Web Worker ausführen

Mit einer fortgeschrittenen Technik, die wir in @next/third-parties erkunden, Drittanbieter-Skripts leichter an einen Web Worker übertragen werden. Beliebt durch wie Partytown, kann das die Zahl der die sich wesentlich auf die Seitenleistung auswirken, gänzlich aus dem Hauptthread verschoben.

Das folgende animierte GIF zeigt die Variationen in langen Aufgaben und Hauptthread Blockierzeit beim Anwenden verschiedener <Script>-Strategien auf einen GTM-Container innerhalb einer Next.js-Website. Der Wechsel zwischen Strategieoptionen verzögert die Ausführung dieser Skripts und verlagert sie in einen Web Worker verringert sich ihre Zeit für den Hauptthread.

GIF, das die Unterschiede bei der Blockierzeit des Hauptthreads für die verschiedenen Skriptstrategien zeigt — </ph> WebPageTest (4G für Mobilgeräte – Virginia, USA)

In diesem speziellen Beispiel werden die Ausführung des GTM-Containers zugehörigen Tag-Skripts zu einem Web-Worker die TBT um 92%reduzieren.

Wenn Sie diese Technik nicht sorgfältig anwenden, das Debugging vieler Drittanbieterskripte kaputtgeht. In der nächsten Monate erscheinen, überprüfen wir, ob Drittanbieter-Komponenten @next/third-parties funktioniert ordnungsgemäß, wenn sie in einem Web Worker ausgeführt wird. Wenn ja, werden wir eine einfache und optionale Möglichkeit für Entwickler bieten, .

Nächste Schritte

Bei der Entwicklung dieses Pakets wurde deutlich, müssen Ladeempfehlungen von Drittanbietern zentralisieren, damit andere Frameworks könnte auch von denselben grundlegenden Techniken profitieren. Das brachte uns dazu, Build Drittanbieter Capital, eine Bibliothek das mithilfe von JSON Ladeverfahren von Drittanbietern beschreibt, die derzeit dient als Grundlage für @next/third-parties.

In den nächsten Schritten werden wir uns weiterhin auf die Verbesserung der bereitgestellten Komponenten und erweitern unsere Bemühungen um ähnliche Dienstprogramme in anderen gängige Frameworks und CMS-Plattformen. Wir arbeiten derzeit mit Nuxt zusammen, und planen die Veröffentlichung ähnlicher Drittanbieter-Dienstprogramme, in naher Zukunft für ihr Ökosystem.

Wenn einer der Drittanbieter, die Sie in Ihrer Next.js-App nutzen, von @next/third-parties, das Paket installieren und probieren Sie es aus! Wir freuen uns auf Ihr Feedback zu GitHub