INP — nieuwe metric, oude probleem

Wat INP precies meet

Interaction to Next Paint meet de tijd tussen een gebruikersinteractie (klik, tap, toetsenbord-input) en het moment dat de browser het visuele resultaat van die interactie toont. Concrete voorbeelden:

• Je tikt op het hamburger-menu — hoe snel zie je het menu open?
• Je klikt op een productfoto — hoe snel verschijnt de modal?
• Je tikt in een formulierveld — hoe snel reageert het toetsenbord?

Google neemt niet één interactie, maar alle interacties tijdens een sessie, en pakt de slechtste (98e percentiel). Dat is een eerlijker beeld van hoe je site echt aanvoelt.

Verschil INP en FID

De vorige metric (First Input Delay) meet alleen de allereerste interactie op een pagina. Dat was vergevingsgezind: sites scoorden vaak groen omdat de eerste klik snel was, terwijl latere interacties slecht waren.

INP is strenger:

• Meet alle interacties, niet alleen de eerste
• Neemt de slechtste, niet de gemiddelde
• Meet hele "input → next paint"-tijd, niet alleen processing-tijd

Toen INP de officiële Core Web Vital werd in maart 2024, zakten WordPress-MKB-sites gemiddeld 25 punten in PageSpeed. Niet omdat hun site slechter werd — omdat de meting eerlijker werd.

Drempels

• Onder 200ms = goed (groen)
• 200-500ms = matig (oranje)
• Boven 500ms = slecht (rood)

Waarom MKB-sites hier zakken

Voor MKB-sites zijn er vier voornaamste boosdoeners:

1. Te veel plugins (WordPress-specifiek)

Elke plugin voegt scripts toe die op page-load draaien. 30 plugins = 30+ script-files, soms 1-2 MB JavaScript totaal. Browser kan niet snel reageren op input zolang hij JS verwerkt. Fix: plugin-audit, schakel uit wat je niet gebruikt, vervang zware door lichte alternatieven.

2. Page-builders (Elementor, Divi, WPBakery)

Page-builders zijn handig voor klanten, maar zwaar voor de browser. Elke widget = JS-code. Een Elementor-homepage met 12 widgets kan 400-600ms INP veroorzaken. Voor MKB-sites die echt snel moeten: overweeg een rebuild op blokken-editor (Gutenberg) of statische generator.

3. Tracking-scripts en chat-widgets

Hotjar, Tawk.to, Drift, Intercom, Facebook Pixel, Google Tag Manager met 8 trackers — die draaien allemaal in de main thread. Fix: laad chat-widgets met delay (na 5s) of alleen op klik. Tracking via Google Tag Manager met "loaded async" attribuut.

4. Eigen JavaScript dat niet async is

Custom scripts die zonder async of defer ingeladen worden blokkeren de main thread. Voeg defer toe aan elke <script>-tag die niet inline op de pagina hoeft te draaien.

Concreet fix-pad

1. Meet INP op pagespeed.web.dev (mobiel)
2. Identificeer trage interacties via Chrome DevTools → Performance Insights — laat zien welke handler het traagst is
3. Plugin-audit (WordPress): deactiveer alles wat je niet gebruikt
4. Voeg defer toe aan externe scripts in je theme
5. Vertraag chat/tracking tot na initial paint (5s delay of on-interaction)
6. Vervang zware widgets door lichte alternatieven (Elementor sliders → native CSS scroll, bijvoorbeeld)

Tools om INP te diagnosticeren

• PageSpeed Insights — geeft INP-score plus "Reduce JavaScript execution time"-advies
• Chrome DevTools → Performance — record een sessie, klik door je site, zoek long tasks (rood gemarkeerd)
• Web Vitals Chrome extension — toont INP in real-time terwijl je rondklikt
• Google Search Console → Core Web Vitals — toont veldgemiddeldes per pagina-type

Wanneer rebuild de slimste optie is

