Fix LCP met een AI-agent: van field data naar code fix

Een trage Largest Contentful Paint heeft vier mogelijke oorzaken. Een AI-agent gekoppeld aan field data kan identificeren wat jouw daadwerkelijke bottleneck is, dit traceren in Chrome en de fix genereren. Dit is de volledige LCP-diagnose workflow met behulp van CWV Superpowers.

Laatst beoordeeld door Arjen Karel in maart 2026

De vier LCP-fases

Google verdeelt LCP in vier fases. Elke fase heeft andere oorzaken en andere fixes.

TTFB is de tijd van de start van de navigatie tot de eerste byte van de HTML-respons. Trage servers, een ontbrekend CDN, geen caching, lange database query's. Als TTFB de bottleneck is, doet niets anders ertoe totdat je de server fixt.

Load Delay is de tijd tussen het ontvangen van de HTML en het moment waarop de browser de LCP-resource opvraagt. Dit is het ontdekkingsprobleem. Als de LCP-afbeelding in een CSS-achtergrond staat, via JavaScript wordt geladen of verborgen zit achter een reeks redirects, kan de browser niet beginnen met ophalen totdat hij ontdekt dat hij deze nodig heeft.

Load Time is hoe lang het duurt om de LCP-resource te downloaden zodra deze is opgevraagd. Grote afbeeldingen, ontbrekende compressie, een traag CDN, geen responsive srcset.

Render Delay is de tijd tussen het voltooien van de resource-download en het moment waarop de browser deze daadwerkelijk op het scherm tekent. Render-blocking scripts, het laden van web fonts of JavaScript dat de DOM manipuleert voordat het LCP-element zichtbaar wordt.

De bottleneck vinden met proportioneel redeneren

Publieke data over de Core Web Vitals is niet goed genoeg om je te helpen de echte problemen met jouw Core Web Vitals te vinden.  Lighthouse voert een synthetische test uit op een gesimuleerde Moto G Power en rapporteert één LCP-tijd. CrUX aggregeert 28 dagen aan echte Chrome-data tot één p75-waarde per URL. Geen van beide vertelt je wat je moet fixen.

Het wordt erger: geen van beide kan zinvol segmenteren. CrUX combineert gecachte paginaweergaven, niet-gecachte paginaweergaven, nieuwe bezoeken en pagina-herlaadacties tot één p75. Deze zouden als afzonderlijke problemen behandeld moeten worden. Gecachte paginaweergaven kunnen een TTFB-bottleneck hebben door verouderde cache-validatie. Pagina-herlaadacties kunnen een resource-ontdekkingsprobleem verbergen waarbij de browser de LCP-afbeelding bij elk bezoek laat vindt. De gecombineerde p75 maskeert beide.

CrUX voegde LCP-subonderdelen toe in 2025, wat helpt. Maar het is nog steeds een 28-daagse p75 zonder element-, viewport- of andere filtering. Je ziet de faseverhoudingen voor "alle bezoekers van deze URL over de afgelopen maand." Je ziet niet wat er gebeurt op het specifieke apparaattype, het land of de paginatemplate waar het probleem zit.

RUM data segmenteert op al deze dimensies. CWV Superpowers query't die gesegmenteerde data en interpreteert deze proportioneel. De bottleneck is de fase die het grootste deel van de totale tijd in beslag neemt voor het specifieke segment dat faalt. Geen betekenisloos gemiddelde of een Lighthouse-simulatie. Echte data!

Concreet voorbeeld. LCP is 3.800ms op mobiele productpagina's. De breakdown van echte gebruikers voor eerste bezoekers op gecachte paginaweergaven:

• TTFB: 600ms (28,7%)
• Load Delay: 1.900ms (44,6%)
• Load Time: 800ms (19,3%)
• Render Delay: 500ms (7,4%)

Load Delay is de overduidelijke bottleneck. De helft van de totale LCP-tijd is de browser die wacht om te ontdekken dat de afbeelding bestaat. Lighthouse, CrUX of handmatig onderzoek zouden heel veel moeite hebben gehad om deze exacte combinatie van bezoekerskenmerken te vinden die dit probleem veroorzaakte.

