Drittanbieter-Skripte in Next.js für bessere Core Web Vitals beheben

Drittanbieter-Skripte in Next.js beheben

Drittanbieter-Skripte sind die häufigste Ursache für das Fehlschlagen der Core Web Vitals auf ansonsten optimierten Next.js-Websites. Sie haben alles richtig gemacht: Bilder optimiert, statische Generierung implementiert, kritisches CSS integriert. Aber Ihr Interaction to Next Paint schlägt immer noch fehl. Die Ursache ist fast immer Drittanbieter-JavaScript. Laut dem Web Almanac 2025 laden 92 % der Seiten mindestens eine Drittanbieter-Ressource. Skripte machen 24,8 % aller Drittanbieter-Anfragen aus, mehr als jeder andere Ressourcentyp.

Zuletzt überprüft von Arjen Karel im März 2026

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

Wie sich Drittanbieter-Skripte auf die Core Web Vitals auswirken

Drittanbieter-Skripte 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 bei Live-Websites stoße.

• Verlangsamung des Netzwerks. Drittanbieter-Skripte können mehrere Anfragen an mehrere Server senden, große, unoptimierte Dateien wie Bilder und Videos herunterladen sowie Frameworks und Bibliotheken mehrmals herunterladen.
• Drittanbieter-JavaScript kann das DOM jederzeit (oder sogar mehrmals während eines Seitenbesuchs) blockieren, wodurch sich die Rendergeschwindigkeit der Seiten verzögert und zu viel CPU-Zeit verbraucht wird, was die Benutzerinteraktion verzögern und den Akku belasten kann.
• Blockierende Drittanbieter-Skripte können ein Single Point of Failure (SPOF) sein.
• Drittanbieter-Skripte können Netzwerkprobleme aufgrund schlecht konfigurierter HTTP-Caches, fehlender Serverkomprimierung und langsamer oder veralteter HTTP-Protokolle verursachen.
• Schädigung der User Experience auf viele andere Arten, wie das Verbergen von Inhalten, das Blockieren von Browserereignissen (wie das window load-Ereignis) oder die Verwendung veralteter APIs wie document.write.

Die Zahlen sind ernüchternd. Das Chrome Aurora-Team fand heraus, dass ein Google Tag Manager-Container mit 18 Tags die Total Blocking Time fast um das 20-fache erhöht. Der Web Almanac 2025 meldet eine mediane mobile TBT von 1.916 ms, was fast dem 10-fachen der Best Practice von 200 ms entspricht. Drittanbieter-Skripte tragen maßgeblich zu dieser Zahl bei.

Beheben Sie Drittanbieter-Skripte und Core Web Vitals in Next.js

Im Idealfall möchten Sie sicherstellen, dass kein Drittanbieter-Skript den kritischen Rendering-Pfad beeinträchtigt. Ihr erster Instinkt wäre, das defer- oder async-Attribut zu verwenden. Aus zeitlicher Sicht ist dies jedoch für die meisten Next.js-Websites keine gute Option. Eine Next.js-Website verlässt sich stark auf JavaScript, um die Seite zu hydratisieren.

Dies bedeutet, dass der Browser dieses JavaScript ausführt, sobald die Next.js-Bundles heruntergeladen wurden. Dies kostet Zeit und Ressourcen. Dieser Prozess verlangsamt sich, wenn der Browser zu sehr damit beschäftigt ist, Drittanbieter-JavaScript zu kompilieren und auszuführen.

Die Next.js Script-Komponente

Die Next.js Script-Komponente (next/script) gibt Ihnen die Kontrolle darüber, wann Drittanbieter-Skripte im Verhältnis zu Ihrem Anwendungscode geladen werden. Anstatt gegen das standardmäßige Ladeverhalten des Browsers anzukämpfen, wählen Sie eine Strategie, die der Wichtigkeit des Skripts entspricht.

Importieren Sie es in eine beliebige Komponente:

import Script from 'next/script'

Strategie

Mit next/script entscheiden Sie, wann Ihr Drittanbieter-Skript geladen werden soll, indem Sie die strategy-Eigenschaft verwenden. Es gibt vier Ladestrategien:

• beforeInteractive: Ein Skript laden, bevor die Seite interaktiv ist
• afterInteractive: Ein Skript laden, unmittelbar nachdem die Seite interaktiv wird
• lazyOnload: Ein Skript während der Leerlaufzeit laden
• worker: Ein Skript in einem Web Worker laden (experimentell, nur Pages Router)

beforeInteractive-Strategie

Skripte, die mit der beforeInteractive-Strategie geladen werden, werden vom Server mit aktiviertem defer-Attribut in das anfängliche HTML eingefügt und ausgeführt, bevor selbstgebündeltes JavaScript ausgeführt wird.

Aus der Perspektive der Core Web Vitals ist dies genau die Art von Verhalten, die wir vermeiden möchten! Die beforeInteractive-Strategie sollte nur für Skripte verwendet werden, die für die Seite absolut kritisch sind. Drittanbieter-Skripte sollten 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 vor dem Next.js-Bundle abruft und ausführt. Dies verzögert die Next.js-Hydratisierung und blockiert wahrscheinlich den Haupt-Thread, wenn der Browser die Next.js-Chunks herunterladen und ausführen sollte. Für die Core Web Vitals bedeutet dies, dass Interaction to Next Paint wahrscheinlich beeinträchtigt wird.

