Largest Contentful Paint (LCP)-problemen oplossen en identificeren

Deze gids maakt deel uit van de Largest Contentful Paint (LCP)-hub. LCP meet hoe snel het grootste zichtbare element rendert. Google wil dit onder de 2,5 seconden houden. Wat volgt is het exacte diagnostische proces dat ik inzet bij advies over paginasnelheid.

De gids van een consultant voor het diagnosticeren en oplossen van de LCP

Mijn naam is Arjen Karel en ik ben consultant voor paginasnelheid. Ik heb de afgelopen jaren honderden websites geaudit. Een van de meest hardnekkige problemen is de Largest Contentful Paint (LCP). In deze gids deel ik de exacte methodologie die ik gebruik om LCP-problemen te diagnosticeren en op te lossen. Je ziet vermeldingen van CoreDash. Dit is een RUM-tool die ik bouwde voor de precieze data die dit proces vereist. De principes hier zijn universeel. Toch geloof ik in het tonen van echte voorbeelden uit de tools die ik dagelijks bouw en gebruik.

De LCP verbeteren is een eliminatieproces. Volgens de 2025 Web Almanac slaagt slechts 66% van de mobiele origins voor de LCP. Dat betekent dat een derde van het web een laadprobleem heeft. Vind de traagste fase, los deze op, meet opnieuw.

De diagnostische methodologie: eerst field data, dan lab data

Om effectief te optimaliseren, moet je een diagnostische workflow in twee stappen aannemen. Dit zorgt ervoor dat je problemen oplost die je gebruikers daadwerkelijk ervaren, en niet slechts jaagt op scores in een labomgeving.

1. Field data (RUM & CrUX) laat je zien WAT er gebeurt. Field data wordt verzameld via echte gebruikers die je site bezoeken. Het vertelt je of je een LCP-probleem hebt, welke pagina's zijn geraakt, en welke gebruikers (mobiel of desktop) het ervaren. Je moet altijd hier beginnen om te bevestigen dat er een echt probleem is.
2. Lab data (Lighthouse, DevTools) helpt je te diagnosticeren WAAROM het gebeurt. Lab data wordt verzameld in een gecontroleerde, gesimuleerde omgeving. Zodra je field data een probleem op een specifieke pagina heeft bevestigd, kun je labtools gebruiken om het probleem consistent te repliceren en het laadproces te ontleden. Zo vind je de oorzaak.

Start met field data. Zo richten je optimalisaties zich op wijzigingen die daadwerkelijk echte gebruikers beïnvloeden.

Stap 1: LCP-problemen identificeren met field data

Je eerste taak is data van echte gebruikers inzetten om te bevestigen óf en welke pagina's een slechte LCP hebben.

Een toegankelijk startpunt: Google Search Console

Een logische plek om te beginnen is het Core Web Vitals-rapport in Google Search Console. Log in, navigeer naar het rapport en bekijk de grafieken voor mobiel en desktop. Als Google URL's markeert met "LCP-probleem: langer dan 2,5 s", heb je bevestiging uit het Chrome User Experience (CrUX) Report dat een percentage van je gebruikers een slechte ervaring heeft.

Search Console bevestigt het probleem. Het updatet echter traag en groepeert URL's. Voor details op paginaniveau in realtime heb je een RUM-tool nodig.

Real User Monitoring (RUM): Details op paginaniveau

Je kunt je eigen RUM-setup bouwen met de web-vitals library om data naar je analytics backend te sturen. Dat is echter een aanzienlijke technische inspanning.

Ik heb CoreDash specifiek hiervoor gebouwd. Je voegt één scripttag toe en het start direct met het verzamelen van LCP-data van elke echte bezoeker, opgesplitst naar pagina, apparaat en element.

Een goede RUM-tool laat je het volgende zien:

• Je exacte LCP-score voor een specifieke URL.
• Een uitsplitsing van elk LCP-element (bijv. een afbeelding of kop) en welke het vaakst geassocieerd worden met een trage LCP.
• De exacte timing van elk van de vier LCP-fases voor elke paginaweergave, om de bottleneck aan te wijzen.

