Largest Contentful Paint (LCP): Wat het is, hoe te meten & optimaliseren

Wat is de Largest Contentful Paint (LCP)?

De Largest Contentful Paint is een meting van de rendertijd van het grootste content-element (van het type afbeelding, video of tekst) dat op het zichtbare deel van het scherm is getekend. De LCP-timing geeft de tijd in milliseconden aan tussen het opvragen van de pagina en het moment dat dat grootste content-element wordt weergegeven op het zichtbare deel van de webpagina (boven de vouw).

Geschiedenis van de Largest Contentful Paint

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

Dat komt omdat het bij de meeste moderne websites moeilijk (of zelfs onmogelijk) is om te definiëren wanneer de pagina is geladen. Steeds meer websites gebruiken technieken zoals lazy loading of progressive loading, waarbij de pagina in feite voor altijd kan blijven laden. Dat betekent dat paginasnelheid niet kan worden gemeten op één enkel tijdstip.

Er zijn verschillende momenten tijdens het laden van de pagina die ervoor kunnen zorgen dat een gebruiker de pagina als snel of langzaam ervaart. Bijvoorbeeld de serververtraging (Time to First Byte), de eerste keer dat content zichtbaar is (First Contentful Paint), de tijd dat de zichtbare viewport compleet lijkt (Largest Contentful Paint) en wanneer de pagina interactief wordt (wanneer klikken op een link mogelijk wordt) zijn allemaal punten tijdens het laadproces waarop de site langzaam of snel kan lijken!

De Largest Contentful Paint (LCP) is gekozen omdat deze zich richt op de gebruikerservaring van een bezoeker. Wanneer de LCP plaatsvindt, kunt u aannemen dat een bezoeker denkt dat de pagina klaar is met laden (zelfs als er op de achtergrond nog processen draaien). De LCP is gecreëerd om de vraag te beantwoorden: 'Wanneer is de inhoud van een pagina zichtbaar?'. Daarom wordt LCP erkend als een kernindicator voor gebruikersgerichte prestaties.

LCP vs FCP: Wat is het verschil?

Largest Contentful Paint (LCP) en First Contentful Paint (FCP) meten beide laadprestaties, maar ze leggen fundamenteel verschillende momenten in de tijdlijn van het laden van de pagina vast. FCP wordt geactiveerd zodra de browser de eerste pixel aan content tekent, wat een kleine navigatiebalk of een laad-spinner kan zijn. LCP wordt geactiveerd wanneer het grootste betekenisvolle element in de viewport wordt weergegeven.

Bekijk het zo: FCP vertelt u dat de pagina is begonnen met laden; LCP vertelt u dat de pagina geladen voelt. Google koos LCP als de Core Web Vital omdat het nauwkeuriger weergeeft wat gebruikers waarnemen als "snelheid".

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

Waarom LCP belangrijk is voor uw 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 nog belangrijker: LCP is cruciaal voor UX. Bezoekers houden er niet van om te wachten, en met steeds meer mobiel verkeer (dat vaak langzamer is dan desktopverkeer) is het optimaliseren van de Largest Contentful Paint erg zinvol.

• Voor SEO. Ja, Google richt zich op het tonen van de beste pagina's in zijn 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. U herkent dat waarschijnlijk wel bij uzelf. Tijdens het surfen op internet lijkt bijna niets zo vervelend als een traag ladende website. De kans is groot dat u een traag ladende pagina snel verlaat.
• Andere redenen: Page Speed is een factor in uw Google Ad Score. Dit betekent dat u uw advertenties goedkoper kunt inkopen. Bovendien is het slagen voor de Core Web Vitals een van de vereisten voor Google's Top Stories-box.

Een snelle LCP geeft de bezoeker het idee dat de pagina snel laadt. Hierdoor is de kans kleiner dat een bezoeker wegnavigeert van de pagina.

Case Study: Vodafone (31% LCP-verbetering, 8% meer omzet)

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

Case Study: Google Flights (fetchpriority bespaarde 700ms)

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

Welke elementen worden beschouwd als LCP-elementen?

Niet alle elementen worden beschouwd als een LCP-element. Het grootste Contentful element moet getekend zijn op het zichtbare deel van het scherm (de viewport) voordat de gebruiker interactie heeft gehad met de pagina.

Het element moet zijn:

• Een <img> element.
• Een <image> element genest in een <svg> element.
• Een <video> element (de posterafbeelding of het eerste videoframe, afhankelijk van wat eerder gebeurt, wordt gebruikt).
• Een element met een achtergrondafbeelding geladen via de CSS url() functie. (Opmerking: Dit is een anti-patroon 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 element op blokniveau dat tekstnodes of andere inline tekstelementen bevat (in het geval van inline tekstelementen zoals <span> wordt het dichtstbijzijnde element op blokniveau <div> of <p> in aanmerking genomen).

Momenteel worden bepaalde elementen uitgesloten als LCP-kandidaten, zoals elementen die verborgen zijn met opacity: 0, afbeeldingen die overeenkomen met 100% van de viewportgrootte (coverafbeeldingen) en placeholders (afbeeldingen met lage entropie). Houd er rekening mee dat dit kan veranderen naarmate de specificatie evolueert!

Technisch worden: LCP-elementgrootte meten

LCP identificeert het grootste zichtbare content-element in de viewport en berekent de grootte op basis van een reeks nauwkeurige regels. Deze regels zorgen voor consistentie en nauwkeurigheid, zelfs in complexe lay-outs.

• Alleen viewport: Alleen het zichtbare deel van de pagina wordt in aanmerking genomen. Als een element zich slechts gedeeltelijk in de zichtbare viewport bevindt, wordt de in aanmerking genomen grootte afgekapt.
• Geen rand, padding of marge: Voor alle elementen worden tekst- en afbeeldingsranden, padding en marges volledig genegeerd.
• Tekstgrootte: Tekstelementen worden gerapporteerd als de kleinste rechthoek die rond de tekstnode(s) kan worden getekend.
• 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 grootte van het LCP-element te berekenen.
• Eerste grootte telt: Wanneer de lay-out verandert of wanneer de grootte van een element verandert, wordt alleen de eerste grootte in aanmerking genomen voor de LCP.
• Verwijderde elementen worden opgenomen: 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 metriek. 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 er een nieuw element wordt gerenderd dat zowel zichtbaar is in de viewport als groter is dan het eerder geïdentificeerde LCP-element, wordt dit de nieuwe LCP.

Take-aways uit LCP-velddata: Bij CoreDash volgen we miljoenen LCP-entries per dag. Het blijkt dat voor mobiele paginaweergaven het LCP-element vaak een op tekst gebaseerd element is, een alinea of een kop. Gemiddeld (of op het 75e percentiel om precies te zijn) zullen de Core Web Vitals slagen wanneer het LCP-element een tekstnode 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 te slagen voor de Core Web Vitals voor de Largest Contentful Paint moet ten minste 75% van uw 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 heeft verbetering nodig en een LCP-score boven de 4 seconden wordt beschouwd als slecht.

Wat LCP-data uit de echte wereld laat zien

CoreDash volgt elke dag miljoenen LCP-metingen van echte gebruikers. Hier is wat de data onthult over LCP-prestaties op het web.

Afbeelding LCP vs Tekst LCP

Pagina's met op afbeeldingen gebaseerde LCP-elementen hebben een 75e percentiel LCP van 744ms, bijna twee keer zo langzaam als op tekst gebaseerde LCP-elementen met 388ms. Dit bevestigt dat beeldoptimalisatie het meest impactvolle gebied is voor het verbeteren van LCP-scores. Als uw LCP-element een afbeelding is, moet u bijzonder agressief zijn met optimalisatie.

De impact van Preloading en Lazy Loading

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

Mobiel vs Desktop LCP

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

Wereldwijde LCP-statistieken

Volgens de HTTP Archive Web Almanac 2024 behaalt 59% 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 het belangrijkste knelpunt voor algemene CWV-scores. Bovendien is 73% van de mobiele LCP-elementen afbeeldingen, en lazy-load 16% van de mobiele sites ten onrechte hun LCP-afbeelding.

Hoe LCP wordt gemeten: De vier sleutelfasen

Volgens Google kan de Largest Contentful Paint worden opgesplitst in 4 subonderdelen. Begrijpen welke fase het knelpunt veroorzaakt is essentieel voor efficiënte optimalisatie, omdat elke fase een compleet andere oplossing vereist. Een trage Time to First Byte (TTFB) vereist werk aan de serverzijde, terwijl een trage resource load delay wijzigingen aan uw HTML vereist.

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

Hier is een uitsplitsing 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 uw LCP altijd zal doden. Op het web besteden sites met slechte LCP gemiddeld 2,27 seconden aan TTFB alleen, wat bijna de volledige drempel van 2,5 seconden is. Het optimaliseren van TTFB 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 daadwerkelijk starten van de browser 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 is uitgevoerd). De oplossing is ervoor te zorgen dat uw 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 responsieve afbeeldingen met srcset en het serveren van assets via een CDN met de juiste compressie.
• Element Render Delay: Dit is de laatste vertraging. Het meet de tijd tussen het moment dat de LCP-bron klaar is met downloaden en het moment dat het element volledig op het scherm wordt weergegeven. Deze vertraging wordt bijna altijd veroorzaakt doordat de main thread van de browser wordt geblokkeerd door andere taken, met name JavaScript-verwerking. Render-blocking CSS en synchrone scripts zijn de meest voorkomende boosdoeners.

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

Veelgemaakte LCP-fouten

Na het analyseren van miljoenen paginaladingen via CoreDash, komen drie LCP-fouten veel vaker voor dan alle andere. Door deze te vermijden, krijgen de meeste sites een voldoende LCP-score.

