Largest Contentful Paint (LCP): wat het is, hoe je meet & optimaliseert

Hoe wordt LCP berekend?

Chrome meet de LCP van één pageload vanaf het moment dat de bezoeker de pagina opvraagt tot het grootste element in de viewport op het scherm staat. Het meldt een nieuwe kandidaat telkens wanneer het een groter element toont, tot de eerste tik, scroll of toetsaanslag van de bezoeker; de laatste kandidaat is de LCP-waarde.

Het LCP-element kan dus veranderen: eerst is de heading even het grootst, daarna neemt de hero image die plek over. "Last contentful paint" klopt voor de helft en "least contentful paint" klopt niet: de laatste kandidaat telt, en dat is altijd de grootste die tot dan toe op het scherm staat. Google beoordeelt het 75e percentiel van die waarden over 28 dagen.

Waarom gebruikt LCP het grootste element?

Een moderne pagina heeft geen enkel vast moment waarop hij geladen is: lazy loading en scripts blijven data ophalen zolang de bezoeker op de pagina blijft. LCP meet wanneer het grootste element, de belangrijkste content, op het scherm staat. Het speed metrics-team van Chrome bouwde de metric rond één vraag: "wanneer is de belangrijkste content van de pagina zichtbaar voor de gebruiker?"

LCP vs FCP: wat is het verschil?

First Contentful Paint (FCP) is het moment waarop de browser de eerste tekst of afbeelding toont. Largest Contentful Paint (LCP) is het moment waarop de browser het grootste element in de viewport op het scherm zet. FCP vertelt je dat de pagina is begonnen met laden. LCP vertelt je dat de pagina geladen voelt.

Een snelle FCP met een late LCP wijst naar de LCP-afbeelding of naar iets wat die verbergt. Zijn ze allebei laat, begin dan bij de server en de bestanden in de head.

Waarom is LCP belangrijk?

De meeste sites die zakken voor de Core Web Vitals, zakken op LCP: in de CrUX-release voor september 2026 had 68,3% van de origins een goede LCP, tegenover 81,7% voor CLS en 85,4% voor INP. Google gebruikt de LCP van echte Chrome-bezoekers in zijn page experience ranking signals.

Welke elementen kunnen het LCP-element zijn?

Het LCP-element is het grootste van deze elementen in de viewport: een <img>, een <image> binnen een <svg>, de poster of het eerste frame van een video, een element met een CSS url()-achtergrond, of een blok tekst.

Chrome slaat elementen met opacity 0 over, net als afbeeldingen die de hele viewport vullen en beelden met lage entropie: sinds Chrome 112 geldt een afbeelding met minder dan 0,05 bits aan beelddata per getoonde pixel als low-entropy. De grootte van een kandidaat volgt drie regels:

• Alleen het deel binnen de viewport telt, zonder padding, border of margin.
• Tekst telt als de kleinste rechthoek rondom de tekstregels.
• Een afbeelding telt voor de kleinste van twee maten: de eigen pixelgrootte of de afmeting op het scherm.

Een fade-in vanaf opacity 0 telt pas zodra de fade klaar is; de volledige fade wordt dus bij de LCP opgeteld.

Hoe vind je je LCP-element?

Open het Performance-paneel in Chrome DevTools: nog voor je iets opneemt, toont het al het LCP-element van de pagina. PageSpeed Insights en Lighthouse tonen het onder de LCP-breakdown melding, en CoreDash rapporteert LCP per element voor echte bezoekers. Check mobiel en desktop apart: op een telefoon kan een heading groter zijn dan het deel van de foto dat in beeld past.

Wat is een goede LCP-score?

Een goede LCP is 2,5 seconden of minder voor minstens 75% van de pageloads. Tussen 2,5 en 4 seconden heeft verbetering nodig, en meer dan 4 seconden is slecht.

