Vind en los Interaction to Next Paint (INP) problemen op: Een stapsgewijze gids
Leer hoe je Interaction to Next Paint problemen identificeert en oplost met behulp van RUM data, Chrome DevTools en de LoAF API
Vind en los Interaction to Next Paint (INP) problemen op
Deze pagina maakt deel uit van onze Interaction to Next Paint (INP) serie. INP meet de responsiviteit van je website door de vertraging tussen een gebruikersinteractie en de volgende visuele update bij te houden. Een goede INP-score is minder dan 200 milliseconden, terwijl scores boven 500 milliseconden als slecht worden beoordeeld. Als INP nieuw voor je is, begin dan met de INP hub-pagina voor een compleet overzicht.
Volgens de 2025 Web Almanac faalt 23% van de mobiele origins nog steeds op INP. Als jouw site er daar één van is, is dit het proces: bevestig het probleem in Search Console, diagnosticeer de grondoorzaken met Real User Monitoring (RUM) data, repliceer het lokaal en pas gerichte fixes toe voor elke INP-fase.
INP TIP: meestal zal de INP veel slechter
zijn wanneer een gebruiker met de pagina interageert tijdens de opstartfase van het
laden van de pagina. Daarom is het, bij het debuggen van de INP,
logisch om zowel alle interacties als de laadstatus van de pagina te loggen!
Table of Contents!
Stap 1: Controleer de INP in Search Console
De eerste stap is bevestigen dat je daadwerkelijk een INP probleem hebt. Voordat je codewijzigingen doorvoert, moet je het probleem verifiëren in Google Search Console, zodat je werkt op basis van echte velddata in plaats van aannames.
Log in op je Google Search Console. Klik in het linkermenu op Core Web Vitals en selecteer Mobiel of Desktop (tip: meestal komen INP-problemen eerst aan het licht op mobiel, dus begin met mobiel).
Hier zie je een overzicht van alle Core Web Vitals gerelateerde problemen die momenteel op je site aanwezig zijn. Als een van deze problemen INP gerelateerd is, heb je bevestigd dat er een probleem is.
Stap 2: Identificeer Interaction to Next Paint problemen
Google Search Console geeft je geen informatie, afgezien van URL-groepen, om te achterhalen wat de problemen met de Interaction to Next Paint veroorzaakt. Dus meestal gaan developers er blind in. Ze beginnen met het verwijderen van ongebruikte JavaScript (altijd een goed idee) en het opbreken van de main thread (ook een goed idee), maar dat lost de INP zelden volledig op.
Daarom moeten we, bij het verbeteren van de INP, precies weten wat er aan de hand is. We hebben antwoord nodig op vier cruciale vragen:
Welke elementen, wanneer ermee gecommuniceerd wordt, veroorzaken een slechte INP-score?
Meestal wordt een slechte INP-score niet veroorzaakt door één enkel element, maar door een combinatie van problemen. We moeten
ze één voor één aanpakken, beginnend met de ergste en zo verder naar
boven.
Wanneer vinden deze interacties plaats? Gebeuren ze
tijdens de opstartfase van het
laden van de pagina, of gebeuren ze zelfs wanneer de hoofdpagina volledig is geladen?
Waar vinden deze
interacties plaats? Gebeuren ze op elke pagina, of gebeuren ze
alleen op een paar geselecteerde pagina's?
Hoe kunnen we
deze interacties repliceren? Je bent er misschien inmiddels achter gekomen dat het
moeilijk is om INP-problemen te repliceren. Daarom moeten we onszelf klaarmaken voor succes door
apparaatkenmerken na te bootsen die een slechte INP-score hebben.
Stel RUM tracking in
Om al deze vragen te beantwoorden, moeten we beginnen met het tracken van echte gebruikers en eventuele problemen loggen die
zich kunnen voordoen met de Interaction to Next Paint. Er zijn verschillende manieren om RUM tracking in te schakelen. De
eerste is door de Web Vitals bibliotheek te gebruiken en de resultaten naar je eigen analytics backend te sturen.
Het voordeel van deze methode is dat het goedkoop en flexibel is. Het nadeel is dat het een hoop
extra werk kan zijn.
Een goed alternatief voor het sturen van je Core Web Vitals data naar je eigen backend is het gebruik van een van de vele RUM tools die er zijn. We hebben CoreDash speciaal voor deze use cases ontwikkeld. CoreDash is een betaalbare, snelle en effectieve RUM tool die de klus klaart. Natuurlijk zijn er veel RUM oplossingen beschikbaar en die zullen de klus ook klaren (zij het vaak tegen een hogere prijs).
Vind trage interacties per element die een hoge INP veroorzaken
Begin met het vinden van de traagste interacties die de slechtste INP-scores veroorzaken. Sorteer je pagina's op "INP metric by Elements" in CoreDash en je krijgt je traagste interacties te zien. Klik op de eerste regel om je statistieken op deze interacties te filteren.
Ontdek wanneer slechte INP-interacties optreden
Sorteer vervolgens de gefilterde URL's op laadstatus. Dit geeft je meer inzicht in de grondoorzaak van de INP. In dit geval gebeurt de hoge INP wanneer de DOM content is geladen. Dit betekent dat scripts zijn geparsed, maar dat async scripts en de sub-resources van de pagina nog niet zijn geladen. In dit geval wordt de INP veroorzaakt door vroege klikken wanneer het laden van de pagina nog niet volledig is voltooid.
Ga verder door op de laadstatus met de hoogste impact te klikken om nog een filter aan te maken.
Vind URL's die verantwoordelijk zijn voor hoge INP-scores
Tot slot, wanneer we hebben gefilterd op de elementen met de traagste interactie en de juiste laadstatus, gaan we kijken naar de URL's waar de INP op zijn slechtst is. In dit geval gebeurt dit duidelijk op een specifieke set pagina's.
Vind apparaatkenmerken
Wanneer we trage interacties, laadstatus en URL's hebben geïdentificeerd die een hoge Interaction to Next Paint veroorzaken, gaan we kijken naar welke soorten bezoekers de slechtste INP-scores veroorzaken. We zouden kijken naar Device Memory, bandbreedte, schermgrootte en andere hardwarekenmerken. Zodra we deze kenmerken hebben geïdentificeerd, kunnen we verdergaan met het repliceren en loggen van het probleem.
De Long Animation Frames (LoAF) API gebruiken voor INP diagnostiek
De Long Animation Frames API (LoAF) vertelt je precies welke scripts en functies trage interacties veroorzaken. In tegenstelling tot de oudere Long Tasks API, geeft LoAF je script-URL's, functienamen en timing breakdowns per frame. Het is vooral nuttig in combinatie met RUM data van een tool zoals CoreDash.
Deze observer verzamelt LoAF-items voor frames langer dan 50ms, en legt scriptattributie, duur en blokkeringstijd vast:
// Observeer Long Animation Frames voor INP-attributie
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// Log alleen frames langer dan 50ms
if (entry.duration > 50) {
console.log('Long Animation Frame:', {
duration: entry.duration,
blockingDuration: entry.blockingDuration,
renderStart: entry.renderStart,
styleAndLayoutStart: entry.styleAndLayoutStart,
scripts: entry.scripts.map(script => ({
sourceURL: script.sourceURL,
sourceFunctionName: script.sourceFunctionName,
invokerType: script.invokerType,
invoker: script.invoker,
duration: script.duration
}))
});
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
De LoAF API onthult welke scripts bijdragen aan elke fase van de INP. De scripts array vertelt je het exacte bronbestand en de functienaam, terwijl renderStart en styleAndLayoutStart je helpen de processing time te scheiden van de presentation delay. LoAF is momenteel alleen beschikbaar in Chromium (Chrome 123+), dus voor het debuggen in Firefox en Safari moet je vertrouwen op de Performance panel trace en RUM data. Voor meer informatie over hoe async vs defer JavaScript laden deze timings beïnvloedt, zie onze uitgebreide gids.
Stap 3: Repliceer en debug interacties die een hoge INP-score veroorzaken
Met deze data in de hand kunnen we beginnen met het oplossen van de grondoorzaken.
Maak jezelf klaar voor succes: repliceer de omstandigheden waarin de INP faalt
Het volgende dat we moeten doen is proberen de falende INP te reproduceren. We doen dit door de omstandigheden na te bootsen waarin de INP mogelijk faalt.
Gebruik het Chrome Performance Panel: Open de Chrome developer tools (Ctrl+Shift+I) en selecteer het
performance paneel. In de bovenste balk kun je de CPU Throttle selecteren (throttle het naar 4x slowdown om
een normaal mobiel apparaat te emuleren), de Network Throttle (selecteer de fast 3G preset om je
gemiddelde mobiele apparaat na te bootsen), en stel de hardware concurrency in op 4 of 8 om je gemiddelde mobiele apparaat te imiteren.
Om Chrome te laden met minder beschikbaar geheugen (hoewel het verlagen van de netwerk- en CPU-instelling vaak al voldoende is) start je Chrome op in een Docker container en wijs je minder geheugen toe.
Herlaad de pagina, interageer en controleer de INP met de Core Web Vitals visualizer
Simuleer nu de omstandigheden en bevestig dat de INP-scores overeenkomen met wat je RUM data rapporteerde.
Herlaad de pagina en klik op het juiste element op het juiste moment
Debug de INP met een performance trace
Dit is het moment waar je je in de vorige stappen op hebt voorbereid. Het is tijd om uit te zoeken waarom een bepaalde interactie de slechte Interaction to Next Paint score veroorzaakt.
Open de Chrome Developer Console (Ctrl+Shift+I), navigeer naar het Performance paneel en klik dit keer op het ronde pijl-icoon om de pagina te herladen en de opname te starten (of gebruik de Ctrl+Shift+E sneltoets). Terwijl de opname loopt, interageer je met het element dat de slechte INP veroorzaakt. Stop de opname na een paar seconden en bekijk de tijdlijn. Zoek naar het interactie-event in de "Interactions" track, en inspecteer vervolgens de bijbehorende taken in de "Main" track om precies te zien welke code er tijdens elke fase wordt uitgevoerd.
De performance trace lezen
In het Chrome Performance paneel verschijnt de interactie als een gekleurde balk in de "Interactions" track. Klik erop om de totale INP-duur en de breakdown ervan te zien. Daaronder, in de "Main" track, zie je de individuele taken die tijdens de interactie zijn uitgevoerd. Let op:
- Taken voor de event handler: deze dragen bij aan input delay
- De event handler zelf: dit is de processing time
- Rendering werk nadat de handler is voltooid: dit is de presentation delay
Vergelijk deze bevindingen met je LoAF data om te bevestigen dat de scripts die in de trace zijn geïdentificeerd overeenkomen met de attributiedata uit je RUM tool. Dit is ook een goed moment om te controleren of er JavaScript scroll handlers bijdragen aan het probleem.
Stap 4: Los INP problemen op
Je weet welke interactie traag is en waarom. Tijd om het op te lossen. De Interaction to Next Paint kan worden opgedeeld in 3 fases: input delay, processing time en presentation delay.
Elke fase vereist een andere aanpak. Hier is een samenvatting. Volg de links voor volledige optimalisatiegidsen.
Minimaliseer Input Delay:
Input delay is de tijd tussen de interactie met de pagina en het moment waarop de event callback begint te draaien. Hoewel enige input delay onvermijdelijk is (browsers hebben tijd nodig om de callbacks in te plannen), kun je het wel minimaliseren:
- Vermijd long tasks. Telkens wanneer een taak wordt uitgevoerd, blokkeert deze de main thread en laat deze de event callbacks wachten. Dit is vooral belangrijk bij het optimaliseren van vroege klikken (aangezien de meeste scripts op dat moment worden uitgevoerd). Voor strategieën om JavaScript-blokkering te verminderen, zie onze gids over async vs defer JavaScript.
- Wees voorzichtig bij het aanmaken van nieuwe taken. Bijvoorbeeld terugkerende taken via
setTimeout()of taken die waarschijnlijk vóór het INP-event zullen plaatsvinden, zoals callbacks op hetmouseoverevent. - Meet en beoordeel vroege interactie. Wanneer een interactief element vroeg wordt gepresenteerd (bijvoorbeeld een site zoekelement) en wordt bestuurd door JavaScript dat later wordt geladen, zal elke interactie met het element geen onmiddellijke layout-update triggeren. Geef de functionaliteit prioriteit of verberg/deactiveer het element totdat het goed werkt.
- Gebruik web workers om JavaScript buiten de main thread van de browser te draaien. Web workers maken het mogelijk om scripts buiten de main thread uit te voeren. Dit voorkomt dat de main thread blokkeert en INP input delay problemen veroorzaakt.
- Laad 'nice-to-have' third party scripts tijdens de idle time van de browser. Sommige scripts zijn belangrijker dan andere. Het is logisch om deze scripts prioriteit te geven en minder belangrijke scripts tijdens de idle time van de browser te laden. Bijvoorbeeld een chat-script. Zie onze gids over 14 methoden om JavaScript te deferren voor praktische technieken.
Minimaliseer Processing Time
- Verwijder onnodige code. Onnodige code is ofwel oudere code die nog steeds draait, of nieuwe code die niet nodig is op deze specifieke pagina maar wel CPU-tijd in beslag neemt. Dit is veruit de makkelijkste manier om de INP direct te verbeteren.
- Stel code uit (defer) die niet vóór de next paint hoeft te draaien. Splits code op in kritieke code die vóór de INP moet draaien en niet-kritieke code (bijvoorbeeld het verzenden van analytics) en plan deze in na het paint-event met de
requestIdleCallback()methode. - Optimaliseer code die vóór de paint moet draaien. Controleer je code en herschrijf trage of ineffectieve delen.
- Zorg voor directe feedback. Geef bij ingewikkelde of mogelijk trage taken directe feedback voordat je de hoofdcode uitvoert.
Minimaliseer Presentation Delay
- Houd de DOM klein en simpel. Het is voor een browser veel gemakkelijker om een pagina met weinig en simpele ongeneste DOM elementen (HTML nodes) te renderen dan een pagina met veel geneste DOM nodes. Lees meer over het oplossen van een excessieve DOM grootte.
- Gebruik content-visibility om off-screen content lazy te renderen. Content-visibility versnelt het renderen van zichtbare delen van de pagina door de rendering van off-screen content uit te stellen en die off-screen content 'just in time' te renderen.
Snelle fix: yielding naar de main thread met scheduler.yield()
Yielding naar de main thread tussen kritiek en niet-kritiek werk verbetert alle drie de INP-fases tegelijkertijd. De scheduler.yield() API biedt een overzichtelijke manier om dit te doen. Hier is een herbruikbare helper-functie met een fallback voor browsers die de API nog niet ondersteunen:
async function yieldToMain() {
if ('scheduler' in window && 'yield' in window.scheduler) {
return await window.scheduler.yield();
}
return new Promise((resolve) => {
setTimeout(resolve, 0);
});
}
// Gebruik in een event handler
async function handleButtonClick() {
// Kritiek werk: update de UI
updateVisualFeedback();
// Yield om de browser te laten painten
await yieldToMain();
// Niet-kritiek werk: analytics, logging
sendAnalyticsEvent('button_click');
logInteraction();
}
Elke INP-fase in detail
Elke fase heeft zijn eigen optimalisatiestrategieën:
- Input Delay: Leer hoe je de tijd tussen de gebruikersinteractie en de start van de event processing minimaliseert. Input delay is doorgaans de kortste van de drie fases, maar piekt tijdens het opstarten van de pagina wanneer de main thread druk bezig is met het uitvoeren van scripts.
- </b>Processing Time: Optimaliseer de event handler code die tijdens de interactie draait. Op de meeste pagina's is dit de plek waar het grootste deel van je optimalisatie-inspanningen zich uitbetaalt.
- Presentation Delay: Verminder het rendering- en painting-werk dat volgt op de event processing. Op complexe pagina's met grote DOM's is dit vaak de grootste fase.
Voor aanvullende strategieën die betrekking hebben op alle drie de fases, zie onze gidsen over het verbeteren van INP door JavaScript scrolling te dumpen en het kiezen van async vs defer voor je JavaScript.
Ask AI why your INP spiked.
CoreDash is the only RUM tool with MCP support. Connect it to your AI agent and query your Core Web Vitals data in natural language. No more clicking through dashboards.
See How It Works
