16 methoden om JavaScript uit te stellen of te plannen

Waarom JavaScript uitstellen of plannen?

JavaScript kan (en zal) je website op een paar manieren vertragen. Dit kan allerlei negatieve impact hebben op de Core Web Vitals. JavaScript kan concurreren om netwerkbronnen, het kan concurreren om CPU- bronnen (de main thread blokkeren) en het kan zelfs het parsen van een webpagina blokkeren. Het uitstellen en plannen van je scripts kan de Core Web Vitals drastisch verbeteren.

Laatst beoordeeld door Arjen Karel in februari 2026

Om de vervelende effecten die JavaScript kan hebben op de Core Web Vitals te minimaliseren, is het meestal een goed idee om aan te geven wanneer een script in de wachtrij wordt gezet om te downloaden en te plannen wanneer het CPU-tijd kan in beslag nemen en de main thread kan blokkeren.

Hoe kan JavaScript timing de Core Web Vitals beïnvloeden?

Hoe kan JavaScript timing de Core Web Vitals beïnvloeden? Kijk maar eens naar dit praktijkvoorbeeld. De eerste pagina is geladen met 'render blocking' JavaScript.  De paint metrics evenals de Total Blocking Time zijn behoorlijk slecht. Het tweede voorbeeld is van exact dezelfde pagina maar met de JavaScript uitgesteld (deferred). Je zult zien dat de LCP afbeelding nog steeds een flinke klap kreeg. In het derde voorbeeld is hetzelfde script uitgevoerd na het 'load event' van de pagina en zijn de functie-aanroepen opgedeeld in kleinere stukken. Deze laatste slaagt ruim voor de Core Web Vitals.

Standaard zal externe JavaScript in de head van de pagina het aanmaken van de render tree blokkeren. Meer specifiek: wanneer de browser een script in het document tegenkomt, moet deze de DOM-constructie pauzeren, de controle overdragen aan de JavaScript runtime, en het script laten uitvoeren voordat hij verdergaat met de DOM-constructie. Dit heeft invloed op je Paint Metrics (Largest Contentful Paint en First Contentful Paint).

Deferred of async JavaScript kan nog steeds invloed hebben op paint metrics, vooral de Largest Contentful Paint, omdat het zal uitvoeren en de main thread zal blokkeren, zodra de DOM is aangemaakt (en veelvoorkomende LCP elementen zoals afbeeldingen misschien nog niet zijn gedownload).

Externe JavaScript bestanden zullen ook concurreren om netwerkbronnen. Externe JavaScript bestanden worden meestal eerder gedownload dan afbeeldingen. Als je te veel scripts downloadt, zal het downloaden van je afbeeldingen worden vertraagd.

Tot slot, JavaScript kan gebruikersinteractie blokkeren of vertragen. Wanneer een script CPU-bronnen gebruikt (en de main thread blokkeert), zal een browser niet reageren op input (klikken, scrollen etc) totdat dat script is voltooid. Dit heeft direct invloed op je Interaction to Next Paint (INP) score.

De impact is meetbaar. Volgens de 2025 Web Almanac slaagt slechts 15% van de mobiele pagina's voor de render-blocking resources audit. De mediane mobiele Total Blocking Time is 1.916 milliseconden. Dat is bijna 2 volle seconden waarin de browser niet kan reageren op gebruikersinvoer. Het kiezen van de juiste defer methode voor elk script is hoe je dat getal omlaag brengt.

Hoe repareert het plannen of uitstellen van JavaScript de Core Web Vitals?

Het plannen of uitstellen van JavaScript repareert de Core Web Vitals niet per se. Het gaat erom dat je de juiste tool voor de juiste situatie gebruikt. Als vuistregel moet je proberen je scripts zo min mogelijk te vertragen, maar ze in de wachtrij plaatsen voor download en ze op het juiste moment uitvoeren.

Hoe kies je de juiste defer methode?

Niet alle scripts zijn hetzelfde en elk script heeft zijn eigen functionaliteit. Sommige scripts zijn belangrijk om vroeg in het renderingproces te hebben, andere niet.

Ik categoriseer JavaScripts graag in 4 groepen op basis van hun belangrijkheidsniveau.

