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

Wat is de Largest Contentful Paint (LCP)?

De Largest Contentful Paint is een meting van de rendertijd van het grootste contentelement (van het type afbeelding, video of tekst) dat is weergegeven op het zichtbare deel van het scherm. De LCP-timing geeft de tijd in milliseconden aan tussen het opvragen van de pagina en wanneer dat grootste contentvolle element wordt weergegeven op het zichtbare deel van de webpagina (above the fold).

Geschiedenis van de Largest Contentful Paint

Als je erover nadenkt, lijkt de LCP misschien een triviale metric om het laad-gedeelte van de Core Web Vitals te vertegenwoordigen. Waarom niet de laadsnelheid meten als 'de tijd die nodig is om de pagina te laden'?

Dat komt omdat het moeilijk (of zelfs onmogelijk) is bij de meeste moderne websites om te definiëren wanneer de pagina is geladen. Steeds meer websites gebruiken technieken zoals lazy loading of progressief laden, waarbij de pagina in feite eindeloos kan blijven laden. Dat betekent dat paginasnelheid niet gemeten kan worden door een enkel moment in de tijd.

Er zijn meerdere momenten bij het laden van een pagina die ertoe kunnen leiden dat een gebruiker de pagina als snel of traag ervaart. Bijvoorbeeld de serververtraging (Time to First Byte), het eerste moment dat content zichtbaar is (First Contentful Paint), het moment dat de zichtbare viewport compleet lijkt (Largest Contentful Paint) en wanneer de pagina interactief wordt (wanneer klikken op een link mogelijk wordt) zijn allemaal momenten tijdens het laadproces waarbij de site traag of snel kan lijken!

De Largest Contentful Paint (LCP) is gekozen omdat het zich richt op de user experience van een bezoeker. Wanneer de LCP plaatsvindt, kun je aannemen dat een bezoeker denkt dat de pagina klaar is met laden (zelfs als achter-de-schermen-processen nog steeds draaien). De LCP is gemaakt om de vraag te beantwoorden: 'Wanneer is de content van een pagina zichtbaar?'. Dit is waarom LCP wordt erkend als een kernindicator van gebruikersgerichte prestaties.

LCP vs FCP: wat is het verschil?

Largest Contentful Paint (LCP) en First Contentful Paint (FCP) meten beide laadprestaties, maar ze vangen fundamenteel verschillende momenten in de paginaladtijdlijn op. FCP wordt geactiveerd zodra de browser de eerste pixel van content schildert, wat een klein navigatiemenu of een laadspinner kan zijn. LCP wordt geactiveerd wanneer het grootste betekenisvolle element in de viewport wordt weergegeven.

Denk er zo over: FCP vertelt je dat de pagina is begonnen met laden; LCP vertelt je dat de pagina geladen aanvoelt. Google koos LCP als de Core Web Vital omdat het nauwkeuriger weergeeft wat gebruikers waarnemen als "snelheid."

Voor de meeste websites moet het optimaliseren van LCP de prioriteit zijn. Als je LCP snel is, zal je FCP bijna altijd ook snel zijn, omdat FCP eerder in de ladtijdlijn plaatsvindt. Het omgekeerde is niet waar: een snelle FCP garandeert geen snelle LCP.

Waarom LCP belangrijk is voor je bedrijf

De Largest Contentful Paint is een van de 3 Core Web Vitals. Als Core Web Vital is de Largest Contentful Paint belangrijk voor SEO, maar belangrijker nog, LCP is cruciaal voor UX. Bezoekers vinden het niet fijn om te moeten wachten, en met steeds meer mobiel verkeer (dat doorgaans trager is dan desktopverkeer) is het optimaliseren van de Largest Contentful Paint zeer zinvol.

• Voor SEO. Ja, Google richt zich op het tonen van de beste pagina's in de zoekresultaten. LCP maakt deel uit van Google's Core Web Vitals. Google stelt duidelijk dat sitesnelheid een factor is in zoekresultaten.
• Voor bezoekers: Volgens recent onderzoek van Google zelf verdubbelt de kans dat een gebruiker de site verlaat bij een laadtijd van 3 seconden. Dat herken je waarschijnlijk zelf ook. Tijdens het surfen op internet lijkt bijna niets zo irritant als een traag ladende website. De kans is groot dat je snel een traag ladende pagina verlaat.
• Andere redenen: Page Speed is een factor in je Google Ad Score. Dit betekent dat je je advertenties goedkoper kunt inkopen. Daarnaast is het halen van de Core Web Vitals een van de voorwaarden voor Google's top Story-box.