Bij MKB-sites die op WordPress + page-builder gebouwd zijn met 25+ plugins is INP-fix vaak een kat-en-muis spel. Je sloopt één plugin, INP zakt, klant mist een feature, plugin gaat terug. Op een schoon platform (Astro, modern Webflow, Gutenberg-WordPress) is INP standaard onder 100ms. Voor MKB die structureel snel wil zijn is rebuild vaak goedkoper-op-de-lange-termijn dan eindeloos optimaliseren.

DesignCheck-rebuilds zitten standaard op INP 80-130ms (zie prijzen). Wat dit oplevert aan conversie en ranking: zie verliescalculator. Voor MKB in de regio: DesignCheck Mijdrecht.

Hoe INP wordt opgebouwd — de drie fasen van een interactie

Eén INP-meting bestaat uit drie aparte fasen. Begrijpen welke fase je probleem veroorzaakt is het verschil tussen een week aan willekeurige optimalisatie en één gerichte fix.

Fase 1 — Input delay. De tijd tussen de klik en het moment dat de event handler begint. Als de main thread bezet is met andere taken (een laat-laadende script, een trage animatie, een heavy timer), wacht de browser. Lange input delays zijn typisch het gevolg van scripts die net binnenkomen op moment van klik.

Fase 2 — Processing time. De tijd die je event handler nodig heeft om zijn werk te doen. Een hamburger-menu die 12 DOM-nodes moet aanpassen en CSS-classes wisselt heeft een processing time van 5-15 ms. Een chat-widget die bij klik een iframe injecteert en API-call doet kan 200-400 ms processing nodig hebben.

Fase 3 — Presentation delay. De tijd tussen het einde van de event handler en het moment dat de browser de nieuwe pixel naar het scherm tekent. Hier komen CSS-recalculatie, layout-engine en paint-werk samen. Complexe CSS-selectoren en zware animaties verhogen deze fase.

Voor MKB-sites zit het probleem meestal in fase 1 (te veel scripts in de race). De aanpak: zorg dat alleen kritisch JavaScript synchronous laadt, alle rest gedeferd of pas-bij-interactie. Tools als web.dev INP-debugger laten zien welke fase de bottleneck is.

Een handige debugging-truc: open je site in Chrome, druk F12, ga naar Performance Insights, klik op "Throttling" en zet 'em op "Mid-tier mobile". Klik nu door je site. Wat op je desktop razendsnel aanvoelt, gedraagt zich nu zoals het op een echte mid-range telefoon doet. Hier zie je interacties van 300-600 ms die je anders nooit zou opmerken.

JavaScript-budgets — hoeveel KB is acceptabel?

Een vaak vergeten regel: hoe meer JavaScript op je pagina, hoe slechter je INP. Niet alleen omdat de scripts iets doen, maar omdat de browser ze moet parsen en compileren. Op een mid-range Android telefoon kost het parsen van 1 MB JavaScript ongeveer 600 ms aan main thread-tijd. Tijdens die 600 ms reageert je site niet op input.

Onze budgets voor MKB-sites:

• Streng (snelle MKB-site): totaal onder 100 KB JavaScript gzipped op de homepage. Geen frameworks tenzij echt nodig. INP zit hiermee structureel onder 100 ms.
• Realistisch (modern MKB): 100-250 KB gzipped. Eén framework (Astro islands, lichte React) plus 2-3 third-party scripts. INP onder 200 ms haalbaar.
• Probleem-zone: 250-500 KB gzipped. Page-builders, multiple-trackers, chat-widgets, sliders. INP zit hier vaak op 300-500 ms.
• Onhoudbaar: boven 500 KB gzipped. Volledige React-SPA op een trage CMS-stack. INP boven 600 ms, rebuild de enige oplossing.

Meet je eigen JavaScript-budget via Chrome DevTools → Network-tab, filter op "JS", refresh. Onderin staat "transferred" — dat is je gzipped totaal. Voor de meeste MKB-sites is dit een schok-moment.

Scripts saneren — concreet voor de drie meest voorkomende cases

Drie veelvoorkomende INP-killers waar 80% van MKB-sites tegenaan loopt, met de concrete fix:

