INP verbeteren: waarom je site traag aanvoelt na de klik

INP verbeteren betekent zorgen dat je pagina snel zichtbaar reageert op elke klik, tik of toetsaanslag. Interaction to Next Paint meet hoe lang het duurt tussen een interactie en het moment dat de browser het resultaat op het scherm zet. Onder de 200 milliseconden is goed. Voelt je site traag na de klik, dan blokkeert vrijwel altijd JavaScript de hoofdthread.

INP verving FID in maart 2024 als Core Web Vital voor responsiviteit. Waar FID alleen de vertraging van de eerste interactie mat, kijkt INP naar alle interacties tijdens een bezoek. Daardoor kwamen veel sites die eerder groen scoorden ineens in de problemen. In dit artikel lees je hoe INP werkt, hoe je de boosdoeners vindt en welke oplossingen het meeste opleveren.

Wat INP precies meet

Elke interactie bestaat uit drie delen. Samen vormen ze de INP-tijd van die interactie:

Fase	Wat er gebeurt	Typische oorzaak van vertraging
Input delay	Tijd voordat de browser aan je event handler kan beginnen	De hoofdthread is bezig met ander werk, zoals scripts die laden
Processing time	Tijd dat je event handlers draaien	Zware of te veel code per klik
Presentation delay	Tijd om de nieuwe weergave te berekenen en te tekenen	Grote DOM, dure layout- of stijlberekeningen

De INP van een pagina is grofweg de traagste interactie van het bezoek, waarbij bij heel veel interacties een enkele uitschieter wordt genegeerd. Google beoordeelt de 75e percentiel van echte bezoeken. De drempels:

• Goed: tot en met 200 ms;
• Verbetering nodig: tussen 200 en 500 ms;
• Slecht: boven 500 ms.

Een uitgebreide technische uitleg vind je op web.dev. Wil je eerst de grote lijnen van alle drie de Core Web Vitals, lees dan Core Web Vitals uitgelegd voor ondernemers.

Waarom je site traag aanvoelt na de klik

De browser heeft één hoofdthread die JavaScript uitvoert, stijlen berekent en het scherm tekent. Zolang die bezig is met een taak, kan hij niet reageren op jouw klik. Taken die langer dan 50 milliseconden duren, heten long tasks, en die zijn de hoofdoorzaak van een slechte INP. Veelvoorkomende bronnen:

• Third-party scripts: chatwidgets, tagmanagers, advertentie- en trackingscripts, A/B-testtools;
• Zware frameworks of page builders die bij elke interactie veel code draaien of grote delen van de pagina opnieuw renderen;
• Event handlers die te veel doen: filteren, sorteren, data versturen en de interface bijwerken, alles in één keer;
• Een enorme DOM: duizenden elementen maken elke layoutberekening duurder;
• Layout thrashing: code die afwisselend afmetingen leest en stijlen wijzigt, waardoor de browser steeds opnieuw moet rekenen.

Let op: een snelle LCP zegt niets over INP. Een pagina kan razendsnel zichtbaar zijn en daarna haperen zodra je het menu opent of een filter aanklikt. Laadsnelheid zelf behandelen we in LCP onder 2,5 seconden.

Zo meet je INP en vind je de boosdoener

Velddata: is er een probleem?

Begin in Google Search Console bij het Core Web Vitals-rapport. Daar zie je welke groepen URL’s slecht scoren op INP, op basis van echte bezoekers. PageSpeed Insights toont per URL of per site dezelfde velddata, als er genoeg verkeer is.

Labdata: welke interactie hapert?

Velddata vertelt je dat er een probleem is, maar niet precies waar. Open daarvoor Chrome DevTools en gebruik het Performance-paneel. Neem een opname op terwijl je de interacties uitvoert die bezoekers vaak doen: menu openen, filter klikken, formulier invullen, accordeon uitklappen. In de opname zie je welke taken lang duren en welk script ze veroorzaakt. Test met CPU-throttling, want je eigen laptop is veel sneller dan de gemiddelde telefoon van je bezoekers.

