LCP (Largest Contentful Paint)

LCP (Largest Contentful Paint) is een [Core Web Vitals](/glossary/core-web-vitals)-metriek die de tijd meet vanaf het begin van het laden van een pagina tot het moment dat het grootste zichtbare inhoudselement in de [viewport](/glossary/viewport) volledig is gerenderd. Dit element is doorgaans een hero-afbeelding, een groot tekstblok, een videoposter of een achtergrondafbeelding. Google definieert drie prestatiebanden: **goed** (2,5 seconden of minder), **verbetering nodig** (2,5 tot 4,0 seconden) en **slecht** (meer dan 4,0 seconden). LCP wordt gemeten op het 75e percentiel van paginabeladingen, wat betekent dat de score de ervaring van de meeste echte gebruikers weerspiegelt, niet alleen van de snelste verbindingen.

LCP is de belangrijkste indicator van waargenomen laadsnelheid. Terwijl andere metrieken technische gereedheid of visuele stabiliteit meten, legt LCP het moment vast waarop een bezoeker de hoofdinhoud ziet — het moment waarop hij besluit dat de pagina "geladen" is. Een trage LCP laat bezoekers naar een onvolledige pagina staren, wat het bouncepercentage verhoogt en de betrokkenheid verlaagt. Google gebruikt LCP als rangsignaal in zijn zoekalgoritme, wat betekent dat een slechte score niet alleen de gebruikerservaring schaadt — het vermindert direct de organische zichtbaarheid. Voor uitgevers die afhankelijk zijn van zoekverkeer kan het optimaliseren van LCP het verschil maken tussen een plek op pagina één en begraven worden in de resultaten.

FlipLink optimaliseert LCP voor zowel de marketingsite als gepubliceerde flipbooks. De [flipbook](/glossary/flipbook)-viewer geeft prioriteit aan het renderen van de omslag en de eerste spread, zodat het grootste zichtbare inhoudselement verschijnt voordat zwaardere assets worden geladen. Het [aangepaste laadscherm](/features/custom-loading-screen) biedt onmiddellijke visuele feedback — een merkgebonden placeholder die in minder dan één seconde verschijnt — terwijl [Three.js](/glossary/three-js)-renderresources op de achtergrond worden geïnitialiseerd. FlipLink's [pagina-ervaring en layout](/features/page-experience-and-layout)-engine past geoptimaliseerde beeldcompressie, responsieve beeldgroottes en progressieve rendering toe om LCP binnen de door Google aanbevolen drempel van 2,5 seconden te houden op zowel desktop als mobiel. Wanneer flipbooks op externe sites worden [ingesloten](/glossary/embed), zorgt [lazy loading](/glossary/lazy-loading) ervoor dat de insluiting niet concurreert met het LCP-element van de hostpagina.

Het begrijpen van LCP vereist context naast gerelateerde prestatiemetrieken: - **Goede LCP**: 2,5 seconden of minder. De pagina voelt direct aan. De meeste gebruikers zien de inhoud voordat ze overwegen te vertrekken. - **Verbetering nodig**: 2,5 tot 4,0 seconden. Gebruikers merken een vertraging op. Bouncepercentages beginnen te stijgen. - **Slechte LCP**: meer dan 4,0 seconden. Bezoekers zullen waarschijnlijk de pagina verlaten voordat de hoofdinhoud verschijnt. Het LCP-element verandert afhankelijk van de pagina. Op een productpagina is het meestal de productafbeelding. Op een blogpost kan het de hero-banner of de eerste alinea tekst zijn. Op een flipbook-pagina is het de omslagafbeelding. Het identificeren van welk element de LCP vormt op elke pagina is de eerste stap naar optimalisatie.

De LCP-meting volgt specifieke regels die zijn gedefinieerd door de Web Performance Working Group. Het grootste element wordt bepaald door zijn zichtbare grootte in de viewport, niet door de bestandsgrootte. Elementen die voor LCP in aanmerking komen zijn `<img>`-elementen, `<image>` binnen SVG, videoposter-afbeeldingen, elementen met via CSS geladen `background-image` en block-level elementen met tekst. Elementen die zich buiten de viewport uitstrekken worden alleen gemeten voor hun zichtbare gedeelte. Veelvoorkomende oorzaken van trage LCP zijn niet-geoptimaliseerde afbeeldingen (een foto van 4MB serveren terwijl een WebP van 200KB zou volstaan), render-blokkerende CSS en JavaScript, trage serverresponstijden ([TTFB](/glossary/core-web-vitals) boven 800ms) en client-side rendering die JavaScript-uitvoering vereist voordat er inhoud verschijnt. Praktische optimalisaties zijn onder meer: het preloaden van de LCP-afbeelding met `<link rel="preload">`, afbeeldingen in moderne formaten serveren (WebP, AVIF), een CDN gebruiken voor statische assets, kritische CSS inline plaatsen, niet-essentieel JavaScript uitstellen en expliciete `width` en `height` op afbeeldingen instellen om layout shifts te voorkomen die LCP kunnen vertragen.

LCP en [FCP](/glossary/core-web-vitals) (First Contentful Paint) zijn beide timingmetrieken, maar ze meten verschillende momenten. FCP wordt geactiveerd wanneer de browser het eerste stuk DOM-inhoud rendert — zelfs als het slechts een navigatiebalk, een laadspinner of een enkele regel tekst is. LCP wordt geactiveerd wanneer het grootste inhoudselement wordt gerenderd. In de praktijk wordt FCP vaak één tot twee seconden vóór LCP geactiveerd. Een pagina kan een snelle FCP maar een trage LCP hebben als de header en navigatie snel laden terwijl de hero-afbeelding meerdere seconden nodig heeft om te verschijnen. Voor de gebruikerservaring is LCP de meer betekenisvolle metriek omdat deze weerspiegelt wanneer de pagina compleet aanvoelt voor de bezoeker. FCP is nuttig om te diagnosticeren of de browser überhaupt is begonnen met renderen, maar LCP bepaalt of de gebruiker blijft of vertrekt.

LCP meet het moment waarop je pagina aanvoelt als geladen voor echte bezoekers. Houd het onder 2,5 seconden door afbeeldingen te optimaliseren, render-blokkerende resources te minimaliseren en above-the-fold content te prioriteren — je zoekrankings en gebruikersbetrokkenheid hangen ervan af.