1. Render critical. Dit zijn de scripts die het uiterlijk van een webpagina veranderen. Als ze niet laden, zal de pagina er niet compleet uitzien. Deze scripts moeten koste wat kost worden vermeden. Als je ze om de een of andere reden niet kunt vermijden, mogen ze niet worden uitgesteld (deferred). Bijvoorbeeld een top slider of een A/B testing script.
2. Critical. Deze scripts veranderen het uiterlijk van een webpagina niet (te veel), maar de pagina werkt niet goed zonder. Deze scripts moeten worden deferred of asynced. Bijvoorbeeld je menu scripts.
3. Important. Dit zijn scripts die je wilt laden omdat ze waardevol zijn voor jou of de bezoeker. Ik laad deze scripts meestal nadat het load event is afgevuurd. Bijvoorbeeld analytics of een 'back to top' knop.
4. Nice to have. Dit zijn scripts zonder welke je kunt leven als het absoluut moet. Ik laad deze scripts met de laagste prioriteit en voer ze alleen uit wanneer de browser idle is. Bijvoorbeeld een chat widget of een facebook knop.

Methode 1: Gebruik het defer attribuut

Scripts met het defer attribuut downloaden in parallel en worden toegevoegd aan de defer JavaScript wachtrij. Vlak voordat de browser het DOMContentLoaded event afvuurt, zullen alle scripts in die wachtrij worden uitgevoerd in de volgorde waarin ze in het document verschijnen.

<script defer src='javascript.js'></script>

De 'defer truc' lost meestal veel problemen op, vooral de paint metrics. Helaas is er geen garantie, het hangt af van de kwaliteit van de scripts. Deferred scripts zullen uitvoeren zodra alle scripts zijn geladen en de HTML is geparseerd (DOMContentLoaded). Het LCP element (meestal een grote afbeelding) is dan misschien nog niet geladen en de deferred scripts zullen nog steeds een vertraging in de LCP veroorzaken.

Wanneer te gebruiken:

Gebruik deferred scripts voor Critical scripts die zo snel mogelijk nodig zijn.

Voordelen:

1. Deferred scripts zullen in parallel downloaden
2. De DOM zal beschikbaar zijn op het moment van uitvoering

Nadelen:

1. Deferred scripts kunnen je LCP metrics vertragen 
2. Deferred scripts zullen de main thread blokkeren zodra ze worden uitgevoerd
3. Het is misschien niet veilig om scripts uit te stellen wanneer inline of async scripts ervan afhankelijk zijn

Methode 2: Gebruik het async attribuut

Scripts met het async attribuut downloaden in parallel en zullen direct uitvoeren nadat ze zijn gedownload.

<script async src='javascript.js'></script>

Async scripts zullen weinig doen om je pagespeed problemen op te lossen. Het is geweldig dat ze in parallel worden gedownload, maar dat is het dan ook. Zodra ze zijn gedownload, zullen ze de main thread blokkeren terwijl ze worden uitgevoerd.

Wanneer te gebruiken:

Gebruik async scripts voor Critical scripts die zo snel mogelijk nodig zijn en op zichzelf staan (niet afhankelijk zijn van andere scripts).

Voordelen:

1. Async scripts zullen in parallel downloaden.
2. Async scripts zullen zo snel mogelijk uitvoeren.

Nadelen:

1. DOMContentLoaded kan zowel vóór als na async gebeuren.
2. De uitvoeringsvolgorde van de scripts is vooraf onbekend.
3. Je kunt geen async scripts gebruiken die afhankelijk zijn van andere async of deferred scripts

Voor een gedetailleerde vergelijking van deze twee benaderingen, zie defer vs async en hoe dit de Core Web Vitals beïnvloedt.

Methode 3: Gebruik modules

Modulaire scripts zijn standaard deferred tenzij ze het async attribuut hebben. In dat geval worden ze behandeld als async scripts

<script module src='javascript.js'></script>

Modules zijn een nieuwe manier van denken over JavaScript en lossen een aantal ontwerpfouten op. Verder zal het gebruik van script modules je website niet versnellen. 

Wanneer te gebruiken:

Wanneer je applicatie op een modulaire manier is gebouwd, is het logisch om ook JavaScript modules te gebruiken.

Voordelen:

1. Modules zijn standaard deferred
2. Modules zijn makkelijker te onderhouden en werken geweldig met modulair webdesign
3. Modules maken eenvoudige code splitting met dynamische imports mogelijk, waarbij je alleen de modules importeert die je op een bepaald moment nodig hebt.

