Interaction to Next Paint (INP): Wat het is, hoe je het meet en verbetert

Interaction to Next Paint (INP) is een Core Web Vital die meet hoe snel een webpagina reageert op gebruikersinteracties zoals klikken, tikken en toetsaanslagen. INP legt de volledige latentie vast van gebruikersinvoer via JavaScript-verwerking tot de uiteindelijke visuele update op het scherm. Een goede INP-score is 200 milliseconden of minder op het 75e percentiel. INP heeft First Input Delay (FID) vervangen als Core Web Vital in maart 2024.

Wat is Interaction to Next Paint (INP)?

Interaction to Next Paint (INP) is een Core Web Vital-metriek die de responsiviteit van een webpagina meet gedurende het hele bezoek van een gebruiker. In tegenstelling tot zijn voorganger First Input Delay (FID), die alleen de vertraging mat voordat de event handler van de eerste interactie begon, evalueert INP elke interactie die een gebruiker met de pagina maakt en rapporteert één enkele waarde die de algehele responsiviteit van de pagina weergeeft.

Elke keer dat een gebruiker op een knop klikt, op een link tikt, een toets op het toetsenbord indrukt of met een aangepast besturingselement interageert, meet de browser de totale tijd vanaf het moment van invoer tot wanneer het volgende frame op het scherm wordt getekend. INP selecteert een van de langzaamste van deze interacties als de responsiviteitsscore van de pagina. Voor pagina's met minder dan 50 totale interacties rapporteert INP de enkele slechtste interactie. Voor pagina's met veel interacties gebruikt INP doorgaans het 98e percentiel om incidentele uitschieters eruit te filteren.

Een lage INP betekent dat de pagina betrouwbaar en tijdig reageert op gebruikersinvoer. Een hoge INP betekent dat de pagina traag, niet-responsief of "schokkerig" aanvoelt omdat de browser interacties niet snel genoeg kan verwerken en het scherm niet snel genoeg kan bijwerken.

INP vs FID: Wat er veranderd is en waarom

INP heeft First Input Delay (FID) officieel vervangen als Core Web Vital in maart 2024. Google heeft FID stopgezet omdat het twee fundamentele beperkingen had die het een onvolledige maatstaf voor paginaresponsiviteit maakten.

Ten eerste mat FID alleen de eerste interactie op een pagina. Als de eerste klik van een gebruiker snel was maar opvolgende interacties traag waren, zou FID een goede score rapporteren ondanks de slechte ervaring. INP meet alle interacties gedurende de gehele sessie en biedt een veel nauwkeuriger beeld van de werkelijke responsiviteit.

Ten tweede mat FID alleen de input delay-fase, wat betekent dat het de tijd vastlegde die de browser besteedde aan wachten voordat hij begon met het verwerken van het event. Het negeerde volledig de tijd die werd besteed aan het uitvoeren van event handler-code (verwerkingstijd) en de tijd die nodig was om het visuele resultaat op het scherm te tonen (presentatievertraging). INP legt alle drie de fasen vast en geeft ontwikkelaars een compleet overzicht van de interactielatentie.

De overgang van FID naar INP veroorzaakte een daling van ongeveer 5 procentpunten in de mobiele Core Web Vitals-slagingspercentages, volgens het HTTP Archive Web Almanac 2025. Dit gebeurde omdat veel sites die responsief leken onder FID, trage latere interacties hadden die INP nu vastlegt.

Welke interacties meet INP?

INP meet alleen interacties met discrete gebruikersinvoer die de browser kan observeren via event handlers. Begrijpen welke interacties meetellen is essentieel voor nauwkeurig debuggen en optimaliseren.

Interacties die meetellen voor INP

• Muisklikken (inclusief klikken op knoppen, links, selectievakjes en aangepaste besturingselementen)
• Tikken op touchscreens (equivalent aan klikken op mobiele apparaten)
• Toetsaanslagen op een fysiek of schermtoetsenbord (inclusief typen in formuliervelden, op Enter drukken, sneltoetsen gebruiken)

Interacties die NIET meetellen voor INP

• Scrollen telt niet mee omdat het wordt afgehandeld door de compositor-thread van de browser en doorgaans de main thread niet blokkeert
• Hoveren (mouseover) telt niet mee omdat hoveren een continue aanwijzerstatus is, geen discrete gebruikersinteractie
• Sleepbewegingen tellen niet mee, hoewel de initiële pointerdown die een sleepbeweging start wel een INP-entry kan triggeren
• CSS-overgangen en animaties die zonder gebruikersinvoer plaatsvinden zijn geen interacties

