Hoe los je Interaction to Next Paint (INP)-problemen op

Een jaar lang werken met INP als experimentele metric heeft één ding duidelijk gemaakt: veel pagina's presteren ondermaats op responsiviteit. FID gaf voor het 75e percentiel weinig problemen aan. INP laat zien dat de UX — zeker voor smartphonebezoekers — op dit vlak matig tot slecht scoort.

Het Web Almanac 2022 van httparchive.org onderzocht het effect van INP als hypothetische Core Web Vitals (CWV)-metric. Als INP vandaag een CWV-metric zou zijn, zou slechts 20% van de top 1.000 mobiele websites goede CWV met INP behalen — een daling van 32 procentpunten ten opzichte van FID (52%).

Voor laadsnelheid en visuele stabiliteit zijn LCP (Largest Contentful Paint) en CLS (Cumulative Layout Shift) al relevante metrics. Met INP hebben we nu ook een serieuze responsiviteitsmetric. Eén ding staat vast: INP is uitdagender dan FID. Dit artikel legt uit waarom INP een betere metric is en hoe je problemen ermee aanpakt.

Snelle visuele feedback is cruciaal voor INP #

Een pagina die snel reageert op gebruikersinteracties — dat is goede responsiviteit. Gebruikers merken dat als visuele feedback. Technisch gezien toont de browser die feedback in het volgende frame dat hij rendert nadat de interactie heeft plaatsgevonden.

Denk aan een mobiel navigatiemenu dat opengaat, een artikel dat aan een winkelwagen wordt toegevoegd of validatiemeldingen in een registratieformulier. Wanneer na een interactie ook een backend-server of third-party resource aangesproken wordt, is snelle visuele feedback extra belangrijk vanwege de extra netwerklatentie. Laat de gebruiker nooit in het duister tasten — toon snel een eerste reactie, al is het maar een laadspinner.

Het moment van de volgende paint is de eerste kans om die visuele respons te geven. Voor INP moet de tijd tussen interactie en het renderen van het volgende frame zo kort mogelijk zijn.

Waarom worden interacties vertraagd #

Interactiviteit in browsers wordt grotendeels aangestuurd door JavaScript. Muisklikken, tikken op een touchscreen en toetsaanslagen tellen mee voor INP. Hoveren en scrollen niet.

Elke interactie bestaat uit drie fasen: input delay, processing delay en presentation delay. FID meet alleen de eerste fase. INP meet alle drie. De visuele respons als resultaat van de laatste fase is het meest relevant voor de gebruiker, die na elke interactie directe feedback verwacht.

Input delay #

Input delay ontstaat doorgaans door JavaScript long tasks. De browser — of liever: de main thread — kan slechts één taak tegelijk verwerken. Duurt een taak langer dan 50 milliseconden, dan spreken we van een long task. Klikt een gebruiker terwijl zo'n taak loopt, dan moet de browser die taak eerst afmaken voordat hij de input kan ontvangen. Een lopende taak kan hij niet onderbreken. De kans is groot dat de gebruiker de vertraging opmerkt en de pagina als traag of schokkerig ervaart.

Hoe lang een long task duurt, verschilt per apparaat — het hangt sterk af van de CPU. Test en monitor interacties dus op apparaten die vergelijkbaar zijn met wat je bezoekers gebruiken.

Long tasks kunnen in je eigen code zitten, maar het gebruik van third-party resources wordt vaak onderschat. Bij third-party tracking is JavaScript vaak de voornaamste component die je pagina's moeten laden en uitvoeren — met slechte responsiviteit als gevolg.

Processing time #

Nadat de browser de input heeft ontvangen (klik, tik of toetsaanslag), reageert hij via event callbacks. Die functies moet de browser zo snel mogelijk kunnen verwerken.

Beperk de code in event callbacks tot de logica die nodig is voor visuele updates in het volgende frame. De logica voor het openen van een mobiel navigatiemenu hoort in een apart of inline script te staan. Als die logica in een grote JavaScript-bundle zit, moet de browser die bundle eerst volledig verwerken voordat het menu reageert.

