Proportioneel redeneren voor webprestaties

Lighthouse vertelt je een getal. Het vertelt je niet of dat getal het probleem is. Converteer elke fase naar een percentage van het totaal. Het grootste percentage is je bottleneck. Niet de fase die een of andere absolute drempelwaarde overschrijdt. Dit verandert welke fixes je Core Web Vitals daadwerkelijk verbeteren.

Laatst beoordeeld door Arjen Karel in maart 2026

Het probleem met absolute drempelwaarden

Lighthouse zegt "Render Delay is 350ms." Wat doe je daarmee?

Als je totale LCP 700ms is, ja, dan is 350ms Render Delay de helft van het probleem. Los het op.

Maar als je totale LCP 4.200ms is en de TTFB 3.800ms bedraagt, dan is die 350ms Render Delay 8% van het totaal. Het terugbrengen naar nul bespaart 350ms. Je houdt nog steeds een falende LCP van 3.850ms over. Voor 90% is je server het probleem.

Absolute getallen zonder context leiden tot verspilde moeite. Converteer naar percentages en de bottleneck wordt overduidelijk.

Fix eerst het grootste percentage

Zowel LCP als INP zijn op te splitsen in fases. Elke fase neemt een deel van het totaal in beslag. Het grootste deel is je bottleneck. Fix die als eerste.

Dit is niet ingewikkeld. Toch is het verrassend hoeveel performance tools, en inmiddels ook AI-agents, deze stap overslaan en optimaliseren wat een vaste drempelwaarde overschrijdt.

LCP voorbeeld

LCP op je mobiele productpagina's: 3.820ms (slecht). De faseverdeling van echte gebruikers:

• TTFB: 420ms (11%)
• Load Delay: 2.100ms (55%)
• Load Time: 680ms (18%)
• Render Delay: 620ms (16%)

Het verlagen van de 16% Render Delay naar nul bespaart 620ms. Het oplossen van het 55% Load Delay probleem bespaart meer dan 2.000ms. Beide zijn echte problemen. Eén daarvan is de bottleneck.

Een Load Delay van 55% betekent dat de browser de HTML heeft ontvangen, maar de hero image meer dan twee seconden lang niet heeft opgevraagd. De browser kan de afbeelding niet vinden. Deze staat niet in de HTML waar de preload scanner hem kan zien. Voeg een preload hint toe en je halveert de LCP bijna.

INP voorbeeld

INP op de checkout pagina: 350ms (verbetering nodig). De faseverdeling:

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

Zonder percentages optimaliseert een agent Input Delay omdat 70ms een bepaalde drempelwaarde overschrijdt. Laat je de percentages zien, dan richt het zich op Presentation. Daar gaat 57% van de tijd naartoe.

Het fixen van Presentation (grote DOM, ontbrekende CSS containment, dure repaint) brengt de INP van 350ms naar onder de 200ms. Dat brengt je van "verbetering nodig" naar "goed". Het oplossen van de Input Delay van 70ms naar 0ms (onwaarschijnlijk, maar hypothetisch) bespaart 70ms. Je faalt dan nog steeds op 280ms. Dezelfde moeite, een heel ander resultaat.

Wat er gebeurt als agents dit overslaan

Een AI-agent zonder proportionele context doet wat de tool hem vertelt. Lighthouse markeert een lange TBT. De agent optimaliseert TBT. De wijziging is technisch correct. De impact in de praktijk is echter minimaal, want TBT was slechts 20% van het probleem en de 57% bottleneck blijft onaangeroerd.

Ik zie dit patroon constant bij AI-gegenereerde performance fixes. De fix pakt een symptoom aan. De bottleneck blijft. Velddata verbetert niet. De ontwikkelaar vraagt zich af waarom een "correcte" optimalisatie geen enkel effect had.

De ene aanpak verspilt je tijd. De andere lost het daadwerkelijke probleem op.

Hoe je dit doet zonder CWV Superpowers

Je kunt dit handmatig doen. Voor LCP: open Chrome DevTools, draai een performance trace, zoek de LCP-marker in de timeline en meet de vier fases. Converteer elke fase naar een percentage van de totale LCP. Fix als eerste het hoogste percentage.

Voor INP: gebruik de Web Vitals Chrome-extensie of een PerformanceObserver met het event entry type. Neem de INP-interactie op, haal de drie faseduurwaarden op en converteer deze naar percentages.

Of laat CWV Superpowers het automatisch doen met velddata van duizenden echte sessies in plaats van één enkele lab trace.