Case 1 — Google Tag Manager met 8+ trackers. Elke tracker draait JavaScript op page-load. Twee fixes: ten eerste, audit GTM-container, deactiveer trackers die je nooit gebruikt (Hotjar dat alleen op project X aanstond, Facebook Pixel van een afgelopen campagne). Ten tweede, configureer GTM met "Initialization — All Pages" → fired on "Window Loaded" in plaats van "Page View". Trackers laden na initial paint. INP-winst: 80-150 ms.

Case 2 — Chat-widget zoals Tawk.to of Intercom. Inline gelinkte chat-widgets laden 200-400 KB JS en starten WebSocket-verbindingen direct. Fix: laad het script pas wanneer iemand op een "chat openen"-knop klikt. Dat is een handmatige loader van 15 regels JavaScript. Bezoekers die niet chatten betalen geen INP-prijs. INP-winst: 100-300 ms.

Case 3 — Slider of carousel-script. jQuery-gebaseerde sliders (Slick, Owl) draaien op DOMContentLoaded en hangen aan elke slide event-listeners. Fix: vervang door native CSS scroll-snap of een vanilla-JS slider van 3 KB. INP-winst: 50-100 ms, plus pagina-gewicht zakt 40-80 KB.

Stappenplan — van INP 500 ms naar onder 200 ms

1. Meet je p75-INP in PageSpeed Insights (mobiel) en in Google Search Console (veld-data).
2. Open Chrome DevTools → Performance Insights tab. Klik "Record". Klik door je site (menu open, formulier invullen, productfoto klikken). Stop opname. Zoek de "Interactions"-laag onderin.
3. Identificeer de drie traagste interacties. Klik elk open en lees welke event handler de meeste tijd kost.
4. Tel je totale JavaScript-budget gzipped via de Network-tab. Boven 250 KB? Reduceren is eerste prioriteit.
5. Doe een script-inventory: lijst elk <script>-tag, weet welke functie hij heeft. Verwijder wat niet meer in gebruik is.
6. Voeg defer attribuut toe aan elke externe script die niet boven de fold nodig is.
7. Audit je Google Tag Manager container. Vertraag firing-rules naar "Window Loaded" of "DOM Ready".
8. Vervang je chat-widget door een on-demand loader. Een knop met onclick="loadChat()" bespaart 200+ ms INP per page-view.
9. Audit je WordPress plugins (indien van toepassing). Schakel uit wat niet actief gebruikt wordt. Vervang zware page-builders door Gutenberg waar mogelijk.
10. Vervang jQuery-sliders door native CSS scroll-snap. 90% van de behoefte is daarmee gedekt.
11. Voeg scheduler.yield() of requestIdleCallback() toe aan eigen scripts die zware berekeningen doen — de browser krijgt dan tussendoor ruimte voor input.
12. Meet opnieuw. Vergelijk lab-INP voor en na.
13. Wacht 28 dagen, check veld-INP in PageSpeed Insights.
14. Stel een INP-budget in: elke nieuwe feature wordt afgewezen als hij de p75 boven 200 ms duwt.

Wanneer INP een rebuild-signaal is

Sommige sites hebben hun INP-probleem ingebakken in de stack. Een Elementor-site met 18 widgets op de homepage heeft een INP-vloer van 250-400 ms die nauwelijks omlaag te krijgen is zonder de page-builder te verlaten. Een legacy-jQuery-site met 600 KB JS heeft hetzelfde probleem. Dan kost één dag debug-werk minder dan tien dagen optimalisatie op een fundament dat het nooit gaat halen.

De DesignCheck-rebuild-pakketten (€1.995, €3.995, €6.995) leveren INP onder 100 ms als standaard. We bouwen op moderne stacks (Astro, Next.js, vanilla) die geen page-builder-overhead hebben. Klanten op een rebuild-traject hebben hun INP gemiddeld zien zakken van 480 ms naar 85 ms. Bij Keurmeesters (NL energielabel-bureau, live klant) zit veld-INP op 78 ms over 30 dagen.

Wereldwijd beschikbaar via remote samenwerking. Twijfel je tussen optimaliseren en rebuilden? Vraag de gratis audit aan — we meten je top-5 pagina's, identificeren de zwaarste scripts en geven binnen 48 uur een onderbouwd advies.