Eigen metingen

Voor grotere sites loont het om INP zelf te meten bij echte bezoekers, met attributie: welke interactie, welk element en welke fase was traag. Dan hoef je niet te gissen welk onderdeel je eerst moet aanpakken.

INP verbeteren: de oplossingen die het meeste opleveren

1. Ruim third-party scripts op

Maak een lijst van alle externe scripts en vraag per script: gebruiken we dit nog, en levert het genoeg op? Verwijder wat overbodig is. Laad de rest pas als het nodig is, bijvoorbeeld een chatwidget pas na een klik op de chatknop.

2. Breek lange taken op

Laat een event handler eerst het zichtbare resultaat tonen en schuif de rest door naar later. Geef de hoofdthread tussendoor terug aan de browser, zodat die kan tekenen:

button.addEventListener('click', async () => {
  toonLaadstatus();          // direct zichtbare feedback
  await geefDoor();          // browser mag eerst tekenen
  verwerkFilter();           // het zware werk daarna
});

function geefDoor() {
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();
  }
  return new Promise(resolve => setTimeout(resolve, 0));
}

Het idee: de bezoeker ziet direct dat zijn klik is aangekomen, ook al duurt de verwerking iets langer.

3. Doe minder per interactie

Moet alles echt bij elke klik gebeuren? Analytics-events kunnen later worden verstuurd, berekeningen kunnen worden gecachet en zoekfilters kunnen met een korte debounce werken in plaats van bij elke toetsaanslag.

4. Verklein de DOM en vermijd layout thrashing

Minder elementen betekent goedkopere stijl- en layoutberekeningen. Groepeer metingen en wijzigingen: eerst alle afmetingen lezen, daarna alle stijlen aanpassen. Met content-visibility: auto kun je bovendien voorkomen dat de browser werk doet voor content die nog buiten beeld is.

5. Kies een lichtere basis

Soms zit het probleem in het fundament: een zware page builder of thema dat op elke pagina veel JavaScript laadt. Dan levert patchen weinig op en is een lichtere opbouw de echte oplossing. Voor WordPress-sites hebben we daar eerder tips voor WordPress zonder tien plugins over geschreven.

Zo pak je het aan

1. Check Search Console en noteer welke paginatypes slecht scoren op INP.
2. Kies per paginatype de belangrijkste interacties, zoals menu, filters, formulieren en knoppen.
3. Neem een performance-opname op met CPU-throttling en zoek de lange taken rond die interacties.
4. Koppel elke lange taak aan een script: je eigen code, een plugin of een third-party.
5. Pak de grootste eerst aan: verwijderen, uitstellen, opbreken of vervangen.
6. Toets opnieuw in het lab en volg in de weken daarna de velddata. Die loopt achter, omdat ze over een periode van 28 dagen wordt verzameld.

Voorbeeld: stel, een webshop in fietsonderdelen heeft een filterpagina waarbij elke klik op een filter de hele productlijst opnieuw opbouwt en tegelijk drie trackingscripts aanroept. Door eerst alleen het aangeklikte filter visueel te markeren, de lijst daarna bij te werken en tracking uit te stellen, wordt de interactie voor de bezoeker direct responsief.

Is de oorzaak dieper dan een paar scripts? Dan helpt een analyse door specialisten in technische SEO en performance, of een maatwerk website die vanaf de basis licht is opgebouwd.

Conclusie

Een slechte INP voel je als bezoeker direct: je klikt en er gebeurt even niets. De oorzaak is bijna altijd een overbelaste hoofdthread door te veel of te zware JavaScript. Meet eerst met velddata, zoek de haperende interacties met DevTools en pak dan scripts, lange taken en DOM-grootte aan. Geef bezoekers vooral direct visuele feedback, ook als het echte werk nog even doorloopt.

Wil je weten waar jouw site vastloopt? Laat de responsiviteit onderzoeken als onderdeel van een technische SEO-analyse.