Fix Third Party Scripts in Next.js voor betere Core Web Vitals

Fix third-party scripts in Next.js

Third-party scripts zijn de meest voorkomende oorzaak van falende Core Web Vitals op verder geoptimaliseerde Next.js sites. Je hebt alles goed gedaan: afbeeldingen geoptimaliseerd, static generation geïmplementeerd, kritieke CSS inline geplaatst. Maar je Interaction to Next Paint faalt nog steeds. De oorzaak is bijna altijd third-party JavaScript. Volgens de 2025 Web Almanac laadt 92% van de pagina's ten minste één third-party resource. Scripts vormen 24,8% van alle third-party verzoeken, meer dan elk ander type resource.

Laatst beoordeeld door Arjen Karel in maart 2026

Dit kan komen door third-party scripts zoals advertenties, analytics, social media knoppen, widgets, A/B testing scripts, video players enzovoort.

Hoe third-party scripts de Core Web Vitals beïnvloeden

Third-party scripts kunnen je Core Web Vitals op meer manieren in de war schoppen dan je je waarschijnlijk kunt voorstellen. Dit zijn enkele van de problemen die ik tegenkom op live websites.

• Het netwerk vertragen. Third-party scripts kunnen meerdere verzoeken naar meerdere servers sturen, grote ongeoptimaliseerde bestanden zoals afbeeldingen en video's downloaden en frameworks en bibliotheken meerdere keren downloaden.
• Third-party JavaScript kan de DOM op elk moment (of zelfs meerdere keren tijdens een paginabezoek) blokkeren, wat vertraagt hoe snel pagina's kunnen renderen en te veel CPU-tijd in beslag neemt, wat gebruikersinteractie kan vertragen en de batterij kan leegtrekken.
• Render blocking third-party scripts kunnen een single point of failure (SPOF) zijn.
• Third-party scripts kunnen netwerkproblemen veroorzaken door slecht geconfigureerde HTTP caching, een gebrek aan voldoende servercompressie en trage of verouderde HTTP-protocollen.
• De user experience op veel andere manieren schaden, zoals het verbergen van content, het blokkeren van browser events (zoals het window load event) of het gebruik van verouderde API's zoals document.write.

De cijfers zijn ontnuchterend. Het Chrome Aurora team ontdekte dat een Google Tag Manager container met 18 tags de Total Blocking Time met bijna 20x verhoogt. De 2025 Web Almanac rapporteert een mobiele mediane TBT van 1.916 ms, bijna 10x de best practice van 200 ms. Third-party scripts leveren een grote bijdrage aan dat cijfer.

Fix third-party scripts en Core Web Vitals in Next.js

Idealiter wil je ervoor zorgen dat geen enkel third-party script het critical rendering path beïnvloedt. Je eerste instinct zou zijn om het defer of async attribuut te gebruiken. Helaas is dit vanuit een timingperspectief geen goede optie voor de meeste Next.js sites. Een Next.js site leunt zwaar op JavaScript om de pagina te hydrateren.

Dit betekent dat zodra de Next.js bundels zijn gedownload, de browser dat JavaScript zal uitvoeren. Dit kost tijd en resources. Dit proces zal vertragen wanneer de browser te druk is met het compileren en uitvoeren van third-party JavaScript.

De Next.js Script component

De Next.js Script component (next/script) geeft je controle over wanneer third-party scripts laden ten opzichte van je applicatiecode. In plaats van te vechten tegen het standaard laadgedrag van de browser, kies je een strategie die past bij het belang van het script.

Importeer het in een component:

import Script from 'next/script'

Strategie

Met next/script beslis je wanneer je je third-party script laadt door de strategy property te gebruiken. Er zijn vier laadstrategieën:

• beforeInteractive: Laad een script voordat de pagina interactief is
• afterInteractive: Laad een script onmiddellijk nadat de pagina interactief is geworden
• lazyOnload: Laad een script tijdens idle time
• worker: Laad een script in een web worker (experimenteel, alleen Pages Router)

beforeInteractive Strategie

Scripts die laden met de beforeInteractive strategie worden vanuit de server geïnjecteerd in de initiële HTML met het defer attribuut ingeschakeld en worden uitgevoerd voordat de zelfgebundelde JavaScript wordt uitgevoerd.

Vanuit een Core Web Vitals perspectief is dit precies het type gedrag dat we willen vermijden! De beforeInteractive strategie zou alleen gebruikt moeten worden voor scripts die absoluut kritiek zijn voor de pagina. Third-party scripts horen nooit kritiek te zijn!

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

