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

Interaction to Next Paint is de moeilijkste Core Web Vital voor AI-agents. 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 fixt wanneer je field data hebt.

Laatst beoordeeld door Arjen Karel in maart 2026

Waarom INP anders is voor AI-agents

INP meet hoe snel je site reageert op gebruikersinteracties: klikken, tikken, toetsaanslagen. Het kiest de enkele slechtste interactie uit de hele sessie. Het sleutelwoord is echt. Een gebruiker klikt op een filter-dropdown op je productpagina terwijl een analytics-script van een derde partij wordt uitgevoerd. Die vertraging van 380ms wordt de INP voor die sessie.

Geen enkele lab-tool kan dit reproduceren. Lighthouse gebruikt Total Blocking Time als een 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 gedurende 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 field data 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 fixes

INP is op te splitsen in drie fases. Elk betekent een andere fix.

Input Delay: De main thread was bezig toen de gebruiker een interactie uitvoerde. Tijdens de laadstatus zijn de gebruikelijke oorzaken grote JavaScript-bundels die worden uitgevoerd, analytics-scripts die initialiseren of framework hydration. Bij een voltooide status (pagina volledig geladen), is de schuldige te vinden in achtergrondtimers, scripts van derde partijen 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 is voltooid. Grote DOM-bomen (duizenden nodes die stijlherschrijving nodig hebben), ontbrekende CSS containment, of dure paint-operaties 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 gissen.

LoAF benoemt het exacte JavaScript-bestand, de functie en de duur. De agent gokt niet welk script de main thread blokkeert. CoreDash vertelt het: gtm-container.js blokkeerde de main thread gedurende 280ms tijdens de interactie op de 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 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 fix: defer het, breek het op in kleinere taken, of verwijder het als niemand het nodig heeft.

Laden vs geladen: twee verschillende problemen

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

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

Als INP slecht is bij een voltooide status, heb je een runtime JavaScript-probleem. Er draait iets op de achtergrond op een volledig geladen pagina. Scripts van derde partijen die pollen voor updates, analytics die beacons verzenden, of je eigen code die dure bewerkingen uitvoert op een timer.

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

Proportional reasoning voor INP

INP is 350ms op de afrekenpagina. De faseverdeling uit field data:

• 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 drempelwaarde overschrijdt. Toon het de verdeling en het gaat rechtstreeks voor de 57%. Het resultaat: één fix die INP onder de 200ms laat zakken in plaats van drie verspreide fixes die het nauwelijks in beweging brengen.

Typische fixes 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 derde partijen die na het laden van de pagina draaien. Gebruik de LOAF-data van CoreDash om het overtredende script te vinden. Defer het naar idle time met requestIdleCallback.

Processing: Yield naar de main thread met scheduler.yield() of setTimeout(0). Splits lange event handlers op in kleinere taken. Vermijd geforceerde lay-outs (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 field data

INP-verbeteringen verschijnen binnen een dag of twee aan echt verkeer 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 laadstatus, bevestig dan dat de laadstatus-cijfers verbeterden zonder dat de voltooid-status-cijfers verslechterden. Field data geeft je deze granulariteit. Lab data doet dat niet.