Voor een volledige uitleg van deze aanpak, zie proportioneel redeneren voor web performance.

Waarom de browser je afbeelding laat vindt

Load Delay is de meest voorkomende LCP-bottleneck die ik zie. Het betekent dat de browser de HTML ontving, maar pas veel later wist dat hij de hero-afbeelding nodig had.

Drie veelvoorkomende oorzaken. De afbeelding is een CSS-achtergrondafbeelding die onzichtbaar is voor de preload scanner. De afbeeldings-URL wordt opgebouwd in JavaScript. Of de afbeelding staat technisch gezien in de HTML maar heeft een lazy loading attribuut dat de browser te gretig respecteert.

Open de Chrome trace. Je zult een enorm gat zien in de network waterfall tussen de aankomst van de HTML en het vuren van de afbeeldingsrequest. Dat gat is jouw Load Delay. Op de sites die ik audit, is het 1.500 tot 2.500ms op mobiel. Twee volle seconden waarin de browser de HTML heeft, maar geen idee heeft dat hij de hero-afbeelding nodig heeft.

De agent ziet hetzelfde gat. Hij matcht de waterfall met de CoreDash breakdown en vertelt je precies waarom de afbeelding te laat was.

Hoe de diagnose eruitziet

Dit is hoe de output eruitziet:

AI-oorzaak geïdentificeerd: De LCP-afbeelding div.hero-banner > img.product-main op /product/running-shoes-42 wordt 1.980ms te laat ontdekt omdat deze een preload hint mist en geen fetchpriority="high" heeft. CoreDash data: LCP is 3.820ms (poor) op mobiel, p75. Load Delay is de bottleneck met 52% van het totaal. Chrome trace bevestigt: een gat van 1.940ms tussen de HTML first byte en de afbeeldingsrequest in de network waterfall.

Dat is de volledige diagnose. De agent vond het bestand en schreef de diff. Jij controleert het en voert het door.

Typische fixes per fase

Load Delay: Voeg een preload hint toe in de <head>. Stel fetchpriority="high" in op de LCP-afbeelding. Verplaats de afbeelding uit een CSS-achtergrond of JavaScript naar de HTML waar de preload scanner deze kan vinden.

Load Time: Converteer naar WebP of AVIF. Verklein de afbeeldingsdimensies zodat ze overeenkomen met de werkelijke weergavegrootte. Voeg een responsive srcset toe zodat mobiele gebruikers geen desktop-formaat afbeelding downloaden. Zie afbeeldingen optimaliseren voor Core Web Vitals.

Render Delay: Verwijder of stel render-blocking scripts uit die worden uitgevoerd voordat het LCP-element zichtbaar wordt. Controleer font-display op web fonts die invloed hebben op het LCP-tekstelement. Gebruik 103 Early Hints om CSS eerder af te leveren.

TTFB: Voeg een CDN toe. Schakel server-side caching in. Verminder de tijd van database query's. Gebruik 103 Early Hints om de browser resources te laten preladen terwijl de server nog steeds de respons genereert.

De fix verifiëren

Na het deployen query je CoreDash field data voor dezelfde pagina en hetzelfde apparaatsegment. Field data wordt bijgewerkt zodra echte gebruikers de pagina laden. Ik check meestal na 24 tot 48 uur aan traffic. De LCP p75 zou moeten dalen en de verdeling van de bottleneck-fases zou moeten verschuiven.

Dit is het verschil tussen het fixen van een cijfer en het fixen van de user experience. Je wacht geen 28 dagen op een CrUX-update of draait Lighthouse nog een keer in de hoop dat de score omhoog is gegaan. Je ziet de verbetering in echte gebruikerscijfers, op het apparaat en de netwerksegmenten waar het probleem zich voordeed.

Voor INP-diagnose (de metric die niet in een lab gemeten kan worden), geldt dezelfde gesegmenteerde workflow. Voor een bredere blik op hoe AI-agents field data vs lab data gebruiken over alle drie de Core Web Vitals, zie AI-agent Core Web Vitals debugging.