Interaction to Next Paint (INP) problemen vinden en oplossen: Een stappenplan
Leer hoe u Interaction to Next Paint problemen identificeert en oplost met RUM-data, Chrome DevTools en de LoAF API
Interaction to Next Paint (INP) problemen vinden en oplossen
Deze pagina is onderdeel van onze Interaction to Next Paint (INP) serie. INP meet de responsiviteit van uw website door de vertraging tussen een gebruikersinteractie en de volgende visuele update bij te houden. Een goede INP-score is lager dan 200 milliseconden, terwijl scores boven de 500 milliseconden als slecht worden beoordeeld. Als u nieuw bent met INP, begin dan met de INP hub-pagina voor een compleet overzicht.
In dit artikel doorlopen we een volledige methodologie voor het identificeren van Interaction to Next Paint problemen en leggen we vervolgens uit hoe u deze kunt oplossen. Het proces omvat het bevestigen van het probleem in Google Search Console, het diagnosticeren van de hoofdoorzaken met Real User Monitoring (RUM) data, het lokaal repliceren van de condities en het toepassen van gerichte oplossingen voor elke INP-fase.
INP TIP: meestal is de INP veel slechter
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 laadstatus van de pagina te loggen!
Table of Contents!
Stap 1: Controleer de INP in Search Console
De eerste stap is bevestigen dat u daadwerkelijk een INP-probleem heeft. Voordat u codewijzigingen aanbrengt, verifieert u het probleem in Google Search Console zodat u werkt met echte velddata in plaats van aannames.
Log in op uw Google Search Console. Klik in het linkermenu op Core Web Vitals en selecteer Mobiel of Desktop (tip: meestal duiken INP-problemen eerst op mobiel op, dus begin met mobiel).
Hier ziet u een overzicht van alle Core Web Vitals gerelateerde problemen die momenteel op uw site spelen. Als een van deze problemen gerelateerd is aan INP, heeft u bevestigd dat er een probleem is.
Stap 2: Identificeer Interaction to Next Paint problemen
Google Search Console geeft u geen informatie behalve URL-groepen om uit te zoeken wat de problemen met de Interaction to Next Paint veroorzaakt. Meestal gaan ontwikkelaars er dus 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 bijna nooit volledig op.
Daarom moeten we bij het verbeteren van de INP precies weten wat er aan de hand is. We hebben antwoorden nodig op vier kritieke vragen:
Welke elementen veroorzaken bij interactie 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 bij de ergste en zo verder werken.
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? U heeft inmiddels misschien gemerkt dat het
moeilijk is om INP-problemen te repliceren. Daarom moeten we onszelf voorbereiden op succes door
apparaatkenmerken met een slechte INP-score na te bootsen.
Stel RUM-tracking in
Om al deze vragen te beantwoorden, moeten we echte gebruikers gaan volgen en alle 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 gebruik te maken van de Web Vitals library en de resultaten naar uw eigen analytics-backend te sturen.
Het voordeel van deze methode is dat het goedkoop en flexibel is. Het nadeel is dat het veel
extra werk kan zijn.
Een goed alternatief voor het verzenden van uw Core Web Vitals data naar uw eigen backend is het gebruik van een van de vele RUM-tools die er zijn. Wij hebben CoreDash speciaal voor deze use cases ontwikkeld. CoreDash is een goedkope, snelle en effectieve RUM-tool die doet wat het moet doen. Natuurlijk zijn er veel RUM-oplossingen en die zullen het werk ook doen (hoewel tegen een hogere prijs).
Vind trage interacties per element die een hoge INP veroorzaken
Het eerste wat gedaan moet worden, is de traagste interacties vinden die de slechtste INP-scores veroorzaken. Lijst uw pagina's op via "INP metric by Elements" in CoreDash en u krijgt uw traagste interacties. Klik op de eerste regel om uw statistieken te filteren op deze interacties.
Vind wanneer slechte INP-interacties optreden
Sorteer vervolgens de gefilterde URL's op laadstatus. Dit geeft u meer inzicht in de hoofdoorzaak van de INP. In dit geval treedt de hoge INP op wanneer de DOM-content geladen is. Dit betekent dat scripts geparsed zijn, maar async scripts en de sub-resources van de pagina nog niet geladen zijn. 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 gefilterd hebben op de elementen met de traagste interactie en de juiste laadstatus, gaan we kijken naar de URL's waar de INP het 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 welk type bezoekers de slechtste INP-scores veroorzaken. We kijken naar Device Memory, Bandbreedte, Schermgrootte en andere hardwarekenmerken. Zodra we deze kenmerken hebben geïdentificeerd, kunnen we doorgaan met het repliceren en loggen van het probleem.
De Long Animation Frames (LoAF) API gebruiken voor INP-diagnostiek
De Long Animation Frames API (LoAF) biedt gedetailleerde attributiedata die u helpt precies vast te stellen welke scripts en functies verantwoordelijk zijn voor trage interacties. In tegenstelling tot de oudere Long Tasks API, geeft LoAF u script-URL's, functienamen en timing-uitsplitsingen per frame. Dit maakt het een onschatbare tool voor INP-debugging, vooral in combinatie met RUM-data van een tool zoals CoreDash.
Gebruik de volgende code om LoAF-entries te verzamelen voor interacties die een drempelwaarde overschrijden. Deze observer legt de script-attributie, duur en blokkeringstijd vast voor elk long animation frame:
// 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 u het exacte bronbestand en de functienaam, terwijl renderStart en styleAndLayoutStart u helpen verwerkingstijd te scheiden van presentatievertraging. Voor een diepere bespreking van hoe async vs defer JavaScript laden deze timings beïnvloedt, zie onze toegewijde gids.
Stap 3: Repliceer en debug interacties die een hoge INP-score veroorzaken
Zodra we alle informatie hebben die we nodig hebben, kunnen we diep in de onderliggende problemen van de Interaction to Next Paint duiken.
Zet uzelf op voor succes: repliceer de falende INP-omstandigheden
Het volgende dat we moeten doen is proberen de falende INP na te bootsen. Dit doen we 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 panel. In de bovenste balk kunt u de CPU Throttle selecteren (throttle deze naar 4x vertraging om
een normaal mobiel apparaat te emuleren), de Network Throttle (selecteer de snelle 3G-voorinstelling om uw
gemiddelde mobiele apparaat na te bootsen), en stel de hardware concurrency in op 4 of 8 om uw gemiddelde mobiele apparaat na te bootsen.
Om Chrome met minder geheugen te laden (hoewel het verlagen van de netwerk- en CPU-instelling vaak al voldoende is) start u Chrome in een Docker-container en wijst u minder geheugen toe.
Herlaad de pagina, interageer en controleer de INP met de Core Web Vitals visualizer
De volgende stap om de oorzaak van de slechte INP-scores te vinden, is de omstandigheden simuleren en bevestigen
dat de INP-scores inderdaad zo slecht zijn als gerapporteerd.
Herlaad pagina en klik op het juiste element op het juiste moment
Debug de INP met een performance trace
Dit is het moment waar u zich in de vorige stappen op heeft voorbereid. Het is tijd om uit te vinden waarom een bepaalde interactie de slechte Interaction to Next Paint score veroorzaakt.
Open de Chrome Developer Console (Ctrl+Shift+I), navigeer naar het Performance panel en klik deze 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, interageert u met het element dat de slechte INP veroorzaakt. Stop na een paar seconden de opname en bekijk de tijdlijn. Zoek naar het interactie-event in de "Interactions" track, en inspecteer vervolgens de bijbehorende taken in de "Main" track om te zien welke code precies wordt uitgevoerd tijdens elke fase.
De performance trace lezen
In het Chrome Performance panel verschijnt de interactie als een gekleurde balk in de "Interactions" track. Klik erop om de totale INP-duur en de uitsplitsing te zien. Hieronder, in de "Main" track, ziet u de individuele taken die tijdens de interactie draaiden. Let op:
- Taken vóór de event handler: deze dragen bij aan invoervertraging (input delay)
- De event handler zelf: dit is de verwerkingstijd (processing time)
- Rendering werk nadat de handler klaar is: dit is de presentatievertraging (presentation delay)
Vergelijk deze bevindingen met uw LoAF-data om te bevestigen dat de scripts die in de trace zijn geïdentificeerd, overeenkomen met de attributiedata van uw RUM-tool. Dit is ook een goed moment om te controleren of JavaScript scroll handlers bijdragen aan het probleem.
Stap 4: Los INP-problemen op
We zijn nu op een punt waar we weten welke interactie onze slechte INP veroorzaakt en we hebben geanalyseerd wat er precies gebeurt tijdens deze trage interactie. Dit betekent dat het tijd is om de Interaction to Next Paint te gaan repareren. De Interaction to Next Paint kan worden opgesplitst in 3 fasen: invoervertraging, verwerkingstijd en presentatievertraging.
Elke fase van de Interaction to Next Paint moet anders worden behandeld. Hieronder vindt u een samenvatting van de meest impactvolle strategieën voor elke fase. Voor complete optimalisatiegidsen volgt u de links naar de specifieke pagina's.
Minimaliseer Invoervertraging:
Invoervertraging is de tijd tussen de interactie met de pagina en het moment waarop de event callback begint te lopen. Hoewel er altijd enige invoervertraging is (zelfs browsers hebben tijd nodig om de callbacks te plannen), zijn er verschillende dingen om te overwegen:
- Vermijd lange taken (long tasks). Wanneer een taak draait, blokkeert deze de main thread en laat 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 maken 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 laadt, zal elke interactie met het element geen onmiddellijke lay-outupdate triggeren. Prioriteer de functionaliteit of verberg/schakel het element uit totdat het goed werkt.
- Gebruik web workers om JavaScript buiten de main thread van de browser te draaien. Web workers maken het mogelijk scripts buiten de main thread te draaien. Dit voorkomt dat de main thread blokkeert en INP-invoervertragingsproblemen veroorzaakt.
- Laad nice-to-have third party scripts tijdens browser idle time. Sommige scripts zijn kritieker dan andere. Het is zinvol om deze scripts prioriteit te geven en minder belangrijke scripts te laden tijdens browser idle time. Bijvoorbeeld een chatscript. Zie onze gids over 14 methoden om JavaScript uit te stellen voor praktische technieken.
Minimaliseer Verwerkingstijd
- 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 verreweg de makkelijkste manier om de INP onmiddellijk te verbeteren.
- Stel code uit die niet vóór de volgende paint hoeft te draaien. Splits code op in kritieke code die vóór de INP moet draaien en niet-kritieke code (bijvoorbeeld analytics verzenden) en plan die na het paint-event met de
requestIdleCallback()methode. - Optimaliseer code die vóór de paint moet draaien. Controleer uw code en herschrijf trage of ineffectieve delen.
- Zorg voor onmiddellijke feedback. Bij gecompliceerde of mogelijk trage taken, zorg voor onmiddellijke feedback voordat de hoofdcode wordt uitgevoerd.
Minimaliseer Presentatievertraging
- Houd de DOM klein en simpel. Het is voor een browser veel makkelijker 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 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 het renderen van off-screen content uit te stellen en die off-screen content just-in-time te renderen.
Snelle oplossing: yield aan de main thread met scheduler.yield()
Een van de meest effectieve technieken om INP in alle drie de fasen te verbeteren, is 'yielden' (voorrang geven) aan de main thread tussen kritiek werk en niet-kritiek werk. De scheduler.yield() API biedt een schone manier om dit te doen. Hier is een herbruikbare hulpfunctie 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();
}
Diepe duik in elke INP-fase
Nu u weet hoe u INP-problemen kunt identificeren en oplossen, verken elke fase in detail:
- <b>Invoervertraging</b>: Leer hoe u de tijd tussen gebruikersinteractie en de start van eventverwerking minimaliseert. Invoervertraging is goed voor ongeveer 18% van de totale INP-tijd.
- <b>Verwerkingstijd</b>: Optimaliseer de uitvoering van de event handler die goed is voor ongeveer 40% van de totale INP-tijd.
- <b>Presentatievertraging</b>: Verminder het render- en paintwerk dat goed is voor ongeveer 42% van de totale INP-tijd.
Voor aanvullende strategieën die alle drie de fasen bestrijken, zie onze gidsen over INP verbeteren door JavaScript scrolling te dumpen en kiezen tussen async vs defer voor uw JavaScript.
Find out what is actually slow.
I map your critical rendering path using real field data. You get a clear answer on what blocks LCP, what causes INP spikes, and where layout shifts originate.
Book a Deep Dive