Een nuance op deze rebuild-overweging. Sommige MKB-sites halen 60-70% van hun verkeer uit branded zoekopdrachten (mensen die naar je bedrijfsnaam zoeken). Daar straft Google trage INP minder hard af omdat de intent al duidelijk is. Bij sites die zwaarder leunen op long-tail SEO-verkeer ("hovenier in Mijdrecht voor onderhoud") weegt INP veel zwaarder mee in ranking. Weet welk verkeer je hebt voor je een rebuild-budget aanvraagt — de business case verschilt per situatie.

CSS als verborgen INP-killer

Veel mensen associëren INP met JavaScript. Niet onterecht — de meeste INP-problemen komen van scripts. Maar CSS heeft een groeiende rol die vaak over het hoofd wordt gezien.

Zware CSS-selectoren verhogen de presentation delay (fase 3 van INP). Een ingewikkelde selector zoals .menu li:not(.active) > a:hover span::before moet bij elke style-recalculation worden geëvalueerd. Op pagina's met duizenden DOM-nodes kost dat 10-30 ms per interactie. Houd selectoren plat: klassen direct op het element waar je 'em wil toepassen.

Een tweede CSS-valkuil: animaties op niet-composited properties. Animaties op height, top, left, width dwingen de browser layout te herberekenen voor elke frame. Tijdens een hamburger-menu-animatie loopt de browser vast op layout-werk, INP schiet omhoog. Vervang door transform: translate() en opacity — die draaien op de GPU en raken de main thread nauwelijks.

Onze regel voor MKB-sites die INP onder 100 ms willen: nooit een animatie op layout-properties. Alleen transform en opacity. Dat is het verschil tussen 80 ms en 220 ms INP op moderne telefoons.

Veld-INP versus lab-INP — waarom ze verschillen

Een sluipend probleem bij INP-optimalisatie: lab-data en veld-data wijken vaak ver uit elkaar. In het lab klikt Lighthouse één keer op het eerste interactieve element en rapporteert de tijd. Veld-data verzamelt over 28 dagen alle interacties van alle bezoekers en pakt de p75 van de slechtste interactie per sessie.

Drie patronen die je in veld-data ziet en in lab niet:

• Het derde scroll-event op een lazy-loadende pagina. Bij scroll 3 zijn drie nieuwe carousels gehydrateerd, de browser hapert. Veld-INP loopt op tot 400 ms. Lab ziet dit niet omdat Lighthouse niet scrollt.
• Formulier-interacties op een trage device. Een Samsung A52 uit 2021 doet vier keer langer over formulier-validatie dan een Pixel 8. Lab gebruikt een mid-range profiel, veld toont de werkelijkheid.
• Chat-widget die pas opent na 5 seconden idle. In het lab klikt de tester binnen 2 seconden. In het veld klikken bezoekers gemiddeld 8-15 seconden na load — precies wanneer de chat-widget zijn hydration-werk doet.

Optimaliseer altijd voor veld-INP. Lab is een diagnose-tool, geen succes-meting. Plaats web-vitals.js (5 KB) op je site om real-user INP te verzamelen en stuur de data naar je analytics. Binnen twee weken weet je welke interacties op welke pagina's de boosdoener zijn.

Wat doe je vandaag?

Open je site op je telefoon. Tik op het hamburger-menu, productfoto, contact-knop, formulier-veld. Voel je vertraging tussen tik en respons? Dan zit je INP boven 200 ms. Open Chrome DevTools op je laptop, ga naar je site, klik op een traag-aanvoelend element en bekijk wat er gebeurt in de Performance Insights tab. Negen van de tien keer is het één van drie boosdoeners: een trage chat-widget, een te grote slider, of een tracker-bundel die te vroeg laadt. Eén van de drie kun je vandaag nog uitschakelen, opnieuw meten, en zien dat INP zakt. Eén concrete fix is meer waard dan een dag plannen maken.

Gerelateerde gidsen

• Core Web Vitals voor MKB
• LCP fixen 2026
• CLS uitleg
• Diagnose: mijn website is traag

FAQ — INP

Door Lorenzo Ruisi — DesignCheck. Laatst bijgewerkt 16 mei 2026.