Het gevolg is een presentation delay: het inschuiven van het menu wordt vertraagd. Gebruikers zien geen feedback en beginnen te rage-clicken — de browser opent en sluit het menu dan herhaaldelijk, want elke klik is een taak die hij verwerkt.

Rage clicks zijn wanneer gebruikers in korte tijd herhaaldelijk klikken op hetzelfde element. Ze zijn een goede indicator voor gebruikersfrustatie. Annie Sullivan, software-engineer bij Google Chrome, stelde vast dat paginaladingen met een "Good" INP een veel lager percentage rage clicks hebben dan paginaladingen met "Needs Improvement" of "Poor" INP (zie afbeelding hierboven).

Presentation delay #

De presentation delay is de laatste fase. Het is de tijd tussen het afronden van de event callbacks en het moment waarop de browser het volgende frame op het scherm van de gebruiker toont.

Op presentation delays heb je het minste invloed. Er zijn factoren die frames kunnen vertragen waarmee je rekening kunt houden, maar optimaliseer vooral de voorgaande fasen.

Hoe debug je INP-problemen? #

Om INP-problemen te debuggen, moet je weten welke pagina's responsiviteitsproblemen hebben en welke interacties die veroorzaken. Misschien heb je zelf problemen waargenomen, of hebben gebruikers hun ervaringen gedeeld. Heb je RUM-software die attribuutdata voor INP vastlegt (zoals de Google Web Vitals-bibliotheek)? Dan kun je daarmee specifieke UX-problemen van echte gebruikers opsporen.

Om INP te debuggen, moet je de activiteit van de browser main thread analyseren. Het performance-tabblad in Chrome DevTools kan overweldigend zijn — gelukkig is er een eenvoudigere manier.

Lighthouse timespan-modus gebruiken #

In de timespan-modus analyseert Lighthouse interacties met de pagina en rapporteert die gedetailleerd in een audit. De audit laat zien hoeveel tijd er aan interacties is besteed, uitgesplitst naar input delay, processing delay en presentation delay.

Phil Walton, Web Performance Engineer bij Google Chrome, maakte een Interaction to Next Paint (INP) Live Demo-applicatie om een gevoel te krijgen voor de metric. De demo laat je het niveau van main thread-blokkering instellen, zodat je kunt zien hoe verschillende vertragingen zich vertalen naar een INP-score.

In het eerste scenario is er een blokkeringstijd van 200 ms op het pointerdown-event en 80 ms voor het pointerup-event. Na meerdere klikken is de hoogst gemeten INP 288 ms.

Lighthouse timespan-modus mat een INP van 290 ms: 200 ms vertraging door processing time en meer dan 80 ms door presentation delay. Dat klopt precies met de ingestelde event-verwerkingstijden in de demo.

De vertraging zat bij events die door de input werden getriggerd — nadat de browser de gebruikersinput had ontvangen. Op een reguliere webpagina zie je in deze audit waarschijnlijk meerdere specifieke bronnen die de oorzaak aangeven.

In het tweede scenario wordt de frequentie van main thread-blokkering verhoogd naar "often" (in plaats van "never" in scenario 1).

De main thread is nu vaker bezig en kan minder snel input van gebruikers ontvangen. Na meerdere klikken is de hoogst gemeten INP 768 ms.

Lighthouse mat een INP van 770 ms. Dezelfde 200 ms voor processing time en 80 ms voor presentation delay — maar nu zorgen de extra long tasks voor een input delay van zo'n 480 ms.

In beide scenario's hangen de vertragingen samen met script evaluations. Duidelijk is dat een hoge INP-score door verschillende vertragingen én verschillende oorzaken kan ontstaan.

Scenario 2 (het blauwe kader) laat zien dat de main thread van de browser continu bezig is met long tasks (in rood). In scenario 1 gebeurt dat alleen als reactie op klikken.

Total Blocking Time (TBT) #

Total Blocking Time (TBT) is een lab-metric voor responsiviteit. TBT is de totale tijd waarin de main thread geblokkeerd was voor gebruikersinput — de optelsom van alle JS long tasks, minus de eerste 50 ms per taak. TBT wordt gemeten tussen First Contentful Paint (FCP) en Time to Interactive (TTI). Hoewel TTI uit Lighthouse 10 is verwijderd, blijft de meting van TBT ongewijzigd.