afterInteractive-Strategie

Skripte, die die afterInteractive-Strategie verwenden, werden clientseitig eingefügt und heruntergeladen, nachdem Next.js die Seite hydratisiert hat.

Aus der Perspektive der Core Web Vitals ist dies ein viel besserer (aber noch nicht perfekter) Ort, um Drittanbieter-Skripte einzufügen. Diese Strategie sollte für Skripte verwendet werden, die nicht so schnell wie möglich geladen werden müssen und abgerufen und ausgeführt werden können, unmittelbar 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');
  `,
  }}
/>

Für Google Tag Manager und Google Analytics gibt es jetzt eine bessere Option. Siehe den Abschnitt @next/third-parties unten.

lazyOnload-Strategie

Mit der lazyOnload-Strategie werden die Dinge endlich interessant! Wie ich über Drittanbieter-Skripte denke, ist einfach: "Sie sollten für eine Seite nicht kritisch sein". Wenn Sie nicht ohne ein bestimmtes Drittanbieter-Skript leben können, sollten Sie sich wahrscheinlich nicht auf einen Drittanbieter 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 Drittanbieter-Skript nicht in die Next.js-Chunks eingreift und die Auswirkungen dieses Skripts auf Interaction to Next Paint (INP) minimiert werden.

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

worker-Strategie

Die worker-Strategie ist eine experimentelle Funktion, die Partytown verwendet, um Skripte in einem Web Worker anstatt im Haupt-Thread auszuführen. Das Konzept ist interessant: Das Chrome Aurora-Team hat eine Reduzierung der TBT um 92 % gemessen, als GTM in einen Web Worker verlagert wurde. Die worker-Strategie funktioniert jedoch nur mit dem Pages Router. Sie unterstützt den App Router nicht. Mein Rat: Halten Sie sich davon fern, bis entweder das Projekt ausgereift ist oder das DOM für Web Worker verfügbar wird.

@next/third-parties: der moderne Ansatz

Next.js bietet jetzt das Paket @next/third-parties mit optimierten Komponenten für die gängigsten Drittanbieter-Dienste. Diese Komponenten handhaben die Ladestrategie intern, sodass Sie sie nicht selbst konfigurieren müssen.

Installieren Sie es:

npm install @next/third-parties

Für den Google Tag Manager fügen Sie die Komponente zu Ihrem Root-Layout hinzu:

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

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

Für Google Analytics:

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

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

Das Chrome Aurora-Team berichtet, dass 66 % der Next.js-Websites den Google Tag Manager und 52 % Google Analytics verwenden. Wenn Sie eines von beiden laden, verwenden Sie die dedizierten Komponenten anstelle der generischen Script-Komponente mit dangerouslySetInnerHTML. Wenn Sie den dataLayer von GTM verwenden, beachten Sie auch das dataLayer INP yield-Muster, um zu verhindern, dass Push-Ereignisse Interaktionen blockieren.

Welche Strategie für welches Skript?

• GTM und GA: Verwenden Sie @next/third-parties-Komponenten. Sie handhaben das Timing intern.
• Chat-Widgets (Intercom, HubSpot, Drift): Verwenden Sie lazyOnload. Ein Chat-Widget ist niemals kritisch für die erste Interaktion.
• A/B-Testing (Optimizely, VWO): Verwenden Sie beforeInteractive nur, wenn sich der Test auf sichtbare Inhalte auswirkt. Ansonsten verwenden Sie afterInteractive.
• Social Embeds und Video-Player: Verwenden Sie lazyOnload.
• Anzeigen-Skripte: Verwenden Sie afterInteractive. Anzeigen müssen für den Umsatz einigermaßen schnell geladen werden, sollten aber die Hydratisierung nicht blockieren.

Auf Next.js-Websites, die von CoreDash überwacht werden, zeigen diejenigen, die lazyOnload für Analytics-Skripte verwenden, eine mediane INP-Verbesserung von 27 ms im Vergleich zu afterInteractive. Das ist der Unterschied zwischen dem Bestehen und Verfehlen des INP-Schwellenwerts.

Unabhängig davon, für welche Strategie Sie sich entscheiden, überprüfen Sie die Ergebnisse mit Real User Monitoring. Laborwerte sagen Ihnen, was passieren könnte. Felddaten sagen Ihnen, was tatsächlich passiert ist. Und manchmal ist die beste Optimierung das Entfernen von Skripten, die Sie nicht benötigen.

Weitere Informationen zur Messung der Auswirkungen finden Sie im Leitfaden zum Messen der Core Web Vitals in Next.js. Wenn Sie auch mit renderblockierendem CSS in Next.js zu tun haben, beheben Sie das zuerst. Für einen breiteren Blick darauf, wie der Browser entscheidet, was wann abgerufen wird, lesen Sie den Leitfaden zur Ressourcenpriorisierung.