De p75 (het 75e percentiel) van LCP is de tijd die drie op de vier pageloads evenaren of verbeteren. Kijk eerst op het tabblad mobiel van PageSpeed Insights: de field data bovenaan toont de p75 over de afgelopen 28 dagen. Geeft Search Console de melding "LCP issue: longer than 2.5s (mobile)", dan zit een groep URL's voor mobiele bezoekers boven de 2,5 seconden; LCP-problemen identificeren en oplossen leidt je van die melding naar de oorzaak. In Lighthouse telt LCP voor een kwart mee in de Performance-score, maar Google rankt op de LCP die je echte bezoekers ervaren.

Wat laten data van echte bezoekers zien over een trage LCP?

Volgens de State of Web Vitals slagen sites waarvan de LCP-afbeelding uit een stylesheet komt op telefoons minder vaak voor LCP dan sites met de afbeelding in de HTML: 77% tegenover 84%. Dat is een correlatie. In dezelfde data slaagt 70% van de WordPress-sites op telefoons voor LCP, tegenover 95% van de Shopify-sites.

CoreDash mat echte pageloads op 149 projecten in de 28 dagen tot 7 november 2026. Samen lag hun LCP-p75 rond de 1,8 seconden op telefoons en 1,7 seconden op desktop. Bij een LCP met een afbeelding op telefoons was de p75 van elk onderdeel: 580 ms time to first byte, 350 ms resource load delay, 130 ms resource load duration en 550 ms element render delay. Elk getal is de p75 van dat losse onderdeel; de vier tellen dus niet direct op tot de LCP.

Wil je dit voor je eigen bezoekers zien, open dan LCP in CoreDash op mobiel en kijk naar Phase breakdown.

CoreDash Phase breakdown: de langste balk is het onderdeel dat je als eerste aanpakt.

Wat zijn de vier onderdelen (fases) van LCP?

De LCP van een afbeelding bestaat uit vier opeenvolgende onderdelen: time to first byte, resource load delay, resource load duration en element render delay. Een tekst-LCP heeft alleen het eerste en het laatste: het wachten op stylesheets en een webfont telt als render delay.

Van links naar rechts: het wachten op de HTML, het wachten tot de afbeelding wordt opgevraagd, de download, en het wachten tot de afbeelding op het scherm staat.

Volgens de State of Web Vitals is time to first byte op twee van de drie sites het grootste onderdeel van LCP op telefoons; de download van de afbeelding is dat op ongeveer één op de vijftig sites. Het comprimeren van de LCP-afbeelding is de fix die mensen als eerste proberen, maar op de meeste sites verkort dat juist het kleinste deel.

Lighthouse en DevTools tonen de onderdelen in de LCP-breakdown melding (oudere namen: "Largest Contentful Paint element", "LCP by phase").

Op een testpagina opgezet als de WordPress-site van een makelaar, met Elementor en een slider, bracht het stap voor stap aanpakken van elk onderdeel de LCP op een gethrottelde telefoon terug van 6,70 naar 2,18 seconden. Het omzetten van de foto naar WebP maakte de download 2,5 seconden korter, waarvan 1,9 seconde doorschoof naar element render delay, omdat een entrance animation de foto tegenhield tot de fade klaar was. In LCP-breakdown staat elke stap.

Hoe ontdek je wat je LCP traag maakt?

Begin met field data op mobiel: welke pagina's zakken voor LCP bij echte bezoekers (Search Console groepeert ze), en welk van de vier onderdelen is daar het grootst (CoreDash toont beide). Kijk ook naar de trend: een plotselinge sprong wijst naar een release, een geleidelijke stijging naar third-party scripts die zich opstapelen. Test daarna een van die pagina's:

1. PageSpeed Insights, tabblad mobiel: de snelste LCP-test, met de field-LCP en een Lighthouse-run.
2. Chrome DevTools: neem een trace op in het Performance-paneel op een gethrottelde telefoon en open LCP breakdown in de Insights-zijbalk. LCP diagnosticeren met Chrome DevTools loopt door de trace.