Een snelle LCP geeft de bezoeker het idee dat de pagina snel laadt. Daardoor is de kans kleiner dat een bezoeker van de pagina weg navigeert.

Casestudy: Vodafone (31% LCP-verbetering, 8% meer verkoop)

Vodafone Italy voerde een gecontroleerd experiment uit om hun LCP-score te optimaliseren. Door de LCP met 31% te verlagen, maten ze een toename van 8% in de verkoop. Dit is geen correlatie; het is een directe A/B-test die bewijst dat sneller waargenomen laden leidt tot meer omzet. De optimalisatie richtte zich op het preloaden van de LCP-afbeelding en het verminderen van render-blokkerende bronnen. Lees de volledige Vodafone-casestudy op web.dev.

Casestudy: Google Flights (fetchpriority bespaarde 700ms)

Het Google Flights-team voegde fetchpriority="high" toe aan hun hero-afbeelding en zag de LCP verbeteren met 700 milliseconden. Deze enkele HTML-attribuutwijziging was de meest impactvolle optimalisatie in hun prestatie-sprint. Het fetchpriority-attribuut vertelt de browser om de download van de LCP-afbeelding te prioriteren boven andere bronnen, en zoals het Google Flights-experiment aantoont, kan de impact dramatisch zijn. Meer informatie over bronprioritering voor Core Web Vitals.

Welke elementen worden beschouwd als LCP-elementen?

Niet alle elementen worden beschouwd als een LCP-element. Het grootste contentvolle element moet geschilderd zijn op het zichtbare deel van het scherm (de viewport) voordat de gebruiker met de pagina heeft geïnteracteerd.

Het element moet zijn:

• Een <img>-element.
• Een <image>-element genest in een <svg>-element.
• Een <video>-element (de posterafbeelding of het eerste videoframe, wat het eerst komt, wordt gebruikt).
• Een element met een achtergrondafbeelding geladen via de CSS url()-functie. (Let op: dit is een anti-pattern voor LCP-optimalisatie omdat het de afbeelding onvindbaar maakt voor de preload-scanner van de browser. Lees onze gids over het uitstellen van achtergrondafbeeldingen).

• Een blok-level element dat tekstknooppunten of andere inline tekstelementen bevat (in het geval van inline tekstelementen zoals <span> wordt het dichtstbijzijnde blok-level element <div> of <p> beschouwd).

Momenteel worden bepaalde elementen uitgesloten als LCP-kandidaten, zoals elementen verborgen met opacity: 0, afbeeldingen die 100% van de viewport beslaan (omslagafbeeldingen) en placeholders (low-entropy afbeeldingen). Houd er rekening mee dat dit kan veranderen naarmate de specificatie evolueert!

Technisch: LCP-elementgrootte meten

LCP identificeert het grootste zichtbare contentelement in de viewport en berekent de grootte op basis van een set precieze regels. Deze regels zorgen voor consistentie en nauwkeurigheid, zelfs in complexe layouts.

• Alleen viewport: Alleen het zichtbare deel van de pagina wordt meegenomen. Als een element slechts gedeeltelijk in de zichtbare viewport staat, wordt de beschouwde grootte bijgesneden.
• Geen border, padding of margin: Voor alle elementen worden tekst- en afbeeldingsborders, padding en margins volledig genegeerd.
• Tekstgrootte: Tekstelementen worden gerapporteerd als de kleinste rechthoek die rond de tekstknooppunt(en) kan worden geschilderd.
• Afbeeldingsgrootte: Voor afbeeldingen wordt de kleinste van de intrinsieke afmetingen (de oorspronkelijke breedte en hoogte) en de weergavegrootte (de grootte op het scherm) gebruikt om de LCP-elementgrootte te berekenen.
• Eerste grootte telt: Wanneer layout verandert of wanneer een elementgrootte verandert, wordt alleen de eerste grootte meegenomen voor de LCP.
• Verwijderde elementen worden meegenomen: Wanneer een element uit de DOM wordt verwijderd, is het nog steeds een LCP-kandidaat.

Dynamische aard van LCP

Largest Contentful Paint (LCP) is een dynamische metric. Hoewel rendering complex kan zijn en in fasen kan plaatsvinden, is het normaal dat het LCP-element verandert tijdens het laden van de pagina. Vóór de eerste gebruikersinteractie identificeert de performance observer van de browser alle elementen die als LCP-kandidaten kunnen worden beschouwd. Als een nieuw element wordt gerenderd dat zowel zichtbaar is in de viewport als groter is dan het eerder geïdentificeerde LCP-element, wordt het het nieuwe LCP.

