Verbeter Interaction to Next Paint (INP)

Leer over Interaction to Next Paint (INP) en hoe je dit verbetert

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-21

Wat is Interaction to Next Paint (INP)?

Interaction to Next Paint (INP) is een relatief nieuwe en spannende metriek die de responsiviteit van een webpagina meet gedurende alle interacties op een pagina. Een lage Interaction to Next Paint zorgt ervoor dat de pagina te allen tijde betrouwbaar responsief is. De INP wordt een Core Web Vital in maart 2024, wanneer Google de FID-metriek vervangt door de INP-metriek.

Om de Interaction to Next Paint metriek te berekenen, worden alle verschillen tussen elke gebruikersinteractie en de uiteindelijke presentatiewijziging op de pagina opgeslagen. Het hoogste getal van alle interacties (of het 98e percentiel) wordt de uiteindelijke Interaction to Next Paint (INP) metriek.

98e percentiel of de slechtste INP?

INP is een metriek die tot doel heeft de algehele interactievertraging van een pagina weer te geven door een van de langste interacties te selecteren die optreden wanneer een gebruiker een pagina bezoekt. Voor pagina's met minder dan 50 interacties in totaal is INP de interactie met de slechtste latentie. Voor pagina's met veel interacties is INP meestal het 98e percentiel van de interactielatentie.

Hoe werkt Interaction to Next Paint (INP) precies?

Een interactie vindt plaats wanneer een bezoeker op een pagina klikt of tikt. Die interactie kan resulteren in een verandering in presentatie op het scherm. De Interaction to Next Paint (INP) meet de tijd tussen de klik en de presentatie.