Het Performance-paneel vóór de opname: de lokale LCP, de field-p75 en het LCP-element.

Dit snippet logt elke LCP-kandidaat met tijd en element; de laatste is de LCP. Wil je meer dan een snelle check, gebruik dan de web-vitals library.

new PerformanceObserver((list) => {
  const lcpEntry = list.getEntries().at(-1);
  console.log('LCP value: ', lcpEntry.startTime);
  console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
}).observe({ type: 'largest-contentful-paint', buffered: true });

Lighthouse laadt je pagina één keer, op een gesimuleerde telefoon, terwijl Google rankt op het 75e percentiel van 28 dagen aan echte bezoeken. Dit patroon zie ik bij bijna elke audit: de machine van de developer slaagt, de CrUX-p75 zakt. In PageSpeed Insights komen de rijen van de LCP-breakdown uit een snelle testload, waardoor ze niet optellen tot de getoonde LCP. Lab data en field data legt uit welk getal waarvoor dient.

Hoe optimaliseer je een trage LCP?

Pak het grootste van de vier onderdelen als eerste aan. Op de meeste sites is dat time to first byte, dus begin met een page cache. Daarna volgt een LCP-afbeelding die de browser te laat ontdekt; een kleiner afbeeldingsbestand helpt meestal het minst.

Een trage server (time to first byte)

Zet een page cache aan in je cache-plugin of bij je host, zodat de server een opgeslagen kopie van de pagina stuurt. Ingelogde gebruikers, een winkelmand-cookie en een onbekende query string omzeilen die kopie vaak, en elke redirect voegt een extra round-trip toe. Ben je developer: cache de HTML dan ook op het CDN. Elk onderdeel van de servertijd vind je in de handleiding over Time to first byte.

Een afbeelding die de browser te laat vindt (resource load delay)

Een <img> in de HTML wordt al opgevraagd terwijl de HTML nog binnenkomt. Een foto als achtergrond van een sectie, in een slider-script of met loading="lazy" wacht op de stylesheet, het script of de layout. Zet lazy loading uit voor de eerste afbeelding, gebruik een image-element in plaats van een achtergrond en maak van de eerste slide een gewone afbeelding.

<img src="/img/hero.webp" alt="..." width="1200" height="600" fetchpriority="high">

Op een testpagina voor een hotel stond dezelfde foto na 2,02 seconden op het scherm als <img> met fetchpriority="high", en pas na 3,64 seconden met loading="lazy". In een test van Google Flights bracht fetchpriority="high" de LCP van 2,6 naar 1,9 seconden (web.dev). Zelf heb ik er tot 30% snellere LCP mee gemeten. De fix werkt niet als een lazy-load-plugin de URL verplaatst naar data-src, of wanneer een logo op dubbel formaat de fetchpriority="high" inpikt die WordPress aan de eerste grote afbeelding geeft. Een preload voor een foto die niet in de HTML kan staan, heeft ook fetchpriority="high" nodig. In LCP request discovery staan de stappen per platform.

Een zwaar afbeeldingsbestand (resource load duration)

Stuur het formaat dat het scherm nodig heeft, in WebP of AVIF; een afbeelding-plugin zoals Imagify of ShortPixel zet dit om. Een sectie-achtergrond of een slider stuurt één bestand naar elk scherm, terwijl een <img> met een srcset de telefoon een kleiner bestand laat kiezen:

<img src="hero-828.webp"
     srcset="hero-480.webp 480w, hero-828.webp 828w, hero-1200.webp 1200w"
     sizes="100vw" width="1200" height="800" fetchpriority="high" alt="...">

Een LCP-afbeelding op een ander domein moet wachten op een eigen verbinding: verplaats hem naar je eigen domein, en voeg alleen een preconnect toe als dat echt niet anders kan. In De LCP-afbeelding optimaliseren staan de formaten en afmetingen.

Een afbeelding die wacht om getoond te worden (element render delay)

