NextJS Core Web Vitals - Third Party Scripte beheben

Third Party Scripte in NextJS beheben

Third Party Scripts sind Skripte, die Ihren Websites Funktionen von Drittanbietern hinzufügen. Oft werden diese Skripte von einem Drittanbieter gehostet, obwohl dies normalerweise nicht unbedingt notwendig ist (Sie können zum Beispiel die Analytics-Javascript-Datei selbst hosten). Third-Party-Scripte bieten eine breite Palette nützlicher Funktionen, die das Web dynamischer, interaktiver und vernetzter machen. Diese Skripte können für die Funktionalität oder den Umsatzstrom Ihrer Website entscheidend sein. Aber Third-Party-Scripte bringen auch viele Risiken mit sich, die berücksichtigt werden sollten, um ihre Auswirkungen zu minimieren und dennoch einen Mehrwert zu bieten.

Stellen Sie sich vor: Sie sind stolzer Besitzer einer optimierten Next.js-Seite. Sie haben Ihren gesamten Code optimiert, eine Form der Static Generation implementiert, alle Ihre Bilder optimiert, Critical CSS implementiert, aber Ihre Seite besteht die Core Web Vitals immer noch nicht. Was ist los?

Es könnte an Third Party Scripten wie Anzeigen, Analytics, Social-Media-Buttons, Widgets, A/B- Testing-Skripten, Videoplayern und so weiter liegen.

Wie Third Party Scripte die Core Web Vitals beeinflussen

Third Party Scripte können Ihre Core Web Vitals auf mehr Arten ruinieren, als Sie sich wahrscheinlich vorstellen können. Dies sind einige der Probleme, auf die ich auf Live-Websites gestoßen bin.

• Das Netzwerk verlangsamen. Third Party Scripte können mehrere Anfragen an mehrere Server senden, große nicht optimierte Dateien wie Bilder und Videos herunterladen, Frameworks und Bibliotheken mehrmals herunterladen.
• JavaScript von Drittanbietern kann das DOM jederzeit blockieren (oder sogar mehrmals während eines Seiten- Besuchs), wodurch das Rendern von Seiten verzögert und zu viel CPU-Zeit verbraucht wird, was die Benutzerinteraktion verzögern und den Akkuverbrauch erhöhen kann.
• Render-Blocking Third-Party-Scripte können ein Single-Point-of- Failure (SPOF) sein
• Third Party Scripte können Netzwerkprobleme aufgrund schlecht konfiguriertem HTTP-Caching, Mangel an ausreichender Serverkomprimierung und langsamen/alten HTTP-Protokollen verursachen
• User Experience auf viele andere Arten schädigen, wie das Verbergen von Inhalten, Blockieren von Browser-Events (wie das Window Load Event) oder die Verwendung veralteter APIs wie document.write

Third-Party-Scripte und Core Web Vitals in Next.js beheben

Idealerweise möchten Sie sicherstellen, dass das Third-Party-Script den Critical Rendering Path nicht beeinträchtigt. Ihre bevorzugte Lösung wäre die Verwendung des defer oder async Attributs. Leider ist dies für die meisten Next.js-Seiten zeitlich keine gute Option. Eine Next.js-Seite verlässt sich stark auf JavaScript, um die Seite zu hydrieren.

Das bedeutet, dass sobald die Next.js-Bundles heruntergeladen sind, der Browser dieses JavaScript ausführt. Das kostet Zeit und Ressourcen. Dieser Prozess wird verlangsamt, wenn der Browser zu beschäftigt damit ist, JavaScript von Drittanbietern zu kompilieren und auszuführen.

Einführung der Next.js Script-Komponente

Die Next.js Script-Komponente, next/script, ist eine Erweiterung des HTML <script> Elements. Es ermöglicht Entwicklern, die Ladepriorität von Third-Party-Scripten überall in ihrer Anwendung, außerhalb von next/head, festzulegen, was Entwicklerzeit spart und gleichzeitig die Ladeleistung verbessert.

Um ein Third-Party-Script zu Ihrer Anwendung hinzuzufügen, importieren Sie die next/script Komponente:

import Script from 'next/script'

Strategie

Mit next/script entscheiden Sie, wann Ihr Third-Party-Script geladen werden soll, indem Sie die Strategy-Eigenschaft verwenden:

Es gibt drei verschiedene Ladestrategien, die verwendet werden können:

• beforeInteractive: Laden Sie ein Skript, bevor die Seite interaktiv ist
• afterInteractive: Laden Sie ein Skript unmittelbar nachdem die Seite interaktiv wird
• lazyOnload: Laden Sie ein Skript während der Leerlaufzeit
• worker: Laden Sie ein Skript in einem Web Worker

beforeInteractive Strategie

Skripte, die mit der beforeInteractive Strategie geladen werden, werden vom Server mit aktiviertem Defer-Attribut in das anfängliche HTML injiziert und ausgeführt, bevor selbst gebündeltes JavaScript ausgeführt wird.

Aus einer Core Web Vitals Perspektive ist dies genau die Art von Verhalten, die wir vermeiden möchten! Die beforeInteractive Strategie sollte nur für Skripte verwendet werden, die absolut kritisch für die Seite sind. Third Party Scripte sollen niemals kritisch sein!

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

In diesem Fall wird die Bootstrap JavaScript-Bibliothek kurz vor den Next.js-Bundles mit dem Defer-Attribut zum generierten HTML hinzugefügt. Dies bedeutet, dass der Browser wahrscheinlich die Bootstrap-Bibliothek abrufen und ausführen wird, bevor das Next.js-Bundle ausgeführt wird. Dies wird die Next.js-Hydratation verzögern und wahrscheinlich den Main Thread blockieren, wenn der Browser damit beschäftigt sein sollte, die Next.js-Chunks herunterzuladen und auszuführen. Für die Core Web Vitals bedeutet dies, dass der First Input Delay wahrscheinlich beeinträchtigt wird.

afterInteractive Strategie

Skripte, die die afterInteractive Strategie verwenden, werden clientseitig injiziert und werden heruntergeladen und nachdem Next.js die Seite hydriert hat.

Aus einer Core Web Vitals Perspektive ist dies ein viel besserer (aber noch nicht perfekter) Ort, um Third Party Scripte zu injizieren. Diese Strategie sollte für Skripte verwendet werden, die nicht so schnell wie möglich laden müssen und unmittelbar abgerufen und ausgeführt werden können, nachdem die Seite interaktiv ist.

<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');
  `,
  }}
/>

lazyOnload Strategie

Mit der lazyOnload Strategie werden die Dinge endlich interessant! Wie ich über Third Party Scripte denke, ist einfach: 'sie sollten nicht kritisch für eine Seite sein'. Wenn Sie ohne ein bestimmtes Third Party Script nicht leben können, sollten Sie sich wahrscheinlich nicht auf einen Dritten verlassen.

Skripte, die die lazyOnload Strategie verwenden, werden spät geladen, nachdem alle Ressourcen abgerufen wurden und während der Leerlaufzeit. Dies bedeutet, dass das Third Party Script nicht mit den Next.js-Chunks interferiert und die Auswirkungen dieses Skripts auf den First Input Delay (FID) minimiert

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

worker Strategie