In dit geval wordt de bootstrap JavaScript bibliotheek toegevoegd aan de gegenereerde HTML met het defer attribuut, net voor de Next.js bundels. Dit betekent dat de browser waarschijnlijk de bootstrap bibliotheek zal ophalen en uitvoeren vóór de Next.js bundel. Dit zal de Next.js hydratatie vertragen en waarschijnlijk de main thread blokkeren wanneer de browser de Next.js chunks zou moeten downloaden en uitvoeren. Voor de Core Web Vitals betekent dit dat Interaction to Next Paint waarschijnlijk wordt beïnvloed.

afterInteractive Strategie

Scripts die de afterInteractive strategie gebruiken, worden client-side geïnjecteerd en zullen downloaden nadat Next.js de pagina hydrateert.

Vanuit een Core Web Vitals perspectief is dit een veel betere (maar nog niet perfecte) plek om third-party scripts te injecteren. Deze strategie zou gebruikt moeten worden voor scripts die niet zo snel mogelijk hoeven te laden en onmiddellijk opgehaald en uitgevoerd kunnen worden nadat de pagina interactief is.

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

Voor Google Tag Manager en Google Analytics is er nu een betere optie. Zie de @next/third-parties sectie hieronder.

lazyOnload Strategie

Met de lazyOnload strategie beginnen de dingen eindelijk interessant te worden! De manier waarop ik denk over third-party scripts is simpel: 'ze horen niet kritiek te zijn voor een pagina'. Als je niet zonder een bepaald third-party script kunt leven, zou je waarschijnlijk niet op een third party moeten vertrouwen.

Scripts die de lazyOnload strategie gebruiken, worden laat geladen nadat alle resources zijn opgehaald en tijdens idle time. Dit betekent dat het third-party script niet interfereert met de Next.js chunks en de impact minimaliseert die dit script heeft op Interaction to Next Paint (INP).

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

worker Strategie

De worker strategie is een experimentele feature die Partytown gebruikt om scripts in een web worker uit te voeren in plaats van de main thread. Het concept is interessant: het Chrome Aurora team mat een 92% TBT reductie bij het verplaatsen van GTM naar een web worker. Maar de worker strategie werkt alleen met de Pages Router. Het ondersteunt de App Router niet. Mijn advies: blijf hier weg totdat het project volwassener wordt of de DOM beschikbaar komt voor web workers.

@next/third-parties: de moderne aanpak

Next.js biedt nu het @next/third-parties package aan met geoptimaliseerde componenten voor de meest voorkomende third-party diensten. Deze componenten handelen de laadstrategie intern af, dus je hoeft het niet zelf te configureren.

Installeer het:

npm install @next/third-parties

Voor Google Tag Manager voeg je de component toe aan je root layout:

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

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

Voor Google Analytics:

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

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

Het Chrome Aurora team rapporteert dat 66% van de Next.js sites Google Tag Manager gebruikt en 52% Google Analytics gebruikt. Als je een van deze laadt, gebruik dan de dedicated componenten in plaats van de generieke Script component met dangerouslySetInnerHTML. Als je GTM's dataLayer gebruikt, zie dan ook het dataLayer INP yield pattern om te voorkomen dat push events interacties blokkeren.

Welke strategie voor welk script?

• GTM en GA: Gebruik de @next/third-parties componenten. Deze handelen de timing intern af.
• Chat widgets (Intercom, HubSpot, Drift): Gebruik lazyOnload. Een chat widget is nooit kritiek voor de eerste interactie.
• A/B testing (Optimizely, VWO): Gebruik beforeInteractive alleen als de test above-the-fold content beïnvloedt. Gebruik anders afterInteractive.
• Social embeds en video players: Gebruik lazyOnload.
• Advertentiescripts: Gebruik afterInteractive. Advertenties moeten redelijk snel laden voor inkomsten, maar mogen de hydratatie niet blokkeren.

Bij Next.js sites gemonitord door CoreDash, laten degenen die lazyOnload gebruiken voor analytics scripts een mediane INP-verbetering van 27ms zien ten opzichte van afterInteractive. Dat is het verschil tussen het halen en falen van de INP drempelwaarde.

Welke strategie je ook kiest, verifieer de resultaten met Real User Monitoring. Lab scores vertellen je wat er zou kunnen gebeuren. Field data vertelt je wat er daadwerkelijk is gebeurd. En soms is de beste optimalisatie het verwijderen van scripts die je niet nodig hebt.

Voor meer over het meten van de impact, zie de gids over het meten van Core Web Vitals in Next.js. Als je ook te maken hebt met render blocking CSS in Next.js, fix dat dan eerst. Voor een bredere kijk op hoe de browser beslist wat er opgehaald moet worden en wanneer, bekijk de resource prioritization gids.