Een veelvoorkomend misverstand is dat scrollen INP beïnvloedt. Dat is niet het geval. Als je pagina echter JavaScript-gebaseerd scrollen gebruikt in plaats van native browser-scrollen, kunnen die JavaScript scroll-handlers event callbacks triggeren die de browser als interacties meet. Dit is een reden waarom native CSS-scrollen qua responsiviteit consequent beter presteert dan JavaScript-scrollen.

De drie fasen van een INP-interactie

Elke interactie die door INP wordt gemeten bestaat uit drie opeenvolgende fasen. De totale INP-waarde is de som van alle drie. Het begrijpen van elke fase is cruciaal omdat de optimalisatiestrategie voor elk verschilt.

1. Input Delay

De input delay is de tijd tussen wanneer de gebruiker interageert met de pagina en wanneer de browser begint met het uitvoeren van de bijbehorende event handlers. Deze vertraging treedt op omdat de main thread van de browser bezig kan zijn met ander werk, zoals het parsen van JavaScript, het uitvoeren van eerder geplande taken, of het verwerken van andere event callbacks.

Input delay is vooral problematisch tijdens de laadpagina-fase wanneer veel scripts tegelijkertijd worden geparsed en uitgevoerd. CoreDash-data toont aan dat interacties tijdens de laadfase een p75 INP hebben van 132ms, vergeleken met slechts 50ms voor interacties na het volledig laden van de pagina. Dat is een 2,6x verschil. Het verminderen van main thread-concurrentie tijdens het opstarten van de pagina is een van de meest effectieve manieren om INP te verbeteren.

Op de mediaan is input delay het kleinste INP-onderdeel. Maar op het 90e percentiel wordt input delay de dominante factor omdat lange taken op de main thread de eventverwerking met honderden milliseconden kunnen vertragen. Het HTTP Archive Web Almanac 2025 stelde vast dat minder dan 25% van de websites de taakduur onder de aanbevolen drempel van 50ms houdt.

2. Verwerkingstijd

De verwerkingstijd is de totale tijd die de browser besteedt aan het uitvoeren van alle event handler-callbacks die bij de interactie horen. Dit omvat alle JavaScript die als reactie op het event wordt uitgevoerd, van formuliervalidatie tot statusupdates tot analytics tracking-aanroepen.

Verwerkingstijd vormt een aanzienlijk deel van de totale INP. Als een event handler dure DOM-operaties uitvoert, synchrone API-aanroepen doet, of inefficiënte loops draait, zal de verwerkingstijd opblazen. Een veelvoorkomend patroon dat de verwerkingstijd opblaast is het uitvoeren van niet-essentiële code (zoals analytics events of callbacks van third-party tags) binnen dezelfde event handler als de kritieke visuele update.

3. Presentatievertraging

De presentatievertraging is de tijd tussen wanneer alle event handlers klaar zijn met uitvoeren en wanneer de browser het volgende frame presenteert met de visuele update. Deze fase omvat stijlherberekening, layoutberekening, schilderen en compositing.

Op de mediaan is presentatievertraging het grootste INP-onderdeel omdat elke interactie minstens één renderingpass vereist. Pagina's met een groot of diep genest DOM hebben meer tijd nodig voor stijlherberekening en layout. Single Page Applications die grote componentbomen herrenderen na statuswijzigingen zijn bijzonder gevoelig voor hoge presentatievertraging.

Wat zijn goede en slechte INP-scores?

Om de Core Web Vitals-beoordeling voor de Interaction to Next Paint-metriek te halen, moet het 75e percentiel van alle in het veld geregistreerde interacties onder de 200 milliseconden blijven:

• Een INP onder of op 200 milliseconden betekent dat je pagina een goede responsiviteit heeft.
• Een INP tussen 200 en 500 milliseconden betekent dat de responsiviteit van je pagina verbetering nodig heeft.
• Een INP boven 500 milliseconden betekent dat je pagina een slechte responsiviteit heeft.