De LCP-afbeelding is gedownload, maar de pagina houdt hem nog tegen: door een entrance animation, een slider die slides verbergt tot het script draait, scripts die worden uitgesteld tot de eerste tik, of het anti-flicker-snippet van een A/B-test. Zet de entrance animation van de eerste sectie uit en toon de eerste slide direct in de HTML. Moet de foto infaden, begin in de stylesheet dan vanaf bijna zichtbaar:

.hero {
  animation: fadeIn 1s both;
}
@keyframes fadeIn {
  from { opacity: 0.01; }
  to { opacity: 1; }
}

Gebruik je Motion (Framer Motion) in React, geef het LCP-element dan initial={false}. In een trace is de long task tussen de download en de paint veel vaker een tag manager of een consent-script dan je eigen code.

De foto wacht ook op elk render-blocking request. Houd elke render-blocking stylesheet onder ongeveer 15 kB gecomprimeerd, voeg de kleintjes samen en schrap @import. Critical CSS, het standaardadvies hier, rendert de pagina met een deel van de CSS en restylet zodra de rest binnenkomt, en inline CSS wordt bij elke pageview opnieuw gedownload. Een tekst-LCP met een webfont kan wachten op het font (Font display). De instellingen per pagebuilder vind je in LCP breakdown.

WordPress

• Page cache: WP Rocket, LiteSpeed Cache of je host. Test de pagina uitgelogd.
• De eerste afbeelding: Optimize Critical Images van WP Rocket, Exclude Leading Images van Perfmatters of Viewport Images van LiteSpeed Cache houden hem buiten lazy loading. Gebruik in Elementor een Image-widget in plaats van een Container-achtergrond. De plugin van deze site, WP Core Web Vitals, leert de LCP-afbeelding per schermgrootte van je bezoekers en laadt deze als eerste, met hoge prioriteit.
• Render delay: zet in Elementor bij de eerste sectie Advanced > Motion Effects > Entrance Animation op None. WP Rocket, Perfmatters en LiteSpeed Cache kunnen scripts vasthouden tot de eerste tik of scroll; is het script dat je foto toont er daar een van, dan wacht de foto op die tik. Sluit de scripts van de pagebuilder uit van de vertraging. Laat critical CSS en Remove Unused CSS uitstaan: ze geven meer gedoe dan ze opleveren.

Shopify

De server, de caching en de afbeeldingsformaten regelt Shopify; de redirects en het theme zijn aan jou. Dawn, Horizon en daarop gebaseerde themes geven de afbeelding in de eerste sectie fetchpriority="high": maak van de banner de eerste sectie. Onder Theme settings > Animations start Dawn's "Reveal sections on scroll" de fade vanaf bijna zichtbaar; gebruik je een ander theme, zet dit dan uit en vergelijk de element render delay. Een hero die een app met JavaScript opbouwt start altijd laat, wat het theme ook doet: gebruik een theme-sectie.

Heeft je LCP-fix echte bezoekers bereikt?

CoreDash toont een fix dag voor dag in de data van je echte bezoekers: filter op mobiel op de pagina's die je hebt aangepast. Search Console kijkt naar de afgelopen 28 dagen, dus twee weken nadat een fix live gaat is de helft van wat je ziet nog steeds de oude site; het duurt tot 28 dagen voor alles groen kleurt.

Draai Lighthouse opnieuw en vergelijk alle vier de onderdelen met de meting van vóór de fix: ging het ene omlaag en het andere met ongeveer evenveel omhoog, dan wacht de afbeelding nu op iets anders.

Sommige LCP-problemen vragen om meer dan een instelling: een server of theme die je niet kunt aanpassen, of wachttijd die na elke fix doorschuift naar het volgende onderdeel. In een Core Web Vitals power hour bekijken we samen je field data en een trace van je traagste template, en bepalen we welk onderdeel je als eerste aanpakt en hoe je dat doet op jouw platform.