Verder kijken dan het LCP-element zelf is cruciaal. In een goed gedocumenteerde case study verbeterde Vodafone hun LCP met 31%, wat direct bijdroeg aan 8% meer sales. Hun optimalisatie focuste op het identificeren en oplossen van de specifieke LCP-bottleneck op belangrijke landingspagina's, via een combinatie van field data-analyse en gerichte fixes. LCP-optimalisatie draait niet alleen om de afbeelding. Je moet de volledige laadpijplijn begrijpen: serverrespons, ontdekking van resources, download en paint.

In CoreDash kun je bijvoorbeeld naar de LCP-pagina navigeren en een datatabel bekijken die je traagste LCP-elementen toont. Door op een specifiek element te klikken (zoals een bepaalde CSS-class voor een hero-afbeelding), filter je alle statistieken. Je ziet dan uitsluitend de performancedata voor pagina's waar dat element de LCP was.

Het doel: gebruik field data om je traagste pagina en het meest voorkomende LCP-element te vinden. Dat is je doelwit.

De LCP meten met de Performance Observer API

De Performance Observer API geeft je direct toegang tot LCP-entries in JavaScript. Dit is dezelfde API die RUM-tools onder de motorkap gebruiken om field data te verzamelen. De volgende snippet logt elke LCP-kandidaat die de browser identificeert, inclusief het element, de grootte en de rendertijd.

const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];
  console.log('LCP element:', lastEntry.element);
  console.log('LCP time:', lastEntry.renderTime || lastEntry.loadTime);
  console.log('LCP size:', lastEntry.size);
});
observer.observe({ type: 'largest-contentful-paint', buffered: true });

Dit is handig voor snelle validatie tijdens development, maar voor productiemetingen moet je de web-vitals library gebruiken. Deze handelt edge cases af, zoals wijzigingen in tabblad-zichtbaarheid en restores uit de back/forward cache.

Stap 2: De bottleneck diagnosticeren met labtools

Je weet welke pagina je moet fixen. Zoek nu uit waarom hij traag is. Draai een test met PageSpeed Insights of het Lighthouse-paneel in Chrome DevTools.

Scroll in het rapport omlaag naar de sectie 'Diagnostics' en zoek de audit 'Largest Contentful Paint element'. Deze watervalgrafiek splitst je LCP-tijd op in zijn vier onderdelen. Je RUM-tool hoort een vergelijkbare uitsplitsing te tonen op basis van je field data.

Je doel is om de langste fase in deze uitsplitsing te vinden. Dat is je primaire bottleneck. Hier moet je je optimalisaties als eerste op richten.

Stap-voor-stap gids: werk je liever in DevTools? LCP diagnosticeren met het Chrome DevTools Performance-paneel toont hoe je een gethrottelde trace opneemt en dezelfde vier onderdelen afleest uit de uitsplitsing van de LCP.

Stap 3: De vier LCP-fases begrijpen

Elke LCP-score is de som van vier opeenvolgende fases. Elke fase heeft een toegewijde gids op deze site die specifieke optimalisatietechnieken behandelt.

• Time to First Byte (TTFB): Dit is de onmisbare basis. Een trage serverrespons is een directe toevoeging aan je LCP, milliseconde voor milliseconde. Voordat je ook maar één afbeelding optimaliseert, moet je zorgen dat je server snel reageert. Leer meer over de TTFB optimaliseren.
• Resource Load Delay: Dit is het 'ontdekkingsprobleem' en een van de meest voorkomende issues. De browser kan geen resource downloaden die hij niet kent. Als je LCP-afbeelding verstopt zit in een CSS- of JavaScript-bestand, of als hij wel in de HTML staat maar andere resources eerst worden opgevraagd, vindt de browser hem te laat. Dit verspilt kostbare tijd. Lees de volledige gids over Resource Load Delay.
• Resource Load Duration: Dit is de downloadtijd van de LCP-resource zelf. Grote, ongecomprimeerde afbeeldingen of trage netwerkomstandigheden kunnen van deze fase een bottleneck maken. Lees de volledige gids over Resource Load Duration.
• Element Render Delay: Dit is het 'te druk om te painten'-probleem. Het LCP-afbeeldingsbestand is mogelijk volledig gedownload, maar als de main thread van de browser geblokkeerd is door zware JavaScript-executie, komt hij er simpelweg niet aan toe om de afbeelding op het scherm te painten. Lees de volledige gids over Element Render Delay.