Het is belangrijk om te begrijpen dat INP het 75e percentiel gebruikt, niet het gemiddelde. Dit betekent dat 75% van je echte gebruikers interacties sneller dan 200ms moeten ervaren. De 75e-percentiel-methodologie zorgt ervoor dat de metriek de ervaring weerspiegelt van gebruikers op langzamere apparaten en verbindingen, niet alleen van gebruikers met high-end hardware.

Hoe meet je Interaction to Next Paint (INP)?

Interaction to Next Paint kan alleen worden gemeten met veldtools die echte gebruikersinteracties vastleggen. In tegenstelling tot labmetrieken die een enkel paginabezoek simuleren, vereist INP daadwerkelijke bezoekers die op je pagina's klikken, tikken en typen. Er is geen manier om een zinvolle INP-score te krijgen uit een synthetische test omdat INP afhankelijk is van echt menselijk gedrag.

De officiële INP-metrieken ophalen

Je kunt de officiële INP-metrieken ophalen bij PageSpeed Insights of het CrUX-dashboard en Google BigQuery. PageSpeed Insights rapporteert de 75e-percentiel-score op basis van de laatste 28 dagen Chrome-gebruikersdata. Google BigQuery biedt meer historische context en maakt aangepaste queries over de gehele CrUX-dataset mogelijk.

Google Search Console rapporteert ook INP-problemen onder het Core Web Vitals-gedeelte, groepeert getroffen URL's en markeert pagina's die verbetering nodig hebben of een slechte responsiviteit hebben.

INP volgen met Real User Monitoring

Hoewel de officiële CrUX-dataset de definitieve bron is voor Core Web Vitals-scores, is deze sterk geanonimiseerd en ondersteunt het geen realtime monitoring of gedetailleerd filteren. Daarom vertrouwen webperformance-professionals op Real User Monitoring (RUM)-tools zoals CoreDash om praktische, realtime INP-data te krijgen. RUM-tools verzamelen INP-metingen van elk paginabezoek, koppelen ze aan specifieke elementen, laadstatussen en apparaattypen, en stellen je in staat om precies te diagnosticeren welke interacties problemen veroorzaken.

INP meten voor de huidige sessie

De eenvoudigste manier om INP te debuggen tijdens ontwikkeling is via Chrome DevTools. Open het Performance-paneel en gebruik de "tijdspanne"-modus in Lighthouse om interacties op te nemen en hun latentie te zien. Je kunt ook de Core Web Vitals Visualizer-extensie gebruiken, die INP-scores over de pagina toont terwijl je ermee interageert.

Voor hands-on debugging gebruik je de Google Web Vitals JavaScript Library om individuele interacties naar de console te loggen:

Log de INP naar de console met de Web Vitals JavaScript Library

<script type="module">
 import {onINP}
 from 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.js?module';
 onINP(console.log);
</script>

Hoe verbeter je Interaction to Next Paint?

Het verbeteren van Interaction to Next Paint vereist het optimaliseren van alle drie de fasen: input delay, verwerkingstijd en presentatievertraging. Je pagina reageert misschien direct op de meeste interacties, maar als zelfs één interactie traag is, kan die de gehele INP-score bepalen. Daarom is een systematische aanpak nodig.

PageSpeed TIP: meestal is de INP veel slechter wanneer een gebruiker interageert met de pagina tijdens de opstartfase van het laden van de pagina. Daarom is het bij het debuggen van INP zinvol om alle interacties én de paginalaadstatus te loggen!

1. Input Delay minimaliseren: voorkom lange taken op de main thread

Normaal gesproken is elke pagina minder responsief tijdens de opstartfase, wanneer het meeste main thread-werk plaatsvindt (parsen, decoderen, renderen en scripting). Om de main thread zo vrij mogelijk te houden:

• Verwijder ongebruikte code. Gebruik tree shaking om dode code te verwijderen en code splitting om je bundel op te splitsen in kleinere stukken die on-demand worden geladen. Controleer je code-dekking met Chrome DevTools om scripts te identificeren die worden geladen maar nooit worden uitgevoerd.
• Laad niet-essentiële code tijdens de idle-tijd van de browser. Heb je echt een chatwidget nodig tijdens de eerste 500ms van het laden van de pagina? Plan niet-kritieke scripts met requestIdleCallback() zodat ze alleen worden uitgevoerd wanneer de browser inactief is.
• Identificeer en herschrijf trage scripts die buitensporig veel CPU-bronnen verbruiken. Gebruik het Chrome Performance-paneel om scripts met lange uitvoeringstijden te vinden en richt je op die voor optimalisatie.
• Houd je pagina eenvoudig te renderen. Vermijd grote DOM-afmetingen, overmatig veel afbeeldingen, te veel video's en CPU-intensieve CSS-animaties.
• Gebruik async en defer op script-tags om te voorkomen dat JavaScript de HTML-parser blokkeert. Overweeg om niet-kritiek JavaScript uit te stellen totdat de pagina interactief is geworden.

