Waarom LCP de Core Web Vital Is Die Je Website Maakt of Breekt
Largest Contentful Paint — kortweg LCP — meet hoe lang het duurt voordat het grootste zichtbare element in de viewport volledig is gerenderd. Denk aan je hero-afbeelding, een groot tekstblok of een prominente video-thumbnail. Het is eigenlijk de metric die het dichtst aansluit bij wat een gebruiker voelt als laadsnelheid: dat moment waarop de pagina er bruikbaar uitziet.
En de cijfers liegen er niet om. Volgens de meest recente CrUX-data (Chrome User Experience Report, december 2025) haalt slechts 67,6% van alle websites de drempelwaarde van 2,5 seconden voor een goede LCP-score. Bijna één op de drie websites heeft dus een trage LCP — en Google weegt dat keihard mee in de zoekresultaten. LCP telt voor ongeveer 25% van je totale Lighthouse Performance Score, dus dat is niet iets om te negeren.
In een eerder artikel doken we diep in INP-optimalisatie. Maar terwijl INP meet hoe responsief je pagina reageert op interacties, meet LCP hoe snel je pagina er klaar voor is. Samen vormen ze het fundament van een goede gebruikerservaring. Eerlijk gezegd: als je LCP slecht is, maakt een perfecte INP weinig uit — gebruikers zijn al weg voordat ze iets kunnen aanklikken.
Het goede nieuws? Google heeft LCP opgesplitst in vier meetbare deelfasen. Elke fase heeft z'n eigen oorzaak en z'n eigen oplossing. In dit artikel nemen we elke fase systematisch door, met werkende codevoorbeelden, moderne browser-API's en concrete optimalisatietechnieken die je vandaag nog kunt toepassen.
Wat Is LCP Precies en Welke Elementen Tellen Mee?
LCP rapporteert de rendertijd van het grootste content-element dat zichtbaar is in de viewport, gemeten vanaf het moment dat de gebruiker naar de pagina navigeert. De browser herberekent het LCP-element continu naarmate de pagina laadt. Het element dat uiteindelijk het grootst is op het moment dat de gebruiker voor het eerst kan interacteren, wordt gerapporteerd.
Elementen die meetellen voor LCP
<img>-elementen (inclusief afbeeldingen binnen<picture>)<video>-elementen (de posterafbeelding of het eerste zichtbare frame)- Elementen met een achtergrondafbeelding geladen via CSS
url() - Blokniveau-elementen met tekstinhoud (zoals een grote
<h1>of<p>)
In de praktijk is het LCP-element op de meeste websites gewoon een hero-afbeelding. Uit analyses van het HTTP Archive blijkt dat op meer dan 70% van de pagina's het LCP-element een <img>-tag is. Dat maakt afbeeldingsoptimalisatie veruit de belangrijkste hefboom die je hebt voor LCP-verbetering.
De drempelwaarden
- Goed: ≤ 2,5 seconden
- Verbetering nodig: 2,5 – 4,0 seconden
- Slecht: > 4,0 seconden
Belangrijk detail: Google meet LCP op het 75e percentiel van alle paginabezoeken over een rollende periode van 28 dagen. Dat betekent dat niet je gemiddelde maar je slechtst presterende kwart van de bezoeken je score bepaalt. Eén slecht presterende pagina-template kan je hele site naar beneden trekken. Dat is een verrassing voor veel ontwikkelaars die alleen naar gemiddelden kijken.
De Vier Deelfasen van LCP: Begrijp Waar Je Tijd Verliest
Oké, dit is het cruciale inzicht dat de meeste LCP-gidsen overslaan. LCP is geen monolithische metric — het is de som van vier opeenvolgende fasen. Elke fase heeft een compleet andere oorzaak en vereist een compleet andere oplossing. Sinds februari 2025 publiceert Google zelfs velddata voor elk van deze deelfasen in CrUX, wat het debuggen een stuk makkelijker maakt.
Fase 1: Time to First Byte (TTFB)
TTFB meet de tijd vanaf de navigatie-start tot het moment waarop de browser de eerste byte van de HTML-response ontvangt. Dit omvat DNS-lookup, TCP-verbinding, TLS-handshake, en de serververwerkingstijd.
Doelwaarde: maximaal 800 milliseconden.
Hier komt een behoorlijk ontnuchterend feit: voor de helft van alle websites met een slechte LCP is de TTFB alleen al zo hoog (mediaan van 2.270ms bij het 75e percentiel) dat het wiskundig onmogelijk is om onder de 2,5 seconden uit te komen. Als je TTFB boven de 800ms zit, is dat vrijwel altijd waar je moet beginnen. Alles wat daarna komt, maakt dan niet meer uit.
Fase 2: Resource Load Delay
Resource Load Delay is de tijd tussen het ontvangen van de eerste byte en het moment waarop de browser daadwerkelijk begint met het downloaden van de LCP-resource (meestal een afbeelding). Dit noem ik graag de "ontdekkingskloof" — hoe lang duurt het voordat de browser weet dat die afbeelding er is en dat 'ie belangrijk is?
Doelwaarde: maximaal 10% van je totale LCP-budget.
Dit is verrassend vaak de grootste boosdoener. Als je LCP-afbeelding pas wordt ontdekt nadat een CSS-bestand is geladen dat een background-image definieert, of nadat JavaScript is uitgevoerd dat het element dynamisch toevoegt aan de DOM, dan heb je een probleem. De browser's preload scanner kan zulke afbeeldingen simpelweg niet vinden in de initiële HTML. Ik heb projecten gezien waar dit alleen al 1,5 seconde kostte — puur omdat de afbeelding "verstopt" zat achter CSS.
Fase 3: Resource Load Duration
Resource Load Duration is de daadwerkelijke downloadtijd van de LCP-resource. Dit hangt direct af van twee dingen: de bestandsgrootte en de netwerksnelheid van de gebruiker.
Doelwaarde: maximaal 40% van je totale LCP-budget.
Hier draait alles om bestandsgrootte. Moderne afbeeldingsformaten (AVIF, WebP), responsive afbeeldingen via srcset, goede compressie, en een CDN dat assets dichtbij je gebruikers serveert — dat zijn je wapens.
Fase 4: Element Render Delay
Render Delay is de tijd vanaf het moment dat de LCP-resource volledig is gedownload tot het moment dat de browser het element daadwerkelijk op het scherm schildert. De afbeelding is er, maar de browser kan 'm nog niet tonen. Frustrerend, toch?
Doelwaarde: maximaal 10% van je totale LCP-budget.
De meest voorkomende oorzaken: render-blocking stylesheets (de browser weigert iets te schilderen totdat alle CSS in de <head> is verwerkt), zware JavaScript-taken die de main thread blokkeren, en grote re-renders door frameworks die de DOM herstructureren na het laden.
LCP-Deelfasen Meten met Code
Je kunt de deelfasen niet optimaliseren als je ze niet kunt meten. Zo simpel is het. De web-vitals-bibliotheek (v4+) maakt dit bijzonder eenvoudig met de attribution build.
web-vitals v4 Attribution Build
import { onLCP } from 'web-vitals/attribution';
onLCP(({ name, value, attribution }) => {
console.log('LCP-waarde:', value, 'ms');
console.log('LCP-element:', attribution.element);
// De vier deelfasen
console.log('TTFB:', Math.round(attribution.timeToFirstByte), 'ms');
console.log('Resource Load Delay:', Math.round(attribution.resourceLoadDelay), 'ms');
console.log('Resource Load Duration:', Math.round(attribution.resourceLoadDuration), 'ms');
console.log('Element Render Delay:', Math.round(attribution.elementRenderDelay), 'ms');
// Stuur naar je eigen analytics
fetch('/api/vitals', {
method: 'POST',
body: JSON.stringify({
metric: 'LCP',
value: value,
element: attribution.element,
ttfb: attribution.timeToFirstByte,
loadDelay: attribution.resourceLoadDelay,
loadDuration: attribution.resourceLoadDuration,
renderDelay: attribution.elementRenderDelay
}),
keepalive: true
});
});Even opletten: in web-vitals v4 is resourceLoadTime hernoemd naar resourceLoadDuration. Als je upgradet van v3, moet je deze naam aanpassen in je code — anders krijg je undefined terug en zit je je af te vragen waarom je data er raar uitziet.
Handmatige Meting via de Performance API
Wil je de deelfasen meten zonder externe bibliotheek? Kan prima met de native Performance API:
new PerformanceObserver((list) => {
const entries = list.getEntries();
const lastEntry = entries[entries.length - 1];
const navEntry = performance.getEntriesByType('navigation')[0];
const ttfb = navEntry.responseStart;
const resourceLoadDelay = lastEntry.startTime - ttfb;
const resourceLoadDuration = lastEntry.loadTime
? lastEntry.loadTime - lastEntry.startTime
: 0;
const renderDelay = lastEntry.renderTime - (lastEntry.loadTime || lastEntry.startTime);
console.log({
element: lastEntry.element,
ttfb: Math.round(ttfb),
resourceLoadDelay: Math.round(resourceLoadDelay),
resourceLoadDuration: Math.round(resourceLoadDuration),
renderDelay: Math.round(renderDelay),
totalLCP: Math.round(lastEntry.renderTime)
});
}).observe({ type: 'largest-contentful-paint', buffered: true });LCP-Deelfasen in Lighthouse en DevTools
In Chrome DevTools (Performance-tabblad) en Lighthouse kun je de deelfasen ook visueel inspecteren. Open Lighthouse, voer een Performance-audit uit en scroll naar de diagnostiek-sectie. Zoek de audit "Largest Contentful Paint element" — daar vind je een watervalgrafiek met de vier fasen en hun duur. De langste fase? Dat is je primaire bottleneck.
Fase 1 Optimaliseren: TTFB Verlagen
TTFB is het fundament van alles. Niets op de frontend kan beginnen voordat de server die eerste byte levert. Het mooie is: alles wat je doet om TTFB te versnellen, verbetert automatisch ook elke andere laadmetric. Dus als je twijfelt waar je moet beginnen — begin hier.
Server-side caching implementeren
Full-page caching is de snelste winst die je kunt behalen. Een goed geconfigureerde cache kan TTFB terugbrengen van 2 seconden naar minder dan 100 milliseconden. Dat is een wereld van verschil. Gebruik Redis, Varnish, of de ingebouwde caching van je framework:
# Nginx full-page caching configuratie
proxy_cache_path /var/cache/nginx levels=1:2
keys_zone=page_cache:10m max_size=1g inactive=60m;
server {
location / {
proxy_cache page_cache;
proxy_cache_valid 200 10m;
proxy_cache_use_stale error timeout updating;
# Stale-while-revalidate: serveer gecachte content
# terwijl een verse versie op de achtergrond wordt opgehaald
add_header Cache-Control "public, max-age=600, stale-while-revalidate=30";
add_header X-Cache-Status $upstream_cache_status;
proxy_pass http://backend;
}
}CDN inzetten voor lagere latentie
Als je server in Nederland staat en een gebruiker in Indonesië je site bezoekt, voegt de netwerk-roundtrip 200–400ms toe aan elk verzoek. Dat tikt behoorlijk aan. Een CDN plaatst kopieën van je content op servers wereldwijd. Configureer je CDN-headers correct:
# Cloudflare / generieke CDN cache headers
Cache-Control: public, max-age=3600, s-maxage=86400, stale-while-revalidate=60
# Voor dynamische pagina's met personalisatie:
Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=30
Vary: Accept-Encoding, CookieBrotli-compressie activeren
Brotli levert 15–25% betere compressie dan Gzip voor HTML, CSS en JavaScript. Alle moderne browsers ondersteunen het inmiddels, dus er is eigenlijk geen reden om het niet te gebruiken. In Nginx:
# Nginx Brotli configuratie
brotli on;
brotli_comp_level 6;
brotli_types text/html text/css application/javascript
application/json image/svg+xml;Fase 2 Optimaliseren: Resource Load Delay Elimineren
Resource Load Delay is naar mijn ervaring de meest onderschatte deelfase, maar tegelijk de fase waar de grootste winst te behalen valt. Het draait om één simpel ding: zorg dat de browser je LCP-resource zo vroeg mogelijk ontdekt.
fetchpriority en preload: de krachtigste combinatie
Het fetchpriority-attribuut is nu volledig ondersteund in alle moderne browsers: Chrome 102+, Safari 17.2+, Firefox 132+ en Edge 102+. In combinatie met <link rel="preload"> vormt het de krachtigste tool om Resource Load Delay weg te werken.
Twee scenario's:
Scenario 1: LCP-afbeelding is een <img>-tag in de HTML
<!-- De browser kan deze afbeelding direct ontdekken via de preload scanner.
fetchpriority="high" zorgt dat de download direct start met hoge prioriteit,
in plaats van te wachten tot na de First Contentful Paint. -->
<img
src="/images/hero.webp"
alt="Hero afbeelding"
width="1200"
height="600"
fetchpriority="high"
>De resultaten spreken voor zich. In tests verbeterde LCP van 4,2 seconden naar 1,9 seconden door simpelweg fetchpriority="high" aan het LCP-element toe te voegen. Google Flights zag een verbetering van 2,6s naar 1,9s, en Etsy rapporteerde 4% verbetering in productie. Eén attribuut, meer dan twee seconden winst.
Scenario 2: LCP-afbeelding is een CSS background-image
<!-- De preload scanner kan CSS background-images NIET ontdekken.
Gebruik daarom een expliciete preload met fetchpriority="high". -->
<head>
<link
rel="preload"
href="/images/hero-bg.webp"
as="image"
fetchpriority="high"
>
</head>In één specifieke test verbeterde LCP van 3,4 naar 1,7 seconden door een preload met fetchpriority="high" toe te voegen voor een CSS background-image. Een halvering van de laadtijd met één enkele regel HTML — dat soort winsten zie je niet vaak.
Vermijd lazy-loading op het LCP-element
Dit klinkt misschien voor de hand liggend, maar je zou versteld staan hoe vaak het voorkomt. Een CrUX-analyse uit 2024 toonde aan dat websites die hun LCP-element lazy-loaden een 35% tragere LCP hebben. Verwijder altijd het loading="lazy"-attribuut van je LCP-afbeelding:
<!-- FOUT: lazy-loading op het LCP-element -->
<img src="/images/hero.webp" loading="lazy" alt="Hero">
<!-- GOED: geen lazy-loading, wel fetchpriority -->
<img src="/images/hero.webp" fetchpriority="high" alt="Hero"
width="1200" height="600">Houd de HTML compact voor snellere ontdekking
Een minder bekend feit (en eerlijk gezegd een die ik zelf ook pas laat leerde): de preload scanner verwerkt de HTML in chunks van ongeveer 14KB — de typische grootte van het eerste TCP-pakket. Als je <img>-tag voor het LCP-element pas na die eerste 14KB verschijnt, moet de browser extra roundtrips maken voordat 'ie de afbeelding überhaupt ontdekt. Zorg ervoor dat je LCP-element zo hoog mogelijk in de HTML staat.
Fase 3 Optimaliseren: Resource Load Duration Verkorten
Als de browser je LCP-resource eenmaal gevonden heeft, moet die zo snel mogelijk gedownload worden. Hier draait het puur om bestandsgrootte en netwerkafstand.
Moderne afbeeldingsformaten: AVIF en WebP
AVIF levert tot 60% kleinere bestanden dan JPEG bij vergelijkbare visuele kwaliteit. WebP zit daar tussenin met 25–34% besparing. Gebruik het <picture>-element voor automatische formatonderhandeling:
<picture>
<!-- AVIF: beste compressie, breed ondersteund (Chrome, Firefox, Safari 16+) -->
<source srcset="/images/hero.avif" type="image/avif">
<!-- WebP: goede fallback, vrijwel universele ondersteuning -->
<source srcset="/images/hero.webp" type="image/webp">
<!-- JPEG: ultieme fallback voor zeer oude browsers -->
<img
src="/images/hero.jpg"
alt="Hero afbeelding van het product"
width="1200"
height="600"
fetchpriority="high"
>
</picture>Kleine maar belangrijke opmerking: bij een <picture>-element plaats je het fetchpriority-attribuut op het <img>-element, niet op de <source>-tags. Dit is een fout die ik regelmatig tegenkom in code reviews.
Responsive afbeeldingen met srcset
Serveer niet dezelfde 1200px-brede afbeelding aan een smartphone met een 360px-breed scherm. Dat is zonde van de bandbreedte (en je gebruiker betaalt er ook nog eens voor op mobiel). Gebruik srcset met sizes om de browser de juiste afbeeldingsgrootte te laten kiezen:
<img
srcset="
/images/hero-400.webp 400w,
/images/hero-800.webp 800w,
/images/hero-1200.webp 1200w,
/images/hero-1600.webp 1600w
"
sizes="(max-width: 640px) 100vw,
(max-width: 1024px) 80vw,
1200px"
src="/images/hero-1200.webp"
alt="Hero afbeelding"
width="1200"
height="600"
fetchpriority="high"
>Om het in perspectief te zetten: een 400px-brede WebP-afbeelding is typisch 30–50KB, vergeleken met 150–300KB voor een 1200px JPEG. Op mobiele netwerken scheelt dat honderden milliseconden downloadtijd.
Automatische afbeeldingsoptimalisatie via een Image CDN
Wil je dit niet allemaal handmatig beheren? Snap ik. Een Image CDN (zoals Cloudflare Images, Imgix of Cloudinary) kan afbeeldingen automatisch converteren naar het optimale formaat, resizen op basis van het Accept-header van de browser, en serveren vanaf de dichtstbijzijnde edge-locatie. Het kost wat, maar het bespaart je enorm veel werk.
Fase 4 Optimaliseren: Render Delay Minimaliseren
De afbeelding is gedownload, maar de browser toont 'm nog niet. Dat is Render Delay — en het wordt veroorzaakt door alles wat de main thread bezighoudt of de rendering blokkeert. Dit is de fase die ontwikkelaars het vaakst over het hoofd zien.
Critical CSS inlinen
De browser weigert iets te schilderen totdat alle stylesheets in de <head> zijn gedownload en verwerkt. De oplossing: extraheer de CSS die nodig is voor above-the-fold content en inline die direct in de HTML. Laad de rest asynchroon:
<head>
<!-- Critical CSS inline: wordt direct verwerkt, geen extra netwerkverzoek -->
<style>
.hero { position: relative; width: 100%; height: 60vh; }
.hero img { width: 100%; height: 100%; object-fit: cover; }
.nav { display: flex; align-items: center; padding: 1rem; }
/* ... alleen above-the-fold styles ... */
</style>
<!-- Niet-kritieke CSS asynchroon laden -->
<link rel="preload" href="/css/main.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/main.css"></noscript>
</head>Vermijd CSS @import-ketens
CSS @import-regels creëren een waterval van opeenvolgende verzoeken. Als main.css een @import bevat naar typography.css, die weer een @import naar variables.css heeft, dan moeten drie bestanden achter elkaar worden opgehaald voordat de browser kan renderen. Drie requests in serie waar het er één had kunnen zijn. Vervang @import door directe <link>-tags of bundel je CSS in een build-stap.
Font-optimalisatie met font-display: swap
Als je LCP-element tekst bevat, kan het laden van weblettertypen de Render Delay flink verhogen. De browser wacht standaard tot 3 seconden op een lettertype voordat het een fallback toont — drie seconden! Los dit op met font-display: swap en preload je kritieke lettertypen:
<head>
<!-- Preload het belangrijkste lettertype -->
<link rel="preload" href="/fonts/inter-var.woff2"
as="font" type="font/woff2" crossorigin>
</head>
<style>
@font-face {
font-family: 'Inter';
src: url('/fonts/inter-var.woff2') format('woff2');
font-display: swap;
/* swap: toont direct een fallback-lettertype en wisselt zodra
het weblettertype geladen is. Voorkomt onzichtbare tekst. */
}
</style>Render-blocking JavaScript minimaliseren
JavaScript in de <head> zonder async of defer blokkeert het renderen volledig. Voeg defer toe aan scripts die niet direct nodig zijn, of verplaats ze naar het einde van de <body>:
<!-- FOUT: blokkeert rendering -->
<script src="/js/analytics.js"></script>
<!-- GOED: defer laadt parallel en voert uit na HTML-parsing -->
<script src="/js/analytics.js" defer></script>
<!-- OOK GOED: async voor onafhankelijke scripts -->
<script src="/js/analytics.js" async></script>Het Complete LCP-Optimalisatierecept: Alles Samen
Goed, laten we alle technieken combineren in één voorbeeld van een volledig geoptimaliseerde <head> en hero-sectie. Dit is in feite je checklist:
<!DOCTYPE html>
<html lang="nl">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<!-- 1. TTFB: CDN + caching regelen we server-side -->
<!-- 2. Resource Load Delay: preload + preconnect -->
<link rel="preconnect" href="https://cdn.example.com">
<link rel="preload" href="/fonts/inter-var.woff2"
as="font" type="font/woff2" crossorigin>
<!-- 3. Render Delay: critical CSS inline -->
<style>
*, *::before, *::after { box-sizing: border-box; margin: 0; }
.hero { position: relative; width: 100%; aspect-ratio: 2/1; }
.hero img { width: 100%; height: 100%; object-fit: cover; display: block; }
@font-face {
font-family: 'Inter';
src: url('/fonts/inter-var.woff2') format('woff2');
font-display: swap;
}
body { font-family: 'Inter', system-ui, sans-serif; }
</style>
<!-- Niet-kritieke CSS asynchroon -->
<link rel="preload" href="/css/main.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/main.css"></noscript>
<!-- Scripts uitgesteld laden -->
<script src="/js/app.js" defer></script>
</head>
<body>
<!-- 4. Resource Load Duration: AVIF/WebP + responsive + fetchpriority -->
<section class="hero">
<picture>
<source
srcset="/images/hero-400.avif 400w,
/images/hero-800.avif 800w,
/images/hero-1200.avif 1200w"
sizes="100vw"
type="image/avif">
<source
srcset="/images/hero-400.webp 400w,
/images/hero-800.webp 800w,
/images/hero-1200.webp 1200w"
sizes="100vw"
type="image/webp">
<img
src="/images/hero-1200.jpg"
srcset="/images/hero-400.jpg 400w,
/images/hero-800.jpg 800w,
/images/hero-1200.jpg 1200w"
sizes="100vw"
alt="Productoverzicht hero afbeelding"
width="1200"
height="600"
fetchpriority="high"
>
</picture>
</section>
<!-- Afbeeldingen below the fold: wél lazy-loaden -->
<img src="/images/product.webp" loading="lazy" alt="Product"
width="600" height="400">
</body>
</html>LCP Monitoren in Productie
Optimalisatie is geen eenmalige actie — dat kan ik niet genoeg benadrukken. Elke nieuwe feature, elke extra afbeelding, elk nieuw third-party script kan je LCP weer verslechteren. Zet daarom structurele monitoring op.
Real User Monitoring met web-vitals
import { onLCP } from 'web-vitals/attribution';
onLCP(({ value, attribution }) => {
// Alleen rapporteren als LCP boven de drempel zit
if (value > 2500) {
const payload = {
url: window.location.pathname,
lcp: Math.round(value),
element: attribution.element,
ttfb: Math.round(attribution.timeToFirstByte),
loadDelay: Math.round(attribution.resourceLoadDelay),
loadDuration: Math.round(attribution.resourceLoadDuration),
renderDelay: Math.round(attribution.elementRenderDelay),
// Voeg de bron-URL toe voor afbeeldingen
resourceUrl: attribution.lcpEntry?.url || null
};
// Gebruik navigator.sendBeacon voor betrouwbare verzending
navigator.sendBeacon('/api/vitals', JSON.stringify(payload));
}
});Door de vier deelfasen per pagina te rapporteren, weet je precies welke fase op welke pagina het probleem is. Geen giswerk meer — pure data. En geloof me, dat maakt het gesprek met stakeholders een stuk makkelijker.
Google Search Console en CrUX
Google Search Console toont je LCP-status per pagina op basis van echte gebruikersdata uit CrUX. Controleer maandelijks het Core Web Vitals-rapport en filter op pagina's met een "slechte" of "verbetering nodig" status. Houd er wel rekening mee dat CrUX-data een rollende periode van 28 dagen beslaat — verbeteringen worden dus pas na enkele weken zichtbaar in de rapporten.
Veelgestelde Vragen over LCP
Wat is een goede LCP-score voor mijn website?
Google beschouwt een LCP van 2,5 seconden of minder als "goed", gemeten op het 75e percentiel van paginabezoeken. Dat betekent dat minimaal 75% van je bezoekers de pagina binnen 2,5 seconden volledig geladen moet zien. In de praktijk zou ik aanraden om naar minder dan 2 seconden te streven, zodat je een buffer hebt voor piekverkeer en tragere apparaten.
Hoe vind ik welk element mijn LCP-element is?
Open Chrome DevTools, ga naar het Lighthouse-tabblad en voer een Performance-audit uit. In de diagnostiek-sectie staat de audit "Largest Contentful Paint element" die exact toont welk element je LCP bepaalt — inclusief een screenshot. Je kunt ook PageSpeed Insights gebruiken, dat hetzelfde rapporteert. Programmatisch kun je de web-vitals-bibliotheek met de attribution build gebruiken om het attribution.element-veld uit te lezen.
Moet ik fetchpriority="high" op meerdere afbeeldingen zetten?
Nee, absoluut niet. Gebruik fetchpriority="high" alleen op je LCP-afbeelding — typisch één afbeelding per pagina. Als je meerdere afbeeldingen hoge prioriteit geeft, concurreren ze met elkaar en met kritieke CSS en JavaScript, waardoor het effect volledig wordt geneutraliseerd. Het is een beetje alsof iedereen in een vergadering tegelijk praat — niemand wordt gehoord.
Wat is het verschil tussen preload en fetchpriority?
<link rel="preload"> zorgt ervoor dat de browser een resource eerder ontdekt — het verkort de Resource Load Delay. fetchpriority="high" zorgt ervoor dat een al ontdekte resource met hogere prioriteit wordt gedownload ten opzichte van andere resources. Ze zijn complementair: preload lost ontdekkingsproblemen op, fetchpriority lost prioriteringsproblemen op. Voor CSS background-images heb je beide nodig; voor <img>-tags in de HTML is vaak alleen fetchpriority="high" voldoende.
Hoe lang duurt het voordat LCP-verbeteringen zichtbaar zijn in Google Search Console?
Google Search Console gebruikt CrUX-data die over een rollende periode van 28 dagen wordt verzameld. Na het doorvoeren van optimalisaties duurt het dus minimaal 28 dagen voordat je de volledige impact ziet. Dat kan frustrerend zijn, ik weet het. In de tussentijd kun je labtools zoals Lighthouse en PageSpeed Insights gebruiken om direct te verifiëren dat je wijzigingen effect hebben. Houd er ook rekening mee dat seizoensgebonden verkeerspatronen de scores tijdelijk kunnen beïnvloeden.