Fout 1: De LCP-afbeelding lazy-loaden

Het toevoegen van loading="lazy" aan uw 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 scrolt. Voor uw LCP-afbeelding (die zich al in de viewport bevindt), creëert dit een volledig onnodige vertraging. Volgens CrUX-data maakt 16% van de mobiele sites deze fout. CoreDash-data laat zien dat lazy-loaded LCP-afbeeldingen een 75e percentiel van 720ms hebben met 4,3% slechte ervaringen, vergeleken met 364ms en 0% slecht voor gepreloade afbeeldingen. Lees onze volledige gids over hoe u 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 hij zelfs maar begint met downloaden. De oplossing is om een preload-hint toe te voegen in de <head> van uw 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 lay-outberekeningen. Combineer het met fetchpriority="high" voor maximale impact. Lees meer 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 hij de HTML heeft gedownload, de CSS heeft geparst en de render tree heeft gebouwd. 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 bron met de hoogste prioriteit op de pagina is. Zoals de Google Flights-casestudy aantoonde, kan dit ene attribuut de LCP met 700ms verminderen. Voor een dieper inzicht, zie onze gids over bronprioritering.

Hoe de Largest Contentful Paint te meten

De Largest Contentful Paint (LCP) kan worden gemeten met pure JavaScript, Lab-data en Veld-tools. Beide hebben hun voor- en nadelen.

Meet de Largest Contentful Paint met JavaScript

Om Largest Contentful Paint (LCP) te meten met behulp van JavaScript, biedt de Performance Observer API een snelle oplossing. Het volgende codefragment laat zien hoe u 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-entry zoals deze wordt gerapporteerd en geeft de tijdstempel en elementdetails weer in de console. Overweeg voor uitgebreidere inzichten het gebruik van de Web Vitals Library.

Meet Largest Contentful Paint (LCP) in Chrome DevTools

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

Het tabblad Prestaties van DevTools geeft nu informatie weer over Core Web Vitals, inclusief de timing en het element van de Largest Contentful Paint.

Meet de Largest Contentful Paint met Lab- en Veld-tools

Laten we duidelijk zijn: Lab- en Veld-data dienen twee verschillende doelen. U hebt beide nodig.

• Veld-data (RUM en CrUX) is de enige data die er werkelijk toe doet voor het slagen voor Core Web Vitals. Het is wat uw echte gebruikers ervaren. Google gebruikt deze data uit zijn CrUX-dataset. U begint hier om te achterhalen of u een probleem hebt.
• Lab-data (Lighthouse, enz.) is een gecontroleerde test. Het is niet wat Google gebruikt voor ranking, maar het is essentieel voor debugging. U gebruikt dit om uit te zoeken waarom u een probleem hebt.

Hier is een snelle gids voor de essentiële tools:

De Largest Contentful Paint verbeteren

Het optimaliseren van LCP vereist een systematische aanpak die de vier fasen aanpakt. Alles wat gebeurt voordat het LCP-element wordt getekend, of het nu netwerkgerelateerd of CPU-intensief is, kan de LCP-score beïnvloeden. Jaag niet slechts één oplossing na; begrijp de hele keten. Hier is de strategie op hoog niveau:

• Optimaliseer TTFB: Uw server moet snel zijn. Als uw TTFB traag is, doet al het andere er niet toe. 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 direct kan vinden. Vermijd CSS-achtergrondafbeeldingen voor LCP. Preload kritieke afbeeldingen die laat worden ontdekt. Leer 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, responsieve afbeeldingen en de juiste compressie. Zie onze volledige gids over hoe u de LCP-afbeelding optimaliseert. U kunt ook lezen over hoe we LCP met 70% hebben verlaagd bij een echt project.
• Verkort Element Render Delay: Stop met het blokkeren van de main thread. Stel niet-kritieke JavaScript uit, breek lange taken op en minimaliseer render-blocking CSS. Dit wordt behandeld in onze gids over het oplossen van Element Render Delay.

Gerelateerde Deep Dives

Deze hub-pagina behandelt de Largest Contentful Paint op hoog niveau. Voor gedetailleerde, bruikbare begeleiding bij elk aspect van LCP-optimalisatie, verken deze speciale gidsen:

• Fix &amp; Identify LCP Issues: Een stapsgewijze diagnostische gids om precies te vinden wat uw trage LCP veroorzaakt, met behulp van Chrome DevTools, WebPageTest en CoreDash.
• Optimaliseer de LCP-afbeelding: Alles over afbeeldingsformaten, responsieve afbeeldingen, compressie en het serveren van de optimale afbeelding voor elk apparaat.
• Resource Load Delay: Hoe ervoor te zorgen dat de browser uw 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 bestandsgrootte-optimalisatie, CDN-configuratie en moderne compressie.
• Element Render Delay: Het elimineren van de vertraging tussen het downloaden van de bron en de weergave op het scherm door het verminderen van de blokkering van de main thread door JavaScript en CSS.