Zorg altijd eerst dat je TTFB snel is en je LCP-resource vindbaar is, voordat je doorgaat met optimalisaties voor bestandsgrootte of rendering.

Stap 4: De fix uitvoeren

Pas de fix toe zodra de bottleneck is geïdentificeerd. De implementatie hangt af van je stack. Elke fase hieronder behandelt eerst de universele principes, en vervolgens specifieke zaken voor WordPress en JS-frameworks.

1. De Time to First Byte (TTFB) optimaliseren

Als je TTFB traag is (een goed doel is onder de 800 ms), legt dit een hoge bodem voor je LCP. De TTFB verbeteren zal elke andere laadmeting verbeteren.

Universele TTFB-oplossingen

• Caching inschakelen: Dit is een van de meest effectieve manieren om de TTFB te verbeteren. Caching genereert en bewaart een kopie van de pagina. Deze kan dan direct worden uitgeserveerd, zonder te wachten tot de server hem bij elk bezoek opnieuw opbouwt.
• Een CDN gebruiken: Een Content Delivery Network serveert je content vanaf een server die fysiek dicht bij je gebruiker staat. Dit verlaagt de netwerklatency. Je volledige HTML-pagina's cachen op de edge van het CDN is een krachtige strategie voor een snelle, wereldwijde TTFB. Zie voor gedetailleerde tips over CDN-configuratie onze gids over hoe je Cloudflare configureert voor optimale performance.
• Brotli- of Gzip-compressie gebruiken: Zorg dat je server op tekst gebaseerde assets, zoals HTML, CSS en JavaScript, comprimeert. Brotli biedt een betere compressie dan Gzip en geniet de voorkeur.
• HTTP/3 met 0-RTT gebruiken: Zorg dat je server is geconfigureerd voor HTTP/3. Dit biedt aanzienlijke performancevoordelen, waaronder betere multiplexing. Het ondersteunt 0-RTT (Zero Round Trip Time Resumption). Dat elimineert de setup-tijd van de verbinding voor terugkerende bezoekers, wat direct een TTFB-boost geeft.
• 103 Early Hints gebruiken: Gebruik voor een geavanceerde boost de statuscode 103 Early Hints. Hiermee kan je server of CDN alvast hints naar de browser sturen over kritieke CSS- en JS-bestanden, terwijl het nog bezig is met het volledige HTML-document. Hierdoor kunnen downloads nog eerder starten. Voor een complete implementatiegids, zie ons artikel over 103 Early Hints.

Platform-specifieke TTFB-fixes

Op WordPress:

• Investeer in kwalitatieve hosting: Op WordPress hangt een trage TTFB vaak samen met de hostingomgeving. Goedkope shared hosting kan een bottleneck zijn. Overweeg een managed WordPress-host die is geoptimaliseerd voor performance.
• Gebruik een caching-plugin: Een hoogwaardige caching-plugin (bijv. WP Rocket of W3 Total Cache) is niet optioneel. Deze verzorgt de generatie van statische HTML-bestanden, wat de basis vormt voor effectieve caching op dit platform.

Op een JS-framework:

• Kies het juiste hostingplatform: Voor Node.js-applicaties zijn platforms als Vercel of Netlify enorm geoptimaliseerd voor SSR/SSG-frameworks. Zij bieden out of the box intelligente caching en executie van serverless functies.
• Implementeer SSR-caching: Als je Server-Side Rendering gebruikt, cache de gerenderde pagina dan op de server (bijv. met Redis of een in-memory cache). Dit voorkomt dat je pagina's bij elke request opnieuw moet renderen.
• Pas op voor serverless cold starts: Gebruik je serverless functies voor rendering? Wees je er dan van bewust dat een "cold start" (de eerste request na een periode van inactiviteit) een hoge TTFB kan hebben. Gebruik provisioned concurrency of keep-alive strategieën om dit te beperken.