Nadelen:

1. Modules zelf zullen de Core Web Vitals niet verbeteren
2. Het just-in-time of on the fly importeren van modules kan traag zijn en de INP verslechteren 

Methode 4: Plaats scripts onderaan de pagina

Footer scripts worden op een later moment in de wachtrij geplaatst voor download. Dit geeft prioriteit aan andere bronnen die zich in het document boven de script tag bevinden.

<html>
   <head></head>
   <body>
      [je pagina-inhoud hier]
      <script defer src='javascript.js'></script>
   </body>
</html>

Het plaatsen van je scripts onderaan de pagina is een interessante techniek. Dit zal andere bronnen (zoals afbeeldingen) vóór je scripts plannen. Dit vergroot de kans dat ze beschikbaar zijn voor de browser en op het scherm worden geschilderd (painted) voordat de JavaScript bestanden zijn gedownload en de main thread zal worden geblokkeerd door scriptuitvoering. Maar toch... geen garantie.

Wanneer te gebruiken:

Wanneer je scripts al behoorlijk goed presteren, maar je andere bronnen zoals afbeeldingen en webfonts lichtelijk prioriteit wilt geven.

Voordelen:

1. Het plaatsen van scripts onderaan de pagina vereist niet veel kennis.
2. Als het correct wordt gedaan, is er geen risico dat dit je pagina breekt

Nadelen:

1. Critical scripts worden mogelijk later gedownload en uitgevoerd
2. Het lost geen onderliggende JavaScript problemen op

Methode 5: Scripts injecteren

Geïnjecteerde scripts worden behandeld als async scripts. Ze worden in parallel gedownload en worden direct na het downloaden uitgevoerd.

<script>
    const loadScript = (scriptSource) => {
        const script = document.createElement('script');
        script.src = scriptSource;
        document.head.appendChild(script);
    }

    // roep de loadscript functie aan die 'javascript.js' injecteert
    loadScript('javascript.js');
</script>

Vanuit een Core Web Vitals perspectief is deze techniek exact hetzelfde als het gebruik van <script async>.

Wanneer te gebruiken:

Deze methode wordt vaak gebruikt door third party scripts die zo vroeg mogelijk triggeren. De functie-aanroep maakt het makkelijk om code in te kapselen en te comprimeren.

Voordelen:

1. Ingekapselde code die een async script injecteert.

Nadelen:

1. DOMContentLoaded kan zowel voor als nadat het script is geladen gebeuren.
   
2. De uitvoeringsvolgorde van de scripts is vooraf onbekend.
3. Je kunt dit niet gebruiken op scripts die afhankelijk zijn van andere async of deferred scripts

Methode 6: Scripts op een later moment injecteren

Nice-to-have scripts zouden naar mijn mening nooit deferred geladen moeten worden. Ze zouden moeten worden geïnjecteerd op het meest geschikte moment. In het onderstaande voorbeeld zal het script uitvoeren nadat de browser het 'load' event heeft verstuurd.

<script>
window.addEventListener('load', function () {
  // zie methode 5 voor de loadscript functie
  loadScript('javascript.js');
});
</script>

Dit is de eerste techniek die betrouwbaar de Largest Contentful Paint zal verbeteren. Alle belangrijke bronnen, inclusief afbeeldingen, zullen worden gedownload wanneer de browser het 'load event' afvuurt. Dit kan allerlei problemen introduceren omdat het lang kan duren voordat het load event wordt aangeroepen.

Wanneer te gebruiken:

Voor nice-to-have scripts die geen reden hebben om de paint metrics te beïnvloeden.

Voordelen:

1. Zal niet concurreren om kritieke bronnen omdat het het script zal injecteren zodra de pagina en de bronnen ervan zijn geladen

Nadelen:

1. Als je pagina slecht is ontworpen qua Core Web Vitals kan het lang duren voordat de pagina het 'load' event verstuurt
2. Je moet oppassen dat je dit niet toepast op critical scripts (zoals lazy loading, menu etc)

Methode 7: Verander het script type (en verander het dan weer terug)

