NextJS Core Web Vitals - fix third party scripts

Fix third party Scripts in NextJS

Third party Scripts zijn scripts die functionaliteit van derden toevoegen aan je websites. Vaak worden deze scripts gehost door een derde partij, hoewel dit meestal niet strikt noodzakelijk is (je kunt bijvoorbeeld het analytics javascript-bestand zelf hosten). Third-party scripts bieden een breed scala aan nuttige functionaliteit, waardoor het web dynamischer, interactiever en meer verbonden wordt. Deze scripts kunnen cruciaal zijn voor de functionaliteit of inkomstenstroom van je website. Maar third-party scripts brengen ook veel risico's met zich mee die in overweging moeten worden genomen om hun impact te minimaliseren en toch waarde te bieden.

Stel je eens voor: Je bent de trotse eigenaar van een geoptimaliseerde Next.js-site. Je hebt al je code geoptimaliseerd, een vorm van static generation geïmplementeerd, al je afbeeldingen geoptimaliseerd, Critical CSS geïmplementeerd maar je site slaagt nog steeds niet voor de Core Web Vitals. Wat is er aan de hand?

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

Hoe Third Party Scripts de Core Web Vitals beïnvloeden

Third Party Scripts kunnen je Core Web Vitals op meer manieren verpesten dan je je waarschijnlijk kunt voorstellen. Dit zijn enkele van de problemen die ik tegenkwam op live websites.

• Het netwerk vertragen. Third party scripts kunnen meerdere verzoeken naar meerdere servers sturen, grote niet-geoptimaliseerde bestanden downloaden zoals afbeeldingen en video's, frameworks en bibliotheken meerdere keren downloaden.
• JavaScript van derden kan de DOM op elk moment blokkeren (of zelfs meerdere keren tijdens een pagina bezoek), waardoor het renderen van pagina's wordt vertraagd en te veel CPU-tijd wordt gebruikt wat gebruikersinteractie kan vertragen en batterijverlies kan veroorzaken.
• Render blocking third-party scripts kunnen een single-point of failure (SPOF) zijn
• Third party scripts kunnen netwerkproblemen veroorzaken door slecht geconfigureerde HTTP caching, gebrek aan voldoende servercompressie en trage/oude http protocollen
• User experience schaden op vele andere manieren zoals het verbergen van content, blokkeren van browser events (zoals het window load event) of gebruikmaken van verouderde api's zoals document.write

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

Idealiter wil je ervoor zorgen dat third-party scripts geen invloed hebben op het critical rendering path. Je go-to oplossing zou zijn om het defer of async attribuut te gebruiken. Helaas is dit qua timing 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 die JavaScript zal uitvoeren. Dit kost tijd en middelen. Dit proces zal vertragen wanneer de browser te druk is met het compileren en uitvoeren van JavaScript van derden.

Introductie van de Next.js Script component

De Next.js Script component, next/script, is een uitbreiding van het HTML <script> element. Het stelt ontwikkelaars in staat om de laadprioriteit van third-party scripts overal in hun applicatie in te stellen, buiten next/head, wat ontwikkelaars tijd bespaart terwijl de laadprestaties worden verbeterd.

Om een third-party script aan je applicatie toe te voegen, importeer je de next/script component:

import Script from 'next/script'

Strategie

Met next/script bepaal je wanneer je je third-party script laadt door gebruik te maken van de strategy property:

Er zijn drie verschillende laadstrategieën die kunnen worden gebruikt:

• beforeInteractive: Laad een script voordat de pagina interactief is
• afterInteractive: Laad een script onmiddellijk nadat de pagina interactief wordt
• lazyOnload: Laad een script tijdens inactieve tijd
• worker: Laad een script in een web worker

beforeInteractive Strategie

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

Vanuit een Core Web Vitals perspectief is dit precies het soort gedrag dat we zouden willen vermijden! De beforeInteractive strategie mag alleen worden gebruikt voor scripts die absoluut kritiek zijn voor de pagina. Third party scripts zijn nooit bedoeld om 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 bezig zou moeten zijn met het downloaden en uitvoeren van de next.js chunks. Voor de Core Web Vitals betekent dit dat de First Input Delay waarschijnlijk beïnvloed zal worden.

afterInteractive Strategie

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

Vanuit een core web vitals perspectief is dit een veel betere (maar nog niet perfecte) plek om third party scripts te injecteren. Deze strategie moet worden gebruikt voor scripts die niet zo snel mogelijk hoeven te laden en onmiddellijk kunnen worden opgehaald en uitgevoerd 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');
  `,
  }}
/>

lazyOnload Strategie

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

Scripts die de lazyOnload strategie gebruiken, worden laat geladen nadat alle resources zijn opgehaald en tijdens inactieve tijd. Dit betekent dat het third party script niet zal interfereren met de next.js chunks en de impact die dit script heeft op de first input delay (FID) zal minimaliseren

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

worker Strategie