2. De Resource Load Delay reduceren

Dit is vaak de grootste bottleneck. Het betekent dat de browser klaar was om te werken, maar je belangrijkste afbeelding of fontbestand niet direct kon vinden. Deze vertraging wordt veelal veroorzaakt door één van twee problemen: de resource wordt laat ontdekt, of hij krijgt een lage downloadprioriteit. Lees voor de complete uitleg onze toegewijde gids over Resource Load Delay.

Universele Load Delay-oplossingen

De universele oplossing voor Resource Load Delay is zorgen dat je LCP-resource ontdekbaar is in de initiële HTML-markup én een hoge prioriteit krijgt van de browser. Dit bereik je zo:

• Maak de LCP-resource vindbaar: De belangrijkste stap is zorgen dat je LCP-element staat in de HTML die de server verzendt. Browsers gebruiken een snelle 'preload scanner' om in de ruwe HTML vooruit te kijken naar resources zoals afbeeldingen en scripts. Als je LCP-afbeelding inlaadt via een CSS background-image of via JavaScript wordt geïnjecteerd, is hij onzichtbaar voor de scanner. Dit geeft forse vertraging. De meest robuuste oplossing is altijd het gebruik van een standaard <img>-tag met een src-attribuut in je server-rendered HTML.
• Stuur de laadvolgorde met preload: Kun je de LCP-resource niet direct vindbaar maken (een klassiek probleem bij fonts of CSS-achtergrondafbeeldingen)? Dan is het gebruik van <link rel="preload"> de op één na beste optie. Deze tag is een expliciete instructie in je HTML <head>. Hij vertelt de browser om een kritieke resource veel eerder te downloaden dan hij hem normaal gesproken zou hebben gevonden. Voor implementatiedetails en voorbeelden, zie onze gids over hoe je de LCP-afbeelding preloadt.
• Zorg voor een hoge prioriteit met fetchpriority: Zelfs als een resource vindbaar is, krijgt hij van de browser niet per se de hoogste downloadprioriteit. De toevoeging fetchpriority="high" aan je <img>-tag of <link rel="preload">-tag is een sterke hint voor de browser. Het geeft aan dat deze specifieke resource essentieel is voor de UX. Zo help je de browser de strijd om de bandbreedte te winnen van andere resources.

Platform-specifieke Load Delay-fixes

Op WordPress:

• Vermijd achtergrondafbeeldingen uit page builders: Veel page builders maken het makkelijk om een hero-afbeelding in te stellen als CSS background-image op een div. Dit maakt hem onzichtbaar voor de preload scanner van de browser. Gebruik indien mogelijk liever een standaard <img>-blok. Lukt dat niet, dan heb je waarschijnlijk een plugin of custom code nodig om specifiek die afbeelding te preloaden.
• Schakel lazy loading voor de LCP-afbeelding uit: Veel optimalisatie-plugins passen automatisch lazy loading toe op alle afbeeldingen. Zoek de instelling in je plugin om de LCP-afbeelding (en idealiter de eerste paar afbeeldingen op de pagina) uit te sluiten van lazy loading. Dit is zo'n veelgemaakte fout dat we een compleet artikel hebben over het fixen van lazy loaded LCP-afbeeldingen.

Op een JS-framework:

• Gebruik Server-Side Rendering (SSR): Dit is vaak de fix met de grootste impact. Een standaard Client-Side Rendered (CSR) React-app levert minimale HTML. Het LCP-element bestaat pas nadat een grote JS-bundel is gedownload en uitgevoerd. SSR-frameworks als Next.js of Remix leveren de complete HTML, inclusief de <img>-tag. Zo kan de browser hem direct ontdekken.
• Gebruik framework-specifieke image-componenten: Frameworks zoals Next.js bieden een image-component met een priority prop. Als je de priority prop gebruikt, pas je automatisch fetchpriority="high" en andere optimalisaties toe op je LCP-afbeelding.

3. De Resource Load Duration verlagen