Als er ergens op de pagina een script tag wordt gevonden die 1. een type attribuut heeft en 2. waarvan het type attribuut geen "text/javascript" is, zal het script niet worden gedownload en uitgevoerd door een browser. Veel JavaScript Loaders (zoals CloudFlare's RocketLoader) vertrouwen op dit principe. Het idee is vrij simpel en elegant.

Eerst worden alle scripts als volgt herschreven:

<script type="some-cool-script-type" src="javascript.js"></script>

Vervolgens worden deze scripts op een gegeven moment tijdens het laadproces weer omgezet naar 'normale javascripts'.

Wanneer te gebruiken:

Dit is geen methode die ik zou aanraden. Het oplossen van JavaScript impact zal veel meer vergen dan alleen elk script een beetje verder in de wachtrij plaatsen. Aan de andere kant, als je weinig controle hebt over de scripts die op de pagina draaien of onvoldoende JavaScript kennis hebt, is dit misschien wel je beste optie.

Voordelen:

1. Het is makkelijk, schakel gewoon rocket loader of een andere plugin in en al je scripts worden nu op een iets later moment uitgevoerd.
2. Het zal waarschijnlijk je paint metrics repareren, mits je geen JS gebaseerde lazy loading hebt gebruikt.
3. Het werkt voor inline en externe scripts.

Nadelen:

1. Je hebt geen fijnmazige controle over wanneer de scripts worden uitgevoerd
2. Slecht geschreven scripts kunnen breken
3. Het gebruikt JavaScript om JavaScript te repareren
4. Het doet niets om langlopende scripts op te lossen

Methode 8: Gebruik de intersection observer

Met de intersection observer kun je een functie uitvoeren (welke in dit geval een externe JavaScript laadt) wanneer een element in de zichtbare viewport scrolt.

<script>
const handleIntersection = (entries, observer) => {
    if (entries?.[0].isIntersecting) {
        // laad je script of voer een andere
           functie uit zoals het triggeren van een lazy loaded element
        loadScript('javascript.js');

        // verwijder de observer
        observer.unobserve(entries?.[0].target);
    }
};
const Observer = new window.IntersectionObserver()
Observer.observe(document.querySelector('footer'));
</script>

Dit is veruit de meest effectieve methode voor het uitstellen van JavaScript die er is. Laad alleen de scripts die je nodig hebt, vlak voordat je ze nodig hebt. Helaas is de praktijk zelden zo overzichtelijk en kunnen niet veel scripts worden gekoppeld aan een element dat in beeld scrolt.

Wanneer te gebruiken:

Gebruik deze techniek zoveel mogelijk! Wanneer een script alleen communiceert met een component buiten het scherm (zoals een kaart, een slider, een formulier) is dit de beste manier om dit script te injecteren.

Voordelen:

1. Zal niet interfereren met Core Web Vitals LCP en FCP
2. Zal nooit scripts injecteren die niet worden gebruikt. Dit zal de INP verbeteren

Nadelen:

1. Mag niet worden gebruikt bij componenten die mogelijk in de zichtbare viewport staan
2. Is moeilijker te onderhouden dan een simpele <script src="...">
3. Kan een layout shift introduceren

Methode 9: Gebruik readystatechange

document.readystate kan worden gebruikt als een alternatief voor het 'DOMContentloaded' en 'load' event. De 'interactive' readystate is meestal een goede plek om critical scripts aan te roepen die de DOM moeten veranderen of event handlers moeten toevoegen. 
De 'complete' ready state is een goede plek om scripts aan te roepen die minder kritiek zijn.

document.addEventListener('readystatechange', (event) => {
  if (event.target.readyState === 'interactive') {
    initLoader();
  } else if (event.target.readyState === 'complete') {
    initApp();
  }
});

Methode 10: Gebruik setTimeout zonder timeout

setTimeout is een afgekeurde maar zwaar onderschatte methode in de pagespeed community. setTimeout heeft een slechte reputatie gekregen omdat het vaak verkeerd wordt gebruikt.  Veel ontwikkelaars geloven dat setTimeout alleen kan worden gebruikt om de uitvoering van een script met een vastgesteld aantal milliseconden te vertragen. Hoewel dit waar is, doet setTimeout eigenlijk iets veel interessanters. Het creëert een nieuwe taak aan het einde van de event loop van de browser. Dit gedrag kan worden gebruikt om je taken effectief te plannen. Het kan ook worden gebruikt om lange taken op te splitsen in aparte, kleinere taken

<script>
   setTimeout(() => {
       // laad een script of voer een andere functie uit
       console.log('- Ik word aangeroepen vanuit een 0ms timeOut()')
    }, 0);

   console.log('- Ik stond als laatste in de rij maar werd als eerste uitgevoerd')

   /*
      Output:
      - Ik stond als laatste in de rij maar werd als eerste uitgevoerd
      - Ik word aangeroepen vanuit een 0ms timeOut()
   */
</script>

Wanneer te gebruiken:

setTimeout creëert een nieuwe taak in de event loop van de browser. Gebruik dit wanneer je main thread wordt geblokkeerd door veel functie-aanroepen die sequentieel draaien.

Voordelen:

1. Kan langlopende code opsplitsen in kleinere stukken.

Nadelen:

1. setTimeout is een vrij ruwe methode en biedt geen prioritering voor belangrijke scripts.
2. Zal de uit te voeren code aan het einde van de loop toevoegen

Methode 11: Gebruik setTimeout met een timeout

Dingen worden nog interessanter wanneer we setTimeout aanroepen met een timeout van meer dan 0ms

<script>
   setTimeout(() => {
       // laad een script of voer een andere functie uit
       console.log('- Ik word aangeroepen vanuit een 10ms timeOut()')
    }, 10);

   setTimeout(() => {
       // laad een script of voer een andere functie uit
       console.log('- Ik word aangeroepen vanuit een 0ms timeOut()')
    }, 0);

   console.log('- Ik stond als laatste in de rij maar werd als eerste uitgevoerd')

   /*
      Output:
      - Ik stond als laatste in de rij maar werd als eerste uitgevoerd
      - Ik word aangeroepen vanuit een 0ms timeOut()
      - Ik word aangeroepen vanuit een 10ms timeOut()
   */
</script>

Wanneer te gebruiken:

Wanneer je een makkelijke methode nodig hebt om het ene script na het andere te plannen, is een kleine timeout voldoende

Voordelen:

1. Ondersteund door alle browsers

Nadelen:

1. Biedt geen geavanceerde scheduling (planning)

Methode 12: Gebruik een promise om een microtask in te stellen

Het creëren van een micro-task is ook een interessante manier om JavaScript te plannen. Micro-tasks worden gepland voor uitvoering direct nadat de huidige executie-loop is voltooid.

<script>
   const myPromise = new Promise((resolve, reject) => {
      resolve();
   }).then(
      () => {
         console.log('- Ik was ingepland na een promise')
         }
   );

   console.log('- Ik stond als laatste in de rij maar werd als eerste uitgevoerd')

   /*
      Output:
      - Ik stond als laatste in de rij maar werd als eerste uitgevoerd
      - Ik was ingepland na een promise
   */
</script>

Wanneer te gebruiken:

Wanneer een taak onmiddellijk na een andere taak gepland moet worden. 

Voordelen:

1. De microtask zal direct nadat de taak is voltooid worden gepland.
2. Een microtask kan worden gebruikt om minder belangrijke stukjes JavaScript code in hetzelfde event te vertragen. 

Nadelen:

1. Zal de main thread niet opbreken in kleinere delen. De browser krijgt geen kans om te reageren op gebruikersinvoer.
2. Je zult waarschijnlijk nooit microtasks hoeven te gebruiken om de Core Web Vitals te verbeteren, tenzij je al precies weet wat je doet.

Methode 13: Gebruik een microtask

Hetzelfde resultaat kan worden bereikt door het gebruik van queueMicrotask(). Het voordeel van het gebruik van queueMicrotask() boven een promise is dat het iets sneller is en dat je je promises niet hoeft af te handelen.

<script>
   queueMicrotask(() => {
      console.log('- Ik ben een microtask')
   })

   console.log('- Ik stond als laatste in de rij maar werd als eerste uitgevoerd')

   /*
      Output:
      - Ik stond als laatste in de rij maar werd als eerste uitgevoerd
      - Ik ben een microtask
   */
</script>

Methode 14: Gebruik requestIdleCallback

De window.requestIdleCallback() methode zet een functie in de wachtrij om aangeroepen te worden tijdens de idle (inactieve) periodes van een browser. Dit stelt ontwikkelaars in staat om achtergrond- en lage prioriteit werk uit te voeren op de main event loop, zonder impact op latentie-kritieke events zoals animatie en input response. Functies worden over het algemeen in first-in-first-out volgorde aangeroepen; echter, callbacks die een timeout gespecificeerd hebben, kunnen buiten de normale volgorde worden aangeroepen indien nodig, om ze uit te voeren voordat de timeout verstrijkt.

<script>
requestIdleCallback(() => {
    const script = document.createElement('script');
    script.src = 'javascript.js';
    document.head.appendChild(script);
});
</script>

Wanneer te gebruiken:

Gebruik dit voor scripts die Nice to have zijn of om niet-kritieke taken af te handelen na gebruikersinvoer

Voordelen:

1. JavaScript uitvoeren met minimale impact voor de gebruiker
2. Zal hoogstwaarschijnlijk INP verbeteren

Nadelen:

1. Geen garantie dat de code ooit zal afvuren 

Methode 15: Gebruik postTask

De scheduler.postTask() methode stelt gebruikers in staat om optioneel een minimale vertraging op te geven voordat de taak zal draaien, een prioriteit voor de taak, en een signaal dat gebruikt kan worden om de taakprioriteit aan te passen en/of de taak af te breken. Het retourneert een promise die wordt opgelost (resolved) met het resultaat van de taak callback functie, of afgewezen (rejected) met de annuleringsreden of een fout die is opgetreden in de taak.

<script>
scheduler.postTask(() => {
    const script = document.createElement('script');
    script.src = 'javascript.js';
    document.head.appendChild(script);
}, { priority: 'background' });
</script>

Wanneer te gebruiken:

postTask is de juiste API om scripts mee te plannen wanneer je fijnmazige controle nodig hebt over prioriteit.

Voordelen:

1. Volledige controle over JavaScript uitvoeringsplanning (scheduling)!

Nadelen:

1. Niet ondersteund in Safari. Ondersteund in Chrome 94+, Edge 94+, en Firefox 142+. Gebruik feature detection en een setTimeout fallback voor volledige dekking.

Methode 16: Gebruik scheduler.yield()

scheduler.yield() is de nieuwste manier om lange taken op te splitsen. Het retourneert een promise die oplost in een nieuwe taak, wat de browser de kans geeft om te reageren op gebruikersinvoer tussen de stukken werk door. In tegenstelling tot setTimeout, krijgt de voortzetting prioriteit boven andere taken in de wachtrij, dus je code gaat verder waar deze was gebleven zonder achteraan in de rij te worden geplaatst.

<script>
async function processItems(items) {
    for (const item of items) {
        doWork(item);
        await scheduler.yield();
    }
}
</script>

Dit is de allerbeste tool voor het verbeteren van INP. Lange taken die de main thread voor honderden milliseconden blokkeren, kunnen worden opgesplitst in kleinere stukken, elk gescheiden door een yield punt. De browser kan gebruikersinvoer afhandelen op elk yield punt. Voor een praktische walkthrough van dit patroon, zie hoe te yielden (yield) naar de main thread.

Safari ondersteunt scheduler.yield() nog niet, dus neem altijd een fallback op:

<script>
function yieldToMain() {
    if (globalThis.scheduler?.yield) {
        return scheduler.yield();
    }
    return new Promise(resolve => {
        setTimeout(resolve, 0);
    });
}

async function processItems(items) {
    for (const item of items) {
        doWork(item);
        await yieldToMain();
    }
}
</script>

Wanneer te gebruiken:

Gebruik dit telkens wanneer je langlopende JavaScript hebt die de main thread blokkeert. Het is de aanbevolen aanpak voor het verbeteren van INP op interaction handlers en alle code die data in een loop verwerkt.

Voordelen:

1. Breekt lange taken op zonder je plaats in de wachtrij te verliezen
2. De voortzetting draait voor andere in de wachtrij geplaatste taken (in tegenstelling tot setTimeout, die achteraan in de rij sluit)
3. Verbetert INP direct door de browser de kans te geven te reageren op gebruikersinvoer

Nadelen:

1. Niet ondersteund in Safari. Ondersteund in Chrome 129+, Edge 129+, en Firefox 142+.
2. Vereist een fallback voor volledige browserdekking (setTimeout werkt als een polyfill)

Na het toepassen van deze technieken, verifieer de verbetering met Real User Monitoring. Lighthouse scores zijn een startpunt, maar velddata van echte gebruikers is wat Google gebruikt voor ranking. CoreDash volgt INP en alle Core Web Vitals van echte bezoekers, zodat je kunt zien of je defer strategie daadwerkelijk werkt in productie.