Los LCP op met een AI-agent: Van velddata naar codefix

Een trage Largest Contentful Paint heeft vier mogelijke oorzaken. Een AI-agent gekoppeld aan velddata kan identificeren wat uw daadwerkelijke bottleneck is, dit traceren in Chrome en de fix genereren. Dit is de volledige LCP-diagnoseworkflow met CWV Superpowers.

Laatst beoordeeld door Arjen Karel in maart 2026

De vier LCP-fases

Google deelt LCP op in vier fases. Elk heeft andere oorzaken en andere oplossingen.

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

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

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

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

De bottleneck vinden met proportioneel redeneren

Lighthouse vertelt u "LCP is 3.8 seconden." Dat is het totaal. Het vertelt u niet welke fase u moet fixen.

CWV Superpowers haalt de faseverdeling uit CoreDash velddata en interpreteert dit proportioneel. De bottleneck is de fase die het grootste deel van de totale tijd in beslag neemt. Niet de fase die een bepaalde absolute drempel overschrijdt.

Concreet voorbeeld. LCP is 3.800 ms op mobiele productpagina's. De verdeling van echte gebruikers:

• TTFB: 600ms (16%)
• Load Delay: 1.900ms (50%)
• Load Time: 800ms (21%)
• Render Delay: 500ms (13%)

Load Delay is de bottleneck. De helft van de totale LCP-tijd is de browser die wacht om te ontdekken dat de afbeelding bestaat. Een Lighthouse-audit zou slechts "3.8 seconden" zeggen en suggereren om afbeeldingen te comprimeren. Afbeeldingscompressie lost Load Time op, wat 21% van het probleem is. De echte fix zit in de 50%.

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

Waarom de browser uw afbeelding laat vindt

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

Drie veelvoorkomende oorzaken. De afbeelding is een CSS background image die onzichtbaar is voor de preload scanner. De afbeeldings-URL is 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. U ziet een flink gat in de network waterfall tussen de aankomst van de HTML en het afvuren van de afbeeldingsrequest. Dat gat is uw Load Delay. Op de sites die ik audit, is dit 1.500 tot 2.500 ms op mobiel. Twee volle seconden waarin de browser de HTML heeft maar geen idee heeft dat de hero-afbeelding nodig is.

De agent ziet hetzelfde gat. Hij matcht de waterfall met de CoreDash-verdeling en vertelt u precies waarom de afbeelding laat was.

Hoe de diagnose eruitziet

Dit is hoe de output eruitziet:

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

Dat is de volledige diagnose. De agent heeft het bestand gevonden en de diff geschreven. U controleert het en zet het live.

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 vanuit 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 deze 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 webfonts die van invloed zijn 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 database-querytijd. Gebruik 103 Early Hints om de browser te laten beginnen met het pre-loaden van resources terwijl de server nog steeds de response genereert.

De fix verifiëren

Vraag na het deployen de CoreDash velddata op voor dezelfde pagina en hetzelfde apparaatsegment. Velddata updatet naarmate echte gebruikers de pagina laden. Ik check doorgaans na 24 tot 48 uur aan verkeer. De LCP p75 zou moeten dalen en de verdeling van de bottleneck-fase zou moeten verschuiven.

Dit is de stap die fixes op basis van velddata onderscheidt van giswerk met Lighthouse. U hoopt niet dat de fix werkte. U ziet het in echte gebruikerscijfers.