Zorgen dat je LCP-resource zo klein mogelijk is, blijft een essentieel onderdeel van het proces. Deze fase draait om hoelang het duurt om het LCP-resourcebestand te downloaden via het netwerk. Zie voor een complete gids over optimalisatietechnieken voor afbeeldingen ons artikel over de LCP-afbeelding optimaliseren, en meer specifiek over de Resource Load Duration.

Universele Load Time-oplossingen

• Beperk de bestandsgrootte met moderne formaten en responsive afbeeldingen: De snelste manier om downloadtijd te verkorten, is een kleiner bestand maken. Voor afbeeldingen betekent dit het inzetten van moderne, enorm efficiënte formaten zoals AVIF of WebP. Dien tevens responsive afbeeldingen op via het <picture>-element of via de srcset- en sizes-attributen. Zo ontvangt een bezoeker op een mobiel apparaat netjes een afbeelding die is geschaald voor zijn kleinere scherm. Hij wordt dan niet gedwongen om een massieve desktop-afbeelding te downloaden. Een 400 pixel breed mobiel scherm heeft gewoon geen 2000 pixel brede afbeelding nodig. Zorg er bij op tekst gebaseerde LCP's voor dat je fonts in het efficiënte WOFF2-formaat zijn. Subset ze om ongebruikte tekens te strippen.
• Beperk netwerkcontention: De LCP-resource concurreert om de beperkte bandbreedte van de gebruiker. Door niet-kritieke resources uit te stellen (zoals analytics-scripts of CSS voor below-the-fold content) maak je bandbreedte vrij. De browser kan zich zo focussen op het versneld downloaden van de LCP-resource.
• Host kritieke resources op je hoofddomein: Voorkom waar mogelijk het inladen van je LCP-resource vanaf een ander domein. Het opzetten van een nieuwe verbinding met een andere server levert tijdrovende DNS lookups en handshakes op.

Platform-specifieke Load Time-fixes

Op WordPress:

• Gebruik een plugin voor afbeeldingsoptimalisatie: Tools als ShortPixel of Smush comprimeren afbeeldingen automatisch bij het uploaden. Ze zetten deze om naar moderne formaten als WebP/AVIF en genereren direct responsive srcset formaten.
• Schaal afbeeldingen handmatig: Verklein je afbeeldingen voor je ze uploadt tot maximaal het vereiste formaat. Upload geen 4000px brede afbeelding voor een vlak dat op de grootste schermen hooguit 1200px breed is.

Op een JS-framework:

• Gebruik een image-CDN: Dit is een enorm krachtige oplossing. Diensten als Cloudinary, Imgix of Akamai's Image & Video Manager automatiseren het volledige optimalisatieproces. Jij uploadt één hoogwaardige afbeelding. Zij leveren via een snel CDN aan iedere gebruiker een perfect geschaalde, gecomprimeerde en geformatteerde versie.
• Benut build tools: Importeer je een afbeelding binnen een component in een modern framework? Dan kan je build tool (zoals Webpack of Vite) het bestand automatisch hashen en optimaliseren als onderdeel van de build.

4. De Element Render Delay verkorten

De resource is succesvol gedownload, maar staat nog niet op het scherm. Dit betekent dat de main thread van de browser druk is met andere taken en het element niet kan painten. Dit is nog een ontzettend veelvoorkomende en flinke bottleneck. Lees voor de complete uitleg onze gids over Element Render Delay.

Universele Render Delay-oplossingen

• Stel ongebruikte JavaScript uit of verwijder het: Alle JS die niet essentieel is voor het renderen van het initiële, zichtbare deel van de pagina, hoor je uit te stellen. Gebruik hiervoor de defer of async attributen.
• Gebruik kritieke CSS: Een grote, render blocking stylesheet kan het renderen ophouden. De techniek rondom kritieke CSS draait om het extraheren van slechts die minimale CSS die nodig is voor de above-the-fold content. Je plaatst deze inline in de <head> en laadt de rest van de stijlen asynchroon in.
• Splits long tasks op: Een langlopend script kan de main thread lange tijd blokkeren. Hierdoor loopt het renderen vast. Dit is tevens een hoofdoorzaak van een slechte Interaction to Next Paint (INP). Splits je code op in kleinere, asynchrone blokken die yielden aan de main thread.