Er is een verband tussen TBT (lab) en INP (field): een hoge TBT leidt waarschijnlijk tot hogere INP-waarden. Los je TBT-problemen volledig op in lab-data, dan verdwijnen ook de INP-problemen die echte gebruikers ervaren.

Wat zijn de gevolgen nu INP deel uitmaakt van Core Web Vitals? #

Met INP hebben we een relevante responsiviteitsmetric. Die geeft niet alleen beter inzicht in de omvang van responsiviteitsproblemen, maar laat ook zien waar specifieke vertragingen optreden.

INP maakt site-eigenaren bewust van problemen die FID niet aan het licht bracht. Daarmee kunnen we de UX op het vlak van responsiviteit beter verbeteren — naast laadsnelheid en visuele stabiliteit.

Net als LCP en CLS maakt INP deel uit van de Core Web Vitals-beoordeling vanaf maart 2024. Nu INP de metric FID vervangt, verwacht Google dat veel mobiele sites de beoordeling niet halen. Dat kan gevolgen hebben voor organische Google-rankings. De beoordeling werkt als signaal voor page experience in Google's core ranking-systemen. Scoor je op alle drie de Core Web Vitals "good", dan kun je betere rankingposities behalen.

Volgens Google is de page experience-rankingfactor niet doorslaggevend voor SEO. Het werkt meer als tiebreaker — relevant wanneer je met concurrenten strijdt om de eerste positie. Verbeter responsiviteit daarom primair vanuit het oogpunt van tevreden gebruikers. Tevreden gebruikers doen meer, kopen meer en komen vaker terug. Dat geldt ook voor verkeer via het SEO-kanaal.

'Core Web Vitals INP issues detected on your sites' #

Sinds medio juli stelt Google site-eigenaren via Google Search Console op de hoogte van INP-problemen die zijn geïdentificeerd voor bezoekers van je site(s). Mogelijk heb je een e-mail ontvangen met als onderwerp "Core Web Vitals INP issues detected on your sites", of de bijbehorende melding in Google Search Console gezien.

De links in deze melding leiden je naar een nieuw INP-rapport, zodat je je kunt voorbereiden op de wijzigingen van maart 2024.

Net als de bestaande rapporten zie je welke URL's of groepen URL's INP-problemen hebben en hoe ernstig. Het rapport onderscheidt twee ernstniveaus die overeenkomen met de INP-drempelwaarden:

• Need improvement
• Poor

Meldingen voor smartphones worden vaker gerapporteerd dan voor desktop, vanwege minder krachtige processors (CPU) in mobiele apparaten.

Dit rapport helpt je niet om de oorzaak van INP-problemen te achterhalen, maar wel om te ontdekken waar bezoekers er last van hebben.

Heb je de INP-problemen opgelost? Vraag Google dan om de pagina's opnieuw te valideren. Een paar weken later — vanwege vertragingen in Google CrUX-data — kun je controleren of je de problemen voor je gebruikers hebt verholpen.

Google biedt waardevolle inzichten via het Chrome UX Report (CrUX) en Google Search Console, maar we raden aan ook een Real-User Monitoring (RUM)-tool te gebruiken voor real-time inzicht in INP-problemen.

Conclusie #

Web Performance Optimisation richt zich op drie UX-aspecten: laadsnelheid, visuele stabiliteit en responsiviteit. FID meet de eerste fase van een interactie. INP meet alle drie: input delay, processing time en de visuele feedback daarna.

Mobiele bezoekers hebben het meest last van responsiviteitsproblemen door lange JavaScript-taken. Hoe lang die taken duren, hangt sterk af van de rekenkracht van het apparaat — waardoor de browser niet direct kan reageren op gebruikersinput.

INP helpt ons beter analyseren waar, in welke fase en waarom de responsiviteit van pagina's tekortschiet. Dat maakt gerichte verbetering mogelijk.

Dat Google ervoor heeft gekozen FID door INP te vervangen, bevestigt dat deze metric beter is bij het meten, onderzoeken en monitoren van responsiviteitsproblemen.