Splits lange taken op met scheduler.yield()

JavaScript draait op de main thread van de browser volgens het "run-to-completion"-model: zodra een taak start, blokkeert deze de main thread totdat deze klaar is. Lange taken (meer dan 50ms) verhinderen dat de browser op gebruikersinvoer reageert. De scheduler.yield() API stelt je in staat om expliciet yield-punten te creëren binnen langlopende code, waardoor de browser de kans krijgt om openstaande gebruikersinteracties te verwerken voordat hij verdergaat.

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  // Fallback for browsers without scheduler.yield()
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

// Usage: break up a long task into smaller chunks
async function processLargeDataSet(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // Yield every 5 items to let the browser handle user input
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

Stel niet-kritiek werk uit met requestIdleCallback

Gebruik requestIdleCallback() om niet-essentiële taken (analytics, telemetrie, prefetching) in te plannen voor wanneer de browser inactief is. Dit houdt de main thread vrij voor gebruikersinteracties en vermindert de input delay direct.

// Instead of running analytics synchronously:
document.querySelector('.cta-button').addEventListener('click', (e) => {
  // Critical: update the UI immediately
  showConfirmation();

  // Non-critical: send analytics during idle time
  requestIdleCallback(() => {
    sendAnalyticsEvent('cta_clicked', { page: location.pathname });
  }, { timeout: 2000 });
});

Gebruik passive event listeners

Voor events die preventDefault() niet hoeven aan te roepen, markeer je event listeners als passief. Dit vertelt de browser dat hij niet hoeft te wachten tot je handler beslist of het standaardgedrag moet worden geannuleerd, wat zorgt voor soepeler scrollen en snellere touch-respons.

// Passive listener: browser does not wait for preventDefault()
document.addEventListener('touchstart', handleTouch, { passive: true });
document.addEventListener('wheel', handleWheel, { passive: true });

2. Verwerkingstijd minimaliseren: geef onmiddellijke feedback

Wanneer een bezoeker een actie uitvoert zoals het verzenden van een formulier of het toevoegen van een item aan de winkelwagen, wacht dan niet op de serverbevestiging voordat je de UI bijwerkt. Geef onmiddellijke visuele feedback ("Formulier wordt verzonden...", "Item wordt toegevoegd aan winkelwagen...") en voltooi de operatie dan op de achtergrond.

Geef ook de main thread zo snel mogelijk vrij na de kritieke visuele update. Omdat JavaScript het "run-to-completion"-model volgt, blokkeert het de main thread totdat alle code in de callback is uitgevoerd. Je kunt handmatig een yield-punt creëren waar de browser de layout kan bijwerken en vervolgens de resterende niet-kritieke code kan uitvoeren.

const formfeedbackEl = document.getElementById("formfeedback");
const formEl = document.getElementById("form");

formEl.addEventListener("submit", (evt) => {
  evt.preventDefault();
  formfeedbackEl.innerText = "Submitting form ... please hold on";

  let headers = new Headers({ Accept: "application/json" });
  let formData = new FormData(formEl);
  fetch("/form-endpoint", { method: "POST", headers, body: formData })
    .then(function (response) {
      return response.json();
    })
    .then(function (jsonData) {
      formEl.reset();
      formfeedbackEl.innerText = jsonData.message;
    });
   setTimeout(other_code_that_needs_to_run(), 0);
});

3. Presentatievertraging minimaliseren: houd het simpel

Wanneer de pagina na een interactie moet worden bijgewerkt, moet de browser stijlen herberekenen, layout uitvoeren, de gewijzigde pixels schilderen en het resultaat compositen. De complexiteit en grootte van je DOM bepaalt direct hoe lang dit renderwerk duurt.

Sommige slecht geoptimaliseerde SPA-omgevingen herrenderen na elke interactie veel te veel content. Wanneer je bijvoorbeeld een teller bijwerkt, zorg er dan voor dat je alleen het tellerelement bijwerkt, niet de gehele componentboom.

Volg deze twee gouden regels voor snellere rendering:

1. Houd het DOM klein en eenvoudig. Het is veel makkelijker voor een browser om een pagina te renderen met minder DOM-elementen (HTML-nodes) dan een pagina met diep geneste, ingewikkelde DOM-structuren. Streef naar minder dan 1.400 DOM-elementen totaal en vermijd nesting dieper dan 32 niveaus.
2. Gebruik content-visibility voor lazy rendering van off-screen content. De CSS-eigenschap content-visibility: auto versnelt de initiële rendering door de rendering van off-screen content uit te stellen totdat de gebruiker in de buurt scrollt.

/* Apply content-visibility to off-screen sections */
.below-the-fold {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

INP debuggen met de Long Animation Frames (LoAF) API

De Long Animation Frames (LoAF) API is een krachtig hulpmiddel voor het diagnosticeren van INP-problemen. Het biedt gedetailleerde informatie over frames die langer dan 50ms nodig hebben om te renderen, inclusief script-attributiedata die je precies vertelt welke scripts bijdragen aan trage interacties.

In tegenstelling tot de oudere Long Tasks API legt LoAF zowel de renderingtijd als de scriptuitvoeringstijd vast, waardoor het bijzonder nuttig is voor het diagnosticeren van presentatievertraging. LoAF-entries bevatten de frameduur, de blokkeringsduur en een array van scriptentries die de bron-URL, functienaam en uitvoeringstijd tonen van elk script dat tijdens het frame is uitgevoerd.

// Observe Long Animation Frames to find INP bottlenecks
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Only look at frames longer than 100ms
    if (entry.duration > 100) {
      console.log('Long frame:', entry.duration + 'ms');

      // Log each script that contributed
      for (const script of entry.scripts) {
        console.log(
          'Script:', script.sourceURL,
          'Function:', script.sourceFunctionName,
          'Duration:', script.duration + 'ms'
        );
      }
    }
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

RUM-tools zoals CoreDash integreren LoAF-data automatisch en correleren lange animatieframes met specifieke gebruikersinteracties, zodat je precies kunt identificeren welk script, op welke pagina, voor welk type interactie je slechtste INP-scores veroorzaakt.

INP en LCP: de lange-taken-connectie

Lange taken op de main thread beïnvloeden zowel INP als Largest Contentful Paint (LCP). Een JavaScript-taak die de main thread 200ms blokkeert, vertraagt de eventverwerking (verslechtert INP) en voorkomt ook dat de browser het LCP-element rendert (verslechtert LCP). Wanneer je je main thread optimaliseert door lange taken op te splitsen, niet-kritiek JavaScript uit te stellen en de scriptuitvoeringstijd te verminderen, verbeter je beide metrieken tegelijkertijd.

Casestudies: INP-verbeteringen in productie

redBus: 80 tot 100% verbetering van mobiele conversie

redBus, een van 's werelds grootste online busticketplatforms, investeerde in Core Web Vitals-optimalisatie in hun wereldwijde markten. Hun focus op het verminderen van JavaScript-uitvoeringstijd en het optimaliseren van event handlers droeg bij aan een 80 tot 100% verbetering van de mobiele conversiepercentages in hun wereldwijde markten. De verbeteringen werden gedreven door een combinatie van het verminderen van main thread-blokkeringstijd, het optimaliseren van het laden van third-party scripts en het implementeren van code splitting om de hoeveelheid JavaScript die tijdens het opstarten van de pagina wordt geparsed te verminderen.

Preply: INP van 250ms naar 185ms, geschatte SEO-besparing van $200.000 per jaar

Preply, een online platform voor taalonderwijs, verbeterde hun Homepage-INP van ongeveer 250ms naar 185ms en hun Zoekpagina-INP van ongeveer 250ms naar 175ms. Het team bereikte deze winsten door het profileren van hun React-applicatie, het identificeren en elimineren van onnodige re-renders, en het uitstellen van niet-kritieke event callbacks. De verbeterde Core Web Vitals-scores correleerden met hogere zoekposities, wat zich vertaalde in een geschatte waarde van $200.000 per jaar aan organische zoekwaarde.

Wat echte data laat zien over INP

Het verschil tussen mobiel en desktop INP

CoreDash-data onthult dat mobiele INP (131ms op p75) 2,8 keer slechter is dan desktop INP (48ms op p75). Dit is het grootste apparaatverschil van alle Core Web Vital-metrieken. Mobiele apparaten hebben langzamere processors, minder geheugen en hogere netwerklatentie, wat allemaal bijdraagt aan langere main thread-blokkeringstijden en tragere eventverwerking. Op desktop bereikt 95,6% van de interacties een "goede" INP-score, terwijl op mobiel dat percentage daalt naar 88,0%. Mobiele gebruikers ervaren ook 5 keer meer "slechte" INP-events (9,6% vs. 1,9%).

Toetsenbord- vs. aanwijzerinteracties

CoreDash-data toont aan dat toetsenbordinteracties (75ms p75) 56% trager zijn dan aanwijzerinteracties (49ms p75). Toetsenbord-events hebben ook significant meer slechte ervaringen: 7,4% van de toetsenbordinteracties resulteert in een slechte INP, vergeleken met slechts 1,4% voor aanwijzerinteracties. Dit verschil komt waarschijnlijk doordat toetsenbord-events, vooral in formuliervelden, complexere verwerking triggeren zoals invoervalidatie, autocomplete-suggesties en statusupdates.

Interacties tijdens het laden vs. na het laden

Interacties die plaatsvinden tijdens het laden van de pagina hebben een dramatisch hogere INP dan die na het volledig laden van de pagina. CoreDash-data toont aan dat interacties tijdens de "laadfase" een p75 INP hebben van 132ms, vergeleken met slechts 50ms voor interacties na het laden. Dat is een 2,6 keer verschil. Zelfs interacties tijdens de "dom-content-loaded"-fase (75ms) tonen verhoogde INP-waarden omdat asynchrone scripts en subbronnen nog worden verwerkt. Deze data ondersteunt nadrukkelijk de aanbeveling om niet-kritiek JavaScript uit te stellen om main thread-concurrentie tijdens het opstarten van de pagina te verminderen.

Wereldwijde INP-slagingspercentages

Volgens het HTTP Archive Web Almanac 2025 bereikt 77% van alle mobiele pagina's een "goede" INP-score (tegenover 55% in 2022). Echter, slechts 53% van de top 1.000 meestbezochte websites haalt INP. Websites met veel verkeer hebben doorgaans complexer JavaScript, meer third-party scripts en ingewikkeldere DOM-structuren, wat allemaal bijdraagt aan slechtere responsiviteit. Op desktop bereikt 97% van de pagina's goede INP-scores, wat het enorme verschil in prestaties tussen mobiel en desktop benadrukt. De mediane Total Blocking Time in labtests is 67ms op desktop maar 1.209ms op mobiel.

Veelgestelde vragen

Gerelateerde gidsen

Deze overzichtspagina behandelt de basisprincipes van Interaction to Next Paint. Voor diepgaande begeleiding bij specifieke aspecten van INP-optimalisatie kun je deze specifieke artikelen verkennen:

• <strong>INP-problemen vinden en oplossen</strong>: Een stapsgewijze diagnostische methodologie met Search Console, RUM-data en Chrome DevTools om precies te identificeren welke interacties je slechtste INP-scores veroorzaken.
• <strong>INP Input Delay</strong>: Behandelt de eerste fase van INP. Leer hoe lange taken op de main thread eventverwerking blokkeren en hoe je input delay minimaliseert met taakplanning, code splitting en web workers.
• <strong>INP Verwerkingstijd</strong>: Behandelt de tweede fase van INP. Leer hoe je event handler-callbacks optimaliseert, kritieke code prioriteert, niet-essentieel werk uitstelt en React-concurrency-functies gebruikt om verwerkingstijd te verminderen.
• <strong>INP Presentatievertraging</strong>: Behandelt de derde fase van INP. Leer hoe DOM-grootte, layout thrashing en client-side rendering bijdragen aan trage visuele updates en hoe je presentatievertraging vermindert.

Deze PageSpeed-optimalisatiegidsen kunnen ook nuttig zijn voor het verbeteren van INP:

• INP verbeteren: stop met JavaScript-scrollen
• Async vs Defer: JavaScript-laadstrategieën
• 14 methoden om JavaScript uit te stellen
• Chatwidget met perfecte Core Web Vitals
• Fix: vermijd buitensporige DOM-grootte