Platform-specifieke Render Delay-fixes

Op WordPress:

• Audit je plugins: Een teveel aan plugins, en dan vooral de zware zoals sliders of ingewikkelde page builders, laden vaak bakken CSS en JS in. Dit blokkeert de main thread. Deactiveer de plugins een voor een om de performancevreters op te sporen.
• Gebruik een lichtgewicht thema: Een bloated thema met talloze functies die je toch niet gebruikt is een bekende bron van render blocking code. Kies voor een thema dat gefocust is op performance.
• Gebruik plugin asset managers: Via tools als Asset CleanUp of Perfmatters schakel je conditioneel de CSS en JS van specifieke plugins uit op pagina's waar ze compleet overbodig zijn.

Op een JS-framework:

• Code splitting is cruciaal: Verscheep nooit de JavaScript van je hele app in één gigantische bundel. Splits je code per route (zodat gebruikers louter de code voor hun specifieke pagina downloaden) en per component.
• Lazy load componenten: Gebruik React.lazy en Suspense om lazy loading toe te passen op componenten die niet direct in beeld staan (zoals componenten below the fold of in modals). Zo houd je ze netjes uit de initiële bundel.

Geavanceerd: De LCP optimaliseren voor volgende navigaties

De initiële LCP fixen is belangrijk. Je kunt het browsen op je site echter direct laten aanvoelen door te optimaliseren voor daaropvolgende paginaweergaven.

Zorg dat pagina's in aanmerking komen voor de Back/Forward Cache (bfcache)

De bfcache is een browseroptimalisatie die een complete momentopname van een pagina in het geheugen vasthoudt als een gebruiker wegnavigeert. Klikt hij vervolgens op de terug-knop, dan herstelt de pagina direct. Resultaat: een LCP van vrijwel nul. Veel pagina's diskwalificeren zich helaas voor deze cache door toevoegingen als unload event listeners. Gebruik de Lighthouse "bfcache" audit om je pagina's te testen en strip alle blokkerende features.

Gebruik de Speculation Rules API voor prerendering

Met de Speculation Rules API dicteer je de browser declaratief naar welke pagina's een gebruiker waarschijnlijk navigeert. De browser kan deze pagina's vervolgens alvast op de achtergrond fetchen en prerenderen. Klikt de gebruiker op een link naar een geprerenderde pagina, dan verloopt de navigatie instantaan. Dit leidt tot een LCP van vrijwel nul. Je definieert deze regels met een <script type="speculationrules">-tag in je HTML.

<script type="speculationrules">
 {
  "prerender": [{
   "source": "document",
   "where": {
    "href_matches": "/products/*"
   },
   "eagerness": "moderate"
  }]
 }
 </script>  

Dit voorbeeld stelt in dat de browser op de huidige pagina speurt naar links die doorverwijzen naar productpagina's. Zodra een gebruiker over de link hovert, start het prerenderen.

Werk de vier fases keurig op volgorde af. Fix de grootste bottleneck eerst, meet nog eens, herhaal.

Volgende stappen: elke LCP-fase in detail

Elke LCP-fase kent een eigen gids:

• De LCP-afbeelding optimaliseren: Een complete gids voor het kiezen van afbeeldingsformaten, responsive afbeeldingen, preloading en veelgemaakte fouten bij de optimalisatie van afbeeldingen.
• Resource Load Delay: Hoe je met preload, fetchpriority en een solide HTML-structuur regelt dat de browser je LCP-resource zo vroeg mogelijk ontdekt.
• Resource Load Duration: Hoe je de downloadtijd van je LCP-resource verkleint via compressie, moderne formaten, CDN-configuraties en netwerkoptimalisatie.
• Element Render Delay: Hoe je de main thread van de browser vrijspeelt zodat hij het LCP-element direct na het downloaden kan painten, met een focus op kritieke CSS, JavaScript uitstellen en content-visibility.