INP verbeteren: trage interacties opsporen en oplossen

Zo meet je INP en vind je de trage interactie

INP (Interaction to Next Paint) meet hoe snel je pagina zichtbaar reageert op klikken, taps en toetsaanslagen. Google kijkt per bezoek naar een representatieve trage interactie en rekent daarover het 75e percentiel van al je bezoekers. Goed is 200 milliseconden of minder, tussen 200 en 500 milliseconden is matig, en boven 500 milliseconden kleurt de score rood.

Zo spoor je de boosdoener op:

1. Open PageSpeed Insights of het Core Web Vitals-rapport in Search Console en noteer welke paginagroepen slecht scoren op INP.
2. Open zo’n pagina in Chrome, start een opname in de Performance-tab van DevTools en gebruik de pagina zoals een bezoeker: klik menu’s open, voeg iets toe aan de winkelwagen, bedien een filter.
3. Zoek in de opname de interacties met de langste duur; DevTools markeert ze en laat zien welke scripts de tijd opslokken.

Meet daarbij de hoofdversie van een pagina, dus zonder trackingparameters. Varianten met parameters wijzen via hun canonical URL naar dezelfde pagina en hebben zelden genoeg eigen velddata.

De drie fases: waar zit jouw vertraging?

Elke interactie bestaat uit drie fases, en elke fase heeft een eigen oplossing:

• Input delay: de klik staat in de wachtrij omdat de hoofdthread nog bezig is met andere taken, vaak scripts die op dat moment laden of uitvoeren.
• Processing duration: de tijd die de event handlers zelf nodig hebben, bijvoorbeeld een klikfunctie die de complete winkelwagen opnieuw doorrekent.
• Presentation delay: de tijd tot de browser het volgende frame tekent, bijvoorbeeld doordat een enorme pagina-opbouw opnieuw berekend moet worden.

In de Performance-opname zie je per interactie hoe de tijd over deze fases verdeeld is. Een lange input delay wijst op te veel JavaScript in het algemeen, een lange processing duration op één specifieke zware functie, en een lange presentation delay op een te grote of te complexe DOM.

Minder JavaScript, kortere taken

Vrijwel elke slechte INP komt neer op een overbelaste hoofdthread. Zo verlicht je die:

• Verwijder overbodige plugins en scripts. Elke plugin die JavaScript toevoegt, vergroot de kans dat een klik moet wachten. Deactiveer wat je site niet echt nodig heeft.
• Wees streng op scripts van derden. Chatwidgets, heatmaps en trackingpixels draaien op dezelfde hoofdthread als je eigen code, en laden meestal op elke pagina mee, tot je 404-pagina aan toe. Laad ze pas na de eerste interactie of schrap ze helemaal.
• Knip lange taken op. Taken die langer dan 50 milliseconden duren, blokkeren elke interactie die op dat moment binnenkomt. Laat maatwerkcode tussendoor de controle teruggeven aan de browser, bijvoorbeeld met setTimeout of, in moderne browsers, scheduler.yield.
• Haal zwaar werk uit de klikafhandeling. Toon eerst het zichtbare resultaat en werk daarna op de achtergrond bij wat niet direct in beeld hoeft.

Geef elke klik direct zichtbare feedback

Bezoekers ervaren traagheid vooral als er even niets gebeurt na een klik. Zelfs wanneer het echte werk tijd kost, kun je de gemeten en gevoelde reactietijd verbeteren:

• Toon meteen een visuele verandering: een actieve knopstatus, een spinner of een skeleton, en laad de data daarna in.
• Houd je DOM compact. Pagina’s met duizenden elementen maken elke herberekening traag; pagebuilder-templates met veel geneste secties en kolommen zijn hier berucht om.
• Vermijd zware visuele effecten op interactie, zoals schaduwen en filters op grote vlakken die bij elke klik opnieuw getekend worden. Gebruik voor animaties bij voorkeur CSS-transforms.

INP verbeteren op een WordPress-site

Voor WordPress vertalen deze principes zich naar een concrete volgorde:

1. Draai een plugin-audit: bekijk welke plugins JavaScript op elke pagina laden en schrap of vervang de zwaarste.
2. Test de optie om JavaScript uit te stellen tot interactie voorzichtig. Die instelling van optimalisatieplugins verbetert laadscores, maar kan juist de éérste klik vertragen, omdat alle uitgestelde scripts dan alsnog tegelijk starten.
3. Versimpel je zwaarste templates: minder secties, kolommen en widgets betekent een kleinere DOM en snellere interacties.
4. Meet na elke wijziging opnieuw met een Performance-opname en houd de velddata de weken erna in de gaten, want die reageren vertraagd.

Veelgemaakte fouten bij INP-optimalisatie

• Sturen op Lighthouse in plaats van velddata. Een labtest klikt nergens op en meet dus geen INP, hooguit de vervangende indicator Total Blocking Time. Fix: beoordeel INP altijd op basis van echte bezoekersdata.
• Alle JavaScript blind uitstellen. Uitgestelde scripts starten bij de eerste interactie tegelijk op, precies het moment dat je wilt beschermen. Fix: sluit scripts uit die interacties afhandelen en test de eerste klik na elke wijziging.
• Alleen de homepage meten. INP is meestal het slechtst op interactieve pagina’s zoals filters, configurators en de winkelwagen. Fix: test je meest interactieve templates apart.
• Aannemen dat een snelle laadtijd genoeg is. Snelheidsplugins verbeteren vooral laadscores, niet automatisch de reactietijd. Fix: behandel INP als een eigen probleem met eigen metingen.
• Zware animaties aan elke klik hangen. Uitgebreide openklap-effecten duwen het volgende frame naar achteren. Fix: houd animaties licht en kort.

Veelgestelde vragen

Bronnen en verder lezen

• Interaction to Next Paint (web.dev)
• Optimize Interaction to Next Paint (web.dev)