FID is voorbij. INP is de nieuwe standaard. Als je je site technisch scherp wilt houden, is dit de belangrijkste verschuiving in de Core Web Vitals van de afgelopen jaren. En anders dan de oude meting is deze een stuk lastiger om goed te krijgen.
Ik werk als SEO- en GEO-specialist onder JSResults, en in vrijwel elke technische SEO-audit die ik doe komt INP nu terug. Vaak zijn LCP en CLS al netjes, maar valt de site op INP door de mand. In dit artikel leg ik uit wat er precies veranderd is, wat INP meet, en welke aanpassingen in de praktijk het meeste effect hebben.
Snel overzicht: de drie Core Web Vitals
Core Web Vitals zijn drie meetwaarden van Google die de ervaring van echte bezoekers meten. Ze zijn een bevestigd rankingsignaal. Dit zijn ze:
- LCP (Largest Contentful Paint): hoe snel het grootste element in beeld staat. Dit meet laadsnelheid.
- INP (Interaction to Next Paint): hoe snel je site reageert op wat de bezoeker doet. Dit meet reactiesnelheid.
- CLS (Cumulative Layout Shift): hoeveel de pagina onverwacht verspringt. Dit meet visuele stabiliteit.
De grote verandering: FID eruit, INP erin
Op 12 maart 2024 heeft Google FID (First Input Delay) vervangen door INP. Sindsdien is INP volwaardig onderdeel van de Core Web Vitals, en in 2026 is het volledig ingeburgerd als signaal.
Waarom deze wissel? FID mat maar een heel klein stukje van de werkelijkheid. Het keek alleen naar de vertraging bij de allereerste interactie, en alleen naar het begin daarvan. Een site kon dus een prima FID-score hebben en tegelijk traag aanvoelen bij alles wat je daarna deed. INP dicht dat gat.
Wat meet INP precies?
INP kijkt naar alle interacties tijdens het hele bezoek, dus elke klik, tik en toetsaanslag. Van al die interacties pakt het in de praktijk de traagste als jouw score. Het meet daarbij de volledige keten, van de handeling tot het moment dat je het volgende beeld ziet.
Die keten bestaat uit drie delen:
Het verschil met FID in een zin: FID mat alleen dat eerste stukje input delay van de eerste interactie. INP meet de hele keten, bij elke interactie, gedurende het hele bezoek. Daardoor is het een veel eerlijker beeld van hoe je site echt aanvoelt.
De drempels in 2026
De officiële drempels zijn niet veranderd. Ik zeg dit expres, want er circuleren berichten dat Google de LCP-grens zou hebben aangescherpt of manual actions zou uitdelen voor Core Web Vitals. Dat klopt niet. Core Web Vitals is een automatisch signaal, geen handmatige straf, en dit zijn de actuele grenzen volgens Google zelf:
| Metric | Goed | Kan beter | Slecht |
|---|---|---|---|
| LCP (laadsnelheid) | 2,5 s of sneller | 2,5 s tot 4 s | langer dan 4 s |
| INP (reactiesnelheid) | 200 ms of sneller | 200 ms tot 500 ms | langer dan 500 ms |
| CLS (stabiliteit) | 0,1 of lager | 0,1 tot 0,25 | hoger dan 0,25 |
Belangrijk detail: Google meet op het 75e percentiel van je bezoeken, gesplitst naar mobiel en desktop. Je hoeft dus niet elke bezoeker onder de grens te krijgen, maar wel driekwart. En let op: het gaat om velddata van echte bezoekers, niet om de labscore die je in een test op je eigen laptop ziet.
Waarom INP zoveel lastiger is dan FID
Op papier lijkt INP mild. De grens voor ‘goed’ ligt op 200 ms, terwijl FID op 100 ms zat. Toch worstelen veel sites er juist mee, en dat is logisch.
- INP meet het hele bezoek, niet een moment. Een enkele trage interactie later op de pagina trekt je score omlaag.
- Het meet de volledige keten, inclusief het verwerken van je JavaScript en het opnieuw tekenen van het scherm.
- Moderne sites leunen zwaar op JavaScript. Precies dat is wat de hoofdthread blokkeert en INP verslechtert.
Kortom: INP straft zware, log reagerende interfaces af. Dat is precies waar veel sites, zeker die met veel scripts en trackers, de mist in gaan.
Welke aanpassingen het meeste effect hebben
Dit is waar het om draait. Op basis van wat ik in audits terugzie, is dit de volgorde waarin ik INP zou aanpakken. Bovenaan staat wat meestal de grootste winst geeft.
- Breek lange taken op. Alles wat de hoofdthread langer dan 50 ms bezet houdt, blokkeert interacties. Knip zwaar JavaScript op in kleinere stukken en geef de browser tussendoor lucht.
- Verminder en stel JavaScript uit. Laad niet-kritieke scripts later of pas bij interactie. Elke kilobyte JavaScript die je niet meteen uitvoert, helpt.
- Ruim third-party scripts op. Chatwidgets, trackers en A/B-testtools zijn beruchte INP-killers. Houd alleen wat echt nodig is, en laad de rest uitgesteld.
- Houd event handlers licht. Doe in een klik-handler alleen het hoognodige. Zwaar werk kun je uitstellen tot na de eerste visuele reactie.
- Toon eerst, reken daarna. Geef bij een interactie meteen visuele feedback (bijvoorbeeld een status), en doe het rekenwerk erna. De bezoeker ervaart de site dan als snel.
- Verklein en vereenvoudig de DOM. Een enorme, diep geneste pagina maakt elke herberekening trager. Minder elementen betekent snellere reacties.
- Gebruik CSS in plaats van JavaScript waar het kan. Animaties en tonen of verbergen gaan vaak sneller en soepeler met pure CSS.
Merk je het patroon? Bijna alles draait om je hoofdthread ontlasten. INP is in de kern een JavaScript-probleem, geen plaatjes- of serverprobleem.
Hoe meet je INP?
Meet altijd met echte velddata, want dat is wat Google gebruikt. Deze tools helpen:
- Google Search Console, rapport Core Web Vitals: laat zien welke groepen pagina’s op mobiel en desktop falen.
- PageSpeed Insights: toont zowel velddata (uit het Chrome User Experience Report) als een labtest.
- Chrome DevTools, tabblad Performance: hiermee spoor je de trage interacties en lange taken op je eigen pagina op.
- De web-vitals JavaScript-bibliotheek: meet INP bij je echte bezoekers en stuur het naar je analytics.
Mijn advies: begin bij Search Console om te zien welke paginagroepen falen, en zoom daarna met DevTools in op de trage interacties zelf. Wil je dat ik dit voor je site in kaart breng, met een actieplan op volgorde van impact? Dat doe ik in een technische SEO-audit, of plan direct een gesprek.
Veelgestelde vragen
Wat is het verschil tussen INP en FID?
FID mat alleen de vertraging bij de eerste interactie, en alleen het eerste stukje daarvan. INP meet alle interacties tijdens het hele bezoek en de volledige keten tot het scherm reageert. INP geeft daardoor een veel eerlijker beeld.
Wat is een goede INP-score?
200 milliseconden of sneller is goed. Tussen 200 en 500 ms kan het beter, en boven de 500 ms is het slecht. Google meet dit op het 75e percentiel van je echte bezoekers.
Zijn de Core Web Vitals-drempels in 2026 veranderd?
Nee. De officiële grenzen zijn onveranderd: LCP 2,5 s, INP 200 ms en CLS 0,1 voor een goede score. Berichten over een strengere LCP-grens of manual actions kloppen niet.
Wat verpest mijn INP meestal?
Bijna altijd zwaar of slecht getimed JavaScript dat de hoofdthread blokkeert. Denk aan trackers, chatwidgets en logge event handlers. Die opruimen of uitstellen geeft de meeste winst.
Bronnen
Dit artikel combineert mijn eigen audit-praktijk met de officiële documentatie van Google. De drempels en definities heb ik gecontroleerd via:
- web.dev, Web Vitals en de INP-documentatie: web.dev/articles/vitals
- web.dev blog, Interaction to Next Paint becomes a Core Web Vital on March 12: web.dev/blog/inp-cwv-march-12
- Google Search Central, Understanding Core Web Vitals and Google search results: developers.google.com