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

Interaction to Next Paint is de moeilijkste Core Web Vital voor AI-agenten. Het kan niet worden gesimuleerd. Lighthouse heeft geen INP-score. Een AI-agent zonder echte gebruikersdata kan je niet vertellen welke interactie traag is, wie deze ervaart, of wanneer in de levenscyclus van de pagina dit gebeurt. Dit is hoe je INP oplost wanneer je velddata hebt.

Laatst beoordeeld door Arjen Karel in maart 2026

Waarom INP anders is voor AI-agenten

INP meet hoe snel je site reageert op gebruikersinteracties: klikken, tikken, toetsaanslagen. Het kiest de enige slechtste interactie uit de hele sessie. Het sleutelwoord is echt. Een gebruiker klikt op een filter-dropdown op je productpagina terwijl er een analytics-script van een derde partij wordt uitgevoerd. 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 responstijd op interacties die op onvoorspelbare momenten tijdens de sessie plaatsvinden. Een pagina met nul TBT kan nog steeds een vreselijke INP hebben als een achtergrondtimer op het verkeerde moment afgaat. Een agent zonder velddata is hier blind voor. Het optimaliseert TBT en claimt de overwinning terwijl echte gebruikers 400ms wachten tot hun klikken worden geregistreerd.

Drie fases, drie verschillende oplossingen

INP valt uiteen in drie fases. Elke fase betekent een andere oplossing.

Input Delay: De main thread was bezig toen de gebruiker interactie had. Tijdens de laadstatus zijn de gebruikelijke oorzaken het uitvoeren van grote JavaScript-bundels, het initialiseren van analytics-scripts, of framework hydration. Bij de voltooide status (pagina volledig geladen), ligt de oorzaak bij achtergrondtimers, scripts van derden die pollen voor updates, of service worker-activiteit.

Processing: De event handler zelf is te traag. Layout thrashing (DOM lezen, DOM schrijven, DOM lezen in een loop), synchrone DOM-query's binnen de handler, dure re-renders, of simpelweg te veel werk doen in een enkele taak zonder yielding.

Presentation: De browser doet er te lang over om te painten nadat de handler klaar is. Grote DOM-bomen (duizenden nodes die herberekening van stijlen nodig hebben), ontbrekende CSS containment, of dure paint-operaties die worden getriggerd door de DOM-wijzigingen van de handler.

Welk script blokkeert je pagina

CoreDash legt Long Animation Frames (LoAF) attributie vast van echte gebruikerssessies. Dit is wat de agent in staat stelt om INP daadwerkelijk te fixen in plaats van te gokken.

LoAF benoemt exact het JavaScript-bestand, de functie en de duur. De agent raadt niet welk script de main thread blokkeert. CoreDash vertelt het: gtm-container.js blokkeerde de main thread gedurende 280ms tijdens de interactie op het filter van de afrekenpagina.

In plaats van "je pagina is traag" krijg je "dit bestand, deze functie, deze duur." Vergelijk dat met Lighthouse, die je vertelt dat de Total Blocking Time 450ms is en het aan jou overlaat om uit te zoeken welk van je 30 scripts dit heeft veroorzaakt.

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

Laden versus geladen: twee verschillende problemen

Of de interactie plaatsvond tijdens de loading of complete status verandert de oplossing volledig.

Als INP alleen slecht is tijdens de loading status, is het probleem de laadvolgorde van scripts. Te veel JavaScript dat wordt uitgevoerd voordat de pagina interactief is. De oplossing zit in script deferral: defer niet-kritieke scripts, pas code-splitting toe, reduceer parser-blokkerende JavaScript.

Als INP slecht is bij de complete status, heb je een runtime JavaScript probleem. Er draait iets op de achtergrond op een volledig geladen pagina. Scripts van derden die pollen voor updates, analytics die beacons versturen, of je eigen code die dure operaties uitvoert op een timer.

CoreDash trackt de laadstatus van de pagina voor elke INP-meting. CWV Superpowers gebruikt dit om de helft van de oorzaken uit te sluiten voordat er naar scripts wordt gekeken.

Proportioneel redeneren voor INP

INP is 350ms op de afrekenpagina. De fase-uitsplitsing uit velddata:

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

Presentation is de bottleneck. 200ms klinkt op zichzelf niet alarmerend. Maar het is 57% van het totaal. Het fixen van Presentation zet meer zoden aan de dijk dan het optimaliseren van Input Delay of Processing gecombineerd.

Zonder de percentages jaagt een agent op Input Delay omdat 70ms een bepaalde drempel overschrijdt. Toon de uitsplitsing en hij gaat rechtstreeks voor de 57%. Het resultaat: één fix die INP onder de 200ms brengt versus drie versnipperde fixes die nauwelijks effect hebben.

Typische oplossingen per fase

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

Input Delay bij voltooid: Audit scripts van derden die draaien na het laden van de pagina. Gebruik de LOAF-data van CoreDash om het daderscript te vinden. Defer het naar idle tijd met requestIdleCallback.

Processing: Yield naar de main thread met scheduler.yield() of setTimeout(0). Splits lange event handlers op in kleinere taken. Vermijd forced layouts (het lezen van lay-out eigenschappen onmiddellijk na het schrijven naar de DOM).

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

Verifiëren met velddata

INP-verbeteringen zijn binnen een dag of twee aan echt verkeer zichtbaar in CoreDash. Query dezelfde pagina en apparaatsegment. De p75 zou moeten dalen en de faseverdeling zou moeten verschuiven.

Let ook op de verdeling van de laadstatus. Als je fix was gericht op INP in de loading status, bevestig dan dat de cijfers van de loading status zijn verbeterd zonder dat de cijfers van de complete status zijn verslechterd. Velddata geeft je deze granulariteit. Labdata niet.