Budget voor interactie-latency

Interactie-latencybudget is een prestatieplafond voor hoe lang een pagina erover mag doen om visueel te reageren na een klik, tik of toetsaanslag. Het is belangrijk omdat het teams een hard getal geeft om op te sturen, en dat getal direct gekoppeld is aan Interaction to Next Paint (INP), dat door Google wordt gebruikt binnen Core Web Vitals.

Wat het in de praktijk betekent

De meeste teams praten over INP nadat de schade al is aangericht. Een interactie-latencybudget zet dat om. Je stelt een doel in, zoals 150 ms bij p75 op mobiel voor kern-templates, en dwingt product-, engineering- en marketingbeslissingen om binnen die grens te blijven.

Dat is het nuttige deel. Niet het label. Het budget wordt een releaselimiet voor JavaScript, hydratatie, personalisatie en scripts van derden.

Google’s guidance voor Core Web Vitals blijft onder 200 ms INP als “goed” behandelen. John Mueller van Google heeft herhaaldelijk gezegd dat CWV op zichzelf geen enorme rankinghefboom zijn, maar ze tellen wanneer veel pagina’s anders vergelijkbaar zijn. Dat is de eerlijke positionering: ILB kan zwakke content of slechte interne links niet redden, maar het kan voorkomen dat vermijdbare UX-trageheid zich opstapelt op SEO-problemen.

Hoe SEO-teams het gebruiken

Stel budgets in per template, niet op basis van gemiddelden voor het hele platform. Startpagina’s, categoriepagina’s, productpagina’s en checkout hebben verschillende taken en dragen verschillende hoeveelheden scripts. Eén globale target verbergt waar de echte schade zit.

• Gebruik field data: Gebruik Google Search Console om trends te valideren en verzamel vervolgens page-level RUM met web-vitals, Datadog of SpeedCurve.
• Debug in labtools: Gebruik Chrome DevTools en Lighthouse voor langdurige taken en crawl daarna templates met Screaming Frog om pagina-types met veel scripts in kaart te brengen.
• Correlatie met SEO-pagina’s: Haal landingspagina’s uit GSC, combineer ze met INP-data en controleer of URL’s met veel vertoningen ook jouw slechtste responders zijn.
• Let op third parties: Tag managers, consentplatformen, chatwidgets en A/B-testtools zijn terugkerende boosdoeners. Eén extra vendorscript kan 50-150 ms toevoegen aan de interactievertraging op mid-range Android-apparaten.

Ahrefs, Semrush en Moz meten ILB niet direct, maar ze helpen prioriteren welke URL’s als eerste engineeringcapaciteit verdienen: pagina’s met rankings, links en omzetpotentieel.

Praktische doelen

Voor de meeste serieuze sites is een logisch startpunt:

• <150 ms p75 op branded en top-entry templates
• <200 ms p75 over mobiele organische landingspagina’s
• Long tasks onder 50 ms tijdens veelvoorkomende interacties
• Opnieuw testen na elke grote release van script of framework

Als je consequent boven 250 ms zit, is het probleem meestal niet één micro-optimalisatie. Het is een architectuurkwestie: te veel client-side rendering, opgeblazen bundles, of te veel dependencies van derden.

Waar het misgaat

Hier is de kanttekening. ILB is geen formele Google-metriek. INP is dat wel. Dus verzin geen budget, haal het in Lighthouse en ga er niet vanuit dat field performance vastligt. Data uit echte gebruikers is rommelig. Apparaatmix, netwerkcondities, consentbanners en scripts per land kunnen je nette labcijfers volledig verstoren.

Verwar “snelle first paint” ook niet met responsieve interactie. Surfer SEO helpt je hier niet mee. Ook niet 5 KB van CSS afschaven als je main thread wordt geblokkeerd door 400 KB JavaScript en een tag manager die bij klik zes vendors afvuurt.

De waarde van een interactie-latencybudget is discipline. Het dwingt tot afwegingen voordat regressies productie bereiken. Daarom gebruiken goede teams het.