Fix INP met een AI-agent: de metric die labtools niet kunnen meten

Interaction to Next Paint is voor AI-agents de lastigste Core Web Vital. Je kunt het niet simuleren. Lighthouse heeft geen INP-score. Een AI-agent zonder data van echte gebruikers kan je niet vertellen welke interactie traag is, wie er last van heeft of wanneer in de levenscyclus van de pagina het gebeurt. Zo los je INP op als je field data hebt.

Laatst gecontroleerd door Arjen Karel in maart 2026

Waarom INP anders is voor AI-agents

INP meet hoe snel je site reageert op interacties van gebruikers: klikken, tikken, toetsaanslagen. Het pakt de slechtste interactie uit de hele sessie. Het sleutelwoord is echt. Een gebruiker klikt op een filter-dropdown op je productpagina terwijl er een third-party analyticsscript draait. Die vertraging van 380ms wordt de INP voor die sessie.

Geen enkele labtool kan dit reproduceren. Lighthouse gebruikt Total Blocking Time als proxy, maar TBT meet het blokkeren van de main thread tijdens het laden van de pagina. INP meet de reactietijd op interacties die op onvoorspelbare momenten tijdens de sessie plaatsvinden. Een pagina met een TBT van nul kan alsnog een vreselijke INP hebben als een achtergrondtimer net op het verkeerde moment afgaat. Een agent zonder field data is hier blind voor. Die optimaliseert TBT en roept de overwinning uit, terwijl echte gebruikers 400ms wachten tot hun klikken worden geregistreerd.

Drie fases, drie verschillende fixes

INP valt uiteen in drie fases. Elke fase vraagt om een andere fix.

Input Delay: De main thread was bezig op het moment van de interactie. Tijdens de loading-state zijn grote JavaScript-bundles die draaien, analyticsscripts die initialiseren of framework-hydration de gebruikelijke oorzaken. In de complete-state (pagina volledig geladen) ligt het aan achtergrondtimers, third-party scripts die pollen voor updates of activiteit van service workers.

Processing: De event handler zelf is te traag. Layout thrashing (DOM lezen, DOM schrijven, DOM lezen in een loop), synchrone DOM-queries in de handler, zware re-renders, of simpelweg te veel werk doen in één task zonder te yielden.

Presentation: De browser doet er te lang over om te painten nadat de handler klaar is. Grote DOM-trees (duizenden nodes waarvan de styles opnieuw berekend moeten worden), ontbrekende CSS containment of zware paint-operaties getriggerd door de DOM-wijzigingen van de handler.

Welk script je pagina blokkeert

CoreDash legt Long Animation Frames (LoAF)-attributie vast uit sessies van echte gebruikers. Hierdoor kan de agent INP echt fixen in plaats van te gokken.

LoAF noemt het exacte JavaScript-bestand, de functie en de duur. De agent hoeft niet te gokken welk script de main thread blokkeert. CoreDash vertelt het direct: gtm-container.js blokkeerde de main thread 280ms tijdens de interactie op het filter van de checkout-pagina.

In plaats van "je pagina is traag" krijg je "dit bestand, deze functie, deze duur." Vergelijk dat met Lighthouse: dat vertelt je dat de Total Blocking Time 450ms is en laat jou zelf uitzoeken welk van je 30 scripts de veroorzaker was.

De agent opent het bestand, leest de code en schrijft de fix: defer het, breek het op in kleinere taken of sloop het eruit als niemand het nodig heeft.

Loading vs loaded: twee verschillende problemen

Of de interactie plaatsvond tijdens de loading of complete state verandert de fix volledig.

Is INP alleen slecht tijdens de loading-state, dan is de laadvolgorde van scripts het probleem. Er draait te veel JavaScript voordat de pagina interactief is. De fix zit in script deferral: defer niet-kritieke scripts, pas code-splitting toe, verminder parser-blocking JavaScript.

Is INP slecht in de complete-state, dan heb je een runtime JavaScript-probleem. Er draait iets op de achtergrond van een volledig geladen pagina. Third-party scripts die pollen voor updates, analytics die beacons verstuurt, of je eigen code die zware operaties uitvoert via een timer.

CoreDash houdt de load state van de pagina bij voor elke INP-meting. CWV Superpowers gebruikt dit om de helft van de oorzaken al uit te sluiten voordat je naar scripts kijkt.

Proportioneel redeneren voor INP

De INP op de checkout-pagina is 350ms. De faseverdeling uit de field data:

• Input Delay: 70ms (20%)
• Processing: 80ms (23%)
• Presentation: 200ms (57%)

Presentation is het knelpunt. Op zichzelf klinkt 200ms niet alarmerend. Maar het is wel 57% van het totaal. Presentation fixen levert meer op dan het optimaliseren van Input Delay en Processing bij elkaar.

Zonder die percentages duikt een agent op Input Delay omdat 70ms een bepaalde drempelwaarde overschrijdt. Laat je de verdeling zien, dan gaat hij recht op die 57% af. Het resultaat: één fix die de INP onder de 200ms brengt, tegenover drie versnipperde fixes die amper verschil maken.

Typische fixes per fase

Input Delay tijdens loading: Defer niet-kritieke scripts. Verwijder ongebruikte JavaScript. Pas code-splitting toe, zodat alleen de code voor de huidige pagina laadt.

Input Delay bij complete: Controleer third-party scripts die na het laden van de pagina draaien. Gebruik de LOAF-data uit CoreDash om het veroorzakende script te vinden. Defer het naar idle time met requestIdleCallback.

Processing: Yield naar de main thread met scheduler.yield() of setTimeout(0). Knip lange event handlers op in kleinere taken. Voorkom forced layouts (layout-eigenschappen direct uitlezen nadat je naar de DOM hebt geschreven).

Presentation: Gebruik content-visibility: auto voor grote DOM-secties below the fold (sinds september 2025 ondersteund in alle grote browsers). Beperk het aantal DOM-nodes dat wordt geraakt door de wijzigingen van de handler. Gebruik CSS containment om de repaint te isoleren tot een kleiner gebied.

Verifiëren met field data

INP-verbeteringen zie je in CoreDash al na een of twee dagen met echt verkeer. Filter op dezelfde pagina en hetzelfde device-segment. De p75 moet dalen en de faseverdeling moet verschuiven.

Houd ook de splitsing per load state in de gaten. Was je fix gericht op INP in de loading-state, controleer dan of de cijfers voor de loading-state zijn verbeterd zonder dat de complete-state achteruitgaat. Field data geeft je deze granulariteit. Lab data niet.