De latentie van een enkele interactie bestaat uit de enkele langste duur van een gebeurtenis die deel uitmaakt van de interactie, waarbij de duur wordt gemeten vanaf het punt waarop de gebruiker interactie had met de pagina totdat het volgende frame wordt gepresenteerd nadat alle bijbehorende event handlers zijn uitgevoerd. De duur is de som van de volgende tijdsduren:

  • De input delay, wat de tijd is tussen wanneer de gebruiker interactie heeft met de pagina en wanneer event handlers worden uitgevoerd.
  • De processing time, wat de totale hoeveelheid tijd is die nodig is om code in bijbehorende event handlers uit te voeren.
  • De presentation delay, wat de tijd is tussen wanneer event handlers klaar zijn met uitvoeren en wanneer de browser het volgende frame presenteert.
  • Wat zijn goede en slechte waarden van de Interaction to Next Paint (INP)?

    Om te slagen voor de Core Web Vitals voor de Interaction to Next Paint metriek moet het 75e percentiel van het laden van pagina's opgenomen in de praktijk onder de 200ms 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.

    Hoe meet je de Interaction to Next Paint (INP)?

    De Interaction to Next Paint kan alleen worden gemeten met veldtools. Om de Interaction to Next Paint te meten hebben we echte gebruikersinteractie nodig. Google meet alle interacties die echte Chrome gebruikers hebben met een pagina en slaat dit op in de CrUX dataset. De CrUX dataset is de officiële dataset voor de Core Web Vitals.

    Verkrijg de officiële INP statistieken

    Je kunt de officiële INP statistieken verkrijgen in PageSpeed Insights of het CrUX dashboard en Google BigQuery. PageSpeed Insights geeft je de 75e percentiel score voor de laatste 28 dagen. Google BigQuery (via Data Studio) geeft je meer historische context.

    De Interaction to Next Paint volgen met Real User Monitoring

    Hoewel de officiële CrUX dataset de uiteindelijke bron is voor Interaction to Next Paint statistieken, is de CrUX dataset niet echt bruikbaar omdat deze sterk geanonimiseerd is. De CrUX dataset biedt geen real-time monitoring en staat ook niet veel filtering toe. Daarom vertrouwen web performance consultants doorgaans op Real User Monitoring.

    Meet de Interaction to Next Paint van de huidige sessie.

    De eenvoudigste manier om de Interaction to Next Paint te debuggen is via Lighthouse in 'timespan' modus.  Je kunt ook de Core Web Vitals Visualizer gebruiken, of als je handig bent met de Google Web Vitals JavaScript Library

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

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

    Hoe de Interaction to Next Paint verbeteren?

    De Interaction to Next Paint is een gecompliceerde metriek. Je pagina kan voor het grootste deel echt snel zijn en direct reageren. Helaas, als slechts één interactie traag is, zal dit de volledige Interaction to Next Paint beïnvloeden.

    Onthoud nu, de INP kan worden opgesplitst in de input delay, processing time en de presentation delay.

    PageSpeed TIP: meestal zal de INP veel slechter zijn wanneer een gebruiker interactie heeft met de pagina tijdens de opstartfase van het laden van de pagina.  Daarom is het bij het debuggen van de INP zinvol om zowel alle interacties als de ladingsstatus van de pagina te loggen!

    1. Minimaliseer de input delay - voorkom lange taken op de main thread

    Meestal is elke pagina minder responsief tijdens de opstartfase van de pagina. Dat is wanneer het meeste werk op de main thread wordt gedaan (parsing, decoding, rendering en scripting).  Om de main thread zo vrij mogelijk te houden, overweeg:

    • Verwijder ongebruikte code. Dit kan worden gedaan via een proces genaamd tree shaking (verwijderen van ongebruikte code) en code splitting (je code zo bundelen dat deze gegroepeerd is in veel kleine bundels die kunnen worden geladen als ze nodig zijn). 
    • Laad niet-essentiële code tijdens browser idle. Bijvoorbeeld, heb je echt een chat widget nodig tijdens de eerste 500ms van het laden van de pagina? Nee, waarschijnlijk niet!
    • Identificeer trage scripts die veel bronnen vereisen en herschrijf de code om deze efficiënter te maken.
    • Zorg ervoor dat je pagina 'gemakkelijk te renderen' is. Vermijd grote DOM-afmetingen, te veel of enorme afbeeldingen, te veel video's, CSS-animaties enz.

    2. Minimaliseer de processing time - geef directe feedback om ervoor te zorgen dat de pagina direct reageert op gebruikersinvoer

    Wanneer een bezoeker een actie uitvoert, zoals het verzenden van een formulier of het toevoegen van een winkelitem aan een mandje, wacht dan niet op de server-side bevestiging (je formulier is verzonden, je items zijn toegevoegd aan het mandje) maar geef directe feedback (we versturen je formulier, voegen itemX toe aan mandje). 

    Geef ook zo snel mogelijk prioriteit aan de main thread. Omdat JavaScript dit ding doet dat 'run to completion' heet, blokkeert het de main thread totdat alle code is uitgevoerd. Je kunt handmatig een breekpunt creëren waar de browser de lay-out kan bijwerken (en vervolgens de rest van de code kan voortzetten) door 'te yielden aan de main thread.' De eenvoudigste manier om dit te doen is door delen van de code in een setTimeout() te verpakken

    const formfeedbackEl = document.getElementById("formfeedback");
    const formEl = document.getElementById("form");
    
    formEl.addEventListener("submit", (evt) => {
      evt.preventDefault();
      formfeedbackEl.innerText = "Formulier indienen... een ogenblik geduld";
    
      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. Minimaliseer presentation delay - houd het simpel!

    Wanneer de pagina moet worden bijgewerkt, gebeurt het volgende. Eerst wordt het deel van de pagina dat moet worden bijgewerkt opnieuw gerenderd. De browser zal dan de nieuwe content schilderen (paint) en naar het presentatiedeel van de browser sturen (Composite GPU en Raster).

    Sommige (slecht gecodeerde) SPA-omgevingen zullen veel te veel content opnieuw renderen na interactie. Bijvoorbeeld, wanneer je een teller bijwerkt, zorg er dan voor dat je alleen de teller bijwerkt en niet het hele component.

    Om het voor een pagina gemakkelijker te maken om (opnieuw) te renderen, volg deze 2 gouden regels:
    1. Houd de DOM klein en simpel. In feite zal het voor een browser veel gemakkelijker zijn om een pagina met minder DOM-elementen (html nodes) te renderen dan voor een browser om een pagina met veel geneste en gecompliceerde DOM nodes te renderen.
    2. Gebruik content-visibility om off-screen content lui te renderen (lazy-render).  Content-visibility zal het renderen van zichtbare delen van de pagina versnellen door het renderen van off-screen content uit te stellen door die off-screen content just-in-time te renderen.

    The RUM tool I built for my own clients.

    CoreDash is what I use to audit enterprise platforms. Under 1KB tracking script, EU hosted, no consent banner. AI with MCP support built in. The same tool, available to everyone.

    Create Free Account
    Verbeter Interaction to Next Paint (INP)Core Web Vitals Verbeter Interaction to Next Paint (INP)