Inzichten uit LCP-velddata: Bij CoreDash tracken we miljoenen LCP-vermeldingen per dag. Het blijkt dat voor mobiele paginaweergaven het LCP-element vaak een tekstgebaseerd element is, ofwel een paragraaf ofwel een koptekst. Gemiddeld (of om precies te zijn op het 75e percentiel) worden de Core Web Vitals gehaald wanneer het LCP-element een tekstknooppunt of zelfs een normale afbeelding is. Wanneer het LCP-element een achtergrondafbeelding, video of een lazy-loaded afbeelding is, hebben de Core Web Vitals de neiging om te falen.

Wat is een goede LCP-score?

Om de Core Web Vitals te halen voor de Largest Contentful Paint moet minimaal 75% van je bezoekers een 'goede' LCP-score hebben. Een LCP-score tussen 0 en 2,5 seconden wordt beschouwd als een goede LCP-score, een LCP-score tussen 2,5 en 4 seconden moet verbeterd worden en een LCP-score boven de 4 seconden wordt beschouwd als slecht.

Wat real-world LCP-data laat zien

CoreDash volgt dagelijks miljoenen echte gebruikers-LCP-metingen. Dit is wat de data onthult over LCP-prestaties op het web.

Afbeelding-LCP vs tekst-LCP

Pagina's met afbeeldingsgebaseerde LCP-elementen hebben een 75e percentiel LCP van 744ms, bijna twee keer zo traag als tekstgebaseerde LCP-elementen met 388ms. Dit bevestigt dat beeldoptimalisatie het meest impactvolle gebied is voor het verbeteren van LCP-scores. Als je LCP-element een afbeelding is, moet je bijzonder agressief zijn met optimalisatie.

De impact van preloading en lazy loading

Voorgeladen LCP-afbeeldingen behalen 100% "goede" scores met een 75e percentiel van 364ms. Daarentegen behoren lazy-loaded LCP-afbeeldingen tot de traagste met 720ms, waarbij 4,3% van de paginaweergaven als "slecht" wordt beoordeeld. Niet-voorgeladen afbeeldingen presteren bijna net zo slecht met 752ms. De conclusie is duidelijk: preload je LCP-afbeelding en lazy-load deze nooit.

Mobiel vs desktop LCP

Mobiele LCP (764ms op het 75e percentiel) is 2x trager dan desktop-LCP (380ms). Dit verschil wordt veroorzaakt door tragere mobiele netwerken en minder krachtige mobiele processors. Aangezien Google mobile-first indexering gebruikt, moet het optimaliseren voor mobiele LCP de prioriteit zijn.

Wereldwijde LCP-statistieken

Volgens de HTTP Archive Web Almanac 2025 behaalt 62% van de mobiele pagina's wereldwijd een goede LCP-score (onder 2,5 seconden), een stijging ten opzichte van 44% in 2022. LCP blijft de moeilijkste Core Web Vital om te halen en is de voornaamste bottleneck voor de totale CWV-scores. Daarnaast is 73% van de mobiele LCP-elementen afbeeldingen, en lazy-loadt 16% van de mobiele sites per ongeluk hun LCP-afbeelding.

Hoe LCP wordt gemeten: de vier belangrijkste fasen

Volgens Google kan de Largest Contentful Paint worden opgesplitst in 4 onderdelen. Begrijpen welke fase de bottleneck veroorzaakt is essentieel voor efficiënte optimalisatie, omdat elke fase een compleet andere oplossing vereist. Een trage Time to First Byte (TTFB) vereist server-side werk, terwijl een trage resource load delay wijzigingen in je HTML vereist.

De uiteindelijke LCP-tijd van een pagina is geen enkele, monolithische waarde. Het is de som van vier afzonderlijke onderdelen. Het begrijpen van deze opsplitsing is de sleutel tot het efficiënt diagnosticeren en oplossen van LCP-problemen.

Hier is een opsplitsing van de vier fasen:

• Time to First Byte (TTFB): Dit is pure serverresponstijd. Het omvat alles van de DNS-lookup, via de TCP/TLS-verbinding, tot het moment dat de browser de eerste byte van het HTML-document ontvangt. Een trage TTFB is een fundamenteel probleem dat altijd je LCP zal doden. Op het hele web besteden sites met slechte LCP gemiddeld 2,27 seconden alleen al aan TTFB, wat bijna de gehele drempelwaarde van 2,5 seconden is. TTFB optimaliseren omvat server-side caching, CDN-configuratie en efficiënte backend-code.
• Resource Load Delay: Dit is het "ontdekkingsgat." Het meet de tijd tussen het voltooien van TTFB en het moment dat de browser daadwerkelijk begint met het downloaden van de LCP-bron. Een lange vertraging hier betekent dat de browser de LCP-bron laat heeft gevonden. Dit is het klassieke symptoom van het gebruik van CSS-achtergrondafbeeldingen (die de preload-scanner niet kan ontdekken) of client-side rendering (waarbij het LCP-element pas verschijnt nadat JavaScript wordt uitgevoerd). De oplossing is ervoor te zorgen dat je LCP-element in de initiële HTML staat en om de LCP-afbeelding te preloaden als de browser deze niet vroeg genoeg kan ontdekken.
• Resource Load Duration: Dit is hoe lang het duurt om het LCP-bronbestand (de afbeelding, het lettertype of de video) daadwerkelijk te downloaden. Deze fase draait helemaal om bestandsgrootte en netwerkomstandigheden. Optimaliseren betekent het gebruik van moderne afbeeldingsformaten zoals AVIF of WebP, het implementeren van responsive afbeeldingen met srcset, en het serveren van assets via een CDN met goede compressie.
• Element Render Delay: Dit is de laatste vertraging. Het meet de tijd tussen wanneer de LCP-bron klaar is met downloaden en wanneer het element volledig op het scherm is gerenderd. Deze vertraging wordt bijna altijd veroorzaakt doordat de main thread van de browser geblokkeerd wordt door andere taken, vooral JavaScript-verwerking. Render-blokkerende CSS en synchrone scripts zijn de meest voorkomende oorzaken.

Elk van deze focusgebieden kan worden geoptimaliseerd om de Largest Contentful Paint te verbeteren. Om de stappen te begrijpen die je moet nemen, lees Fix &amp; Identify Largest Contentful Paint (LCP) issues.

Veelgemaakte LCP-fouten

Na het analyseren van miljoenen paginaweergaven via CoreDash komen drie LCP-fouten veel vaker voor dan alle andere. Het vermijden hiervan brengt de meeste sites naar een voldoende LCP-score.

Fout 1: de LCP-afbeelding lazy-loaden

Het toevoegen van loading="lazy" aan je hero-afbeelding is de meest voorkomende LCP-fout. Lazy loading vertelt de browser om het downloaden van de afbeelding opzettelijk uit te stellen totdat deze in beeld scrollt. Voor je LCP-afbeelding (die al in de viewport staat) creëert dit een geheel onnodige vertraging. Volgens CrUX-data maakt 16% van de mobiele sites deze fout. CoreDash-data toont dat lazy-loaded LCP-afbeeldingen een 75e percentiel hebben van 720ms met 4,3% slechte ervaringen, vergeleken met 364ms en 0% slecht voor voorgeladen afbeeldingen. Lees onze complete gids over hoe je een lazy-loaded LCP-afbeelding repareert.

Fout 2: de LCP-afbeelding niet preloaden

Zelfs zonder lazy loading slagen veel sites er niet in om de browser vroeg genoeg over de LCP-afbeelding te vertellen. Als de afbeeldings-URL pas wordt ontdekt na het parsen van CSS of het uitvoeren van JavaScript, verspilt de browser honderden milliseconden voordat het zelfs maar begint met downloaden. De oplossing is het toevoegen van een preload-hint in de <head> van je document:

<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">

Dit vertelt de browser om onmiddellijk te beginnen met het downloaden van de afbeelding, zonder te wachten op CSS of layoutberekeningen. Combineer het met fetchpriority="high" voor maximale impact. Meer informatie in onze gids over het preloaden van de LCP-afbeelding.

Fout 3: een CSS-achtergrondafbeelding gebruiken voor LCP

CSS-achtergrondafbeeldingen geladen via background-image: url(...) zijn onzichtbaar voor de preload-scanner van de browser. De browser kan ze pas ontdekken nadat het de HTML heeft gedownload, de CSS heeft geparset en de rendertree heeft opgebouwd. Dit voegt aanzienlijke resource load delay toe. Volgens CrUX-data gebruikt 9% van de mobiele pagina's een CSS-achtergrondafbeelding als hun LCP-element. De oplossing is om in plaats daarvan een standaard <img>-tag te gebruiken, met het fetchpriority="high"-attribuut:

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

Het fetchpriority="high"-attribuut is een direct signaal aan de browser dat deze afbeelding de hoogste prioriteit heeft op de pagina. Zoals de Google Flights-casestudy aantoonde, kan dit enkele attribuut de LCP met 700ms verlagen. Voor een dieper begrip, zie onze gids over bronprioritering.

Hoe meet je de Largest Contentful Paint

De Largest Contentful Paint (LCP) kan worden gemeten met puur JavaScript, lab-data en veldtools. Beide hebben hun voor- en nadelen.

De Largest Contentful Paint meten met JavaScript

Om Largest Contentful Paint (LCP) te meten met JavaScript biedt de Performance Observer API een snelle oplossing. Het volgende codefragment demonstreert hoe je de LCP-timing en elementinformatie vastlegt:

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 });

Dit fragment volgt de LCP-vermelding terwijl deze wordt gerapporteerd en toont de tijdstempel en elementdetails in de console. Voor uitgebreidere inzichten kun je de Web Vitals Library overwegen.

Largest Contentful Paint (LCP) meten in Chrome DevTools

1. Open Chrome DevTools door op Ctrl+Shift+I (of Cmd+Option+I op Mac) te drukken.
2. Navigeer naar het Performance-tabblad.
3. Herlaad de pagina om de Core Web Vitals te bekijken.

Het Performance-tabblad van DevTools toont nu informatie over Core Web Vitals, inclusief de timing en het element van de Largest Contentful Paint.

De Largest Contentful Paint meten met lab- en veldtools

Laten we duidelijk zijn: lab- en velddata dienen twee verschillende doelen. Je hebt beide nodig.

• Velddata (RUM en CrUX) is de enige data die er echt toe doet voor het halen van de Core Web Vitals. Het is wat je echte gebruikers ervaren. Google gebruikt deze data uit zijn CrUX-dataset. Je begint hier om te ontdekken of je een probleem hebt.
• Lab-data (Lighthouse, etc.) is een gecontroleerde test. Het is niet wat Google gebruikt voor ranking, maar het is essentieel voor het debuggen. Je gebruikt dit om erachter te komen waarom je een probleem hebt.

Hier is een beknopte gids met de essentiële tools:

De Largest Contentful Paint verbeteren

Het optimaliseren van LCP vereist een systematische aanpak die de vier fasen adresseert. Alles wat vóór het schilderen van het LCP-element gebeurt, of het nu netwerkgerelateerd of CPU-intensief is, kan de LCP-score beïnvloeden. Jaag niet op één enkele oplossing; begrijp de hele keten. Hier is de strategie op hoog niveau:

• Optimaliseer TTFB: Je server moet snel zijn. Als je TTFB traag is, doet niets anders ertoe. Dit omvat server-side caching, het gebruik van een CDN en efficiënte backend-code. Lees meer in onze gids voor het optimaliseren van TTFB.
• Elimineer Resource Load Delay: Zorg ervoor dat het LCP-element in de initiële HTML staat zodat de preload-scanner van de browser het onmiddellijk kan vinden. Vermijd CSS-achtergrondafbeeldingen voor LCP. Preload kritieke afbeeldingen die laat worden ontdekt. Lees hoe in onze gids over het oplossen van Resource Load Delay.
• Verminder Resource Load Time: Maak het LCP-bestand kleiner. Dit betekent het gebruik van moderne afbeeldingsformaten zoals AVIF, responsive afbeeldingen en goede compressie. Zie onze complete gids over hoe je de LCP-afbeelding optimaliseert. Je kunt ook lezen over hoe we de LCP met 70% hebben verlaagd in een echt project.
• Verkort Element Render Delay: Stop met het blokkeren van de main thread. Stel niet-kritiek JavaScript uit, breek lange taken op en minimaliseer render-blokkerende CSS. Dit wordt behandeld in onze gids over het oplossen van Element Render Delay.

Gerelateerde gidsen

Deze hubpagina behandelt de Largest Contentful Paint op hoog niveau. Voor gedetailleerde, praktische begeleiding bij elk aspect van LCP-optimalisatie, bekijk deze specifieke gidsen:

• Fix &amp; Identify LCP Issues: Een stap-voor-stap diagnostische gids om precies te vinden wat je trage LCP veroorzaakt, met Chrome DevTools, WebPageTest en CoreDash.
• Optimize the LCP Image: Alles over afbeeldingsformaten, responsive afbeeldingen, compressie en het serveren van de optimale afbeelding voor elk apparaat.
• Resource Load Delay: Hoe je ervoor zorgt dat de browser je LCP-bron zo vroeg mogelijk ontdekt, inclusief preloading, fetchpriority en het vermijden van CSS-achtergrondafbeeldingen.
• Resource Load Duration: Het verminderen van de daadwerkelijke downloadtijd van de LCP-bron door bestandsgrootteoptimalisatie, CDN-configuratie en moderne compressie.
• Element Render Delay: Het elimineren van de vertraging tussen het downloaden van de bron en het renderen op het scherm door het verminderen van main thread-blokkering door JavaScript en CSS.