Largest Contentful Paint optimaliseren

LCP is de Core Web Vital waar de meeste webshops op zakken. Een score boven 2,5 seconden kost je rankings en conversies. Dit is de stap-voor-stap aanpak die wij gebruiken om LCP onder de 2 seconden te krijgen.

Largest Contentful Paint optimaliseren — de complete gids

Google zegt het al jaren: een LCP boven 2,5 seconden is "slecht". Voor e-commerce is die drempel relevant: onderzoek van Portent laat zien dat een pagina die in 1 seconde laadt een conversieratio heeft die 3x hoger is dan een pagina die in 5 seconden laadt.

LCP is de Core Web Vital die de meeste webshops rood kleurt. In onze audits zien we regelmatig LCP-scores van 4-7 seconden op mobiel. Dit artikel beschrijft de aanpak die wij gebruiken om dat naar onder de 2 seconden te brengen.

Wat je leert in dit artikel

Wat LCP precies meet en welk element het uitlokt
De vijf meest voorkomende LCP-oorzaken
Hero image optimalisatie stap voor stap
Server response time verbeteren
Resource hints: preload, preconnect en prefetch correct inzetten
Hoe LCP samenhangt met andere Core Web Vitals

Wat is Largest Contentful Paint?

LCP meet hoe lang het duurt voordat het grootste zichtbare inhoudelement in de viewport volledig gerenderd is. Dat element is bijna altijd een van deze twee:

Een afbeelding (hero image, product hero, banner)
Een tekstblok (grote heading of introductietekst)

Voor webshops is het in 95% van de gevallen de hero image bovenaan de homepage of de product-hoofdafbeelding op een productpagina.

Drempelwaarden:

Goed: onder 2,5 seconden
Verbetering nodig: 2,5 tot 4,0 seconden
Slecht: boven 4,0 seconden

Google meet LCP op basis van field data (echte gebruikers via Chrome User Experience Report) en lab data (via PageSpeed Insights / Lighthouse). Field data telt voor je ranking.

De vijf meest voorkomende LCP-oorzaken

1. Afbeelding niet voorgeladen (geen preload)

De browser ontdekt de hero image pas nadat hij HTML en CSS geparseerd heeft. Dat kost 500-800ms extra tijd voordat de download überhaupt begint.

Oplossing: voeg een toe in de voor de LCP-afbeelding.

html

<!-- Voeg dit toe in de <head> -->
<link
    rel="preload"
    as="image"
    href="/media/catalog/product/hero-image.webp"
    fetchpriority="high"
>

2. Render-blokkerende resources

CSS en JavaScript bestanden die geladen worden vóór de LCP-afbeelding vertragen de rendering. Een stylesheet van 200KB die niet gesplitst is, blokkeert de browser volledig.

3. Trage serverrespons (TTFB)

Als de server 1,5 seconden nodig heeft om de eerste byte te sturen, begint de LCP-klok al op achterstand. TTFB is de fundamenten. Je kunt de beste afbeeldingen hebben — als de server traag is, is LCP slecht.

4. Afbeelding in verkeerd formaat of te groot

Een JPEG van 1,2MB als hero image is in 2026 niet acceptabel. Een WebP van dezelfde afbeelding is 300-400KB. Een AVIF is nog compacter. De browser moet minder data downloaden en toont de afbeelding sneller.

5. Geen CDN voor statische assets

Als je webshopserver in Amsterdam staat en een gebruiker in Rotterdam afbeeldingen ophaalt, is de latency laag. Maar als je server in Frankfurt staat zonder CDN, voeg je 50-80ms toe aan elk asset-request.

Hero image optimalisatie stap voor stap

De hero image is voor de meeste webshops het LCP-element. Hier is de volledige optimalisatieroutine.

Stap 1: Identificeer het LCP-element

Open Chrome DevTools, ga naar de Performance tab en neem een paginalading op. Het LCP-element is gemarkeerd in de timeline. Of gebruik PageSpeed Insights — die toont je ook welk element het LCP uitlokt.

Stap 2: Converteer naar WebP of AVIF

bash

# Converteer JPEG naar WebP met cwebp (CLI tool)
cwebp -q 85 hero-image.jpg -o hero-image.webp

# Converteer naar AVIF met avifenc
avifenc --min 20 --max 30 hero-image.jpg hero-image.avif

WebP levert gemiddeld 25-35% kleinere bestanden dan JPEG bij vergelijkbare kwaliteit. AVIF levert 40-50% kleiner maar heeft iets minder browser-ondersteuning (95%+ in 2026).

Stap 3: Gebruik responsive images met srcset

html

<picture>
    <!-- AVIF voor browsers die het ondersteunen -->
    <source
        type="image/avif"
        srcset="
            /media/hero-400.avif 400w,
            /media/hero-800.avif 800w,
            /media/hero-1200.avif 1200w
        "
        sizes="100vw"
    >
    <!-- WebP als fallback -->
    <source
        type="image/webp"
        srcset="
            /media/hero-400.webp 400w,
            /media/hero-800.webp 800w,
            /media/hero-1200.webp 1200w
        "
        sizes="100vw"
    >
    <!-- JPEG als laatste fallback -->
    <img
        src="/media/hero-1200.jpg"
        alt="Hero afbeelding webshop"
        width="1200"
        height="600"
        fetchpriority="high"
        loading="eager"
    >
</picture>

Let op: de LCP-afbeelding krijgt loading="eager" en fetchpriority="high". Nooit loading="lazy" op het LCP-element.

Stap 4: Voorkom layout shift

Geef de afbeelding altijd expliciete width en height attributen. Zonder die attributen weet de browser de hoogte niet totdat de afbeelding gedownload is. Dat veroorzaakt een layout shift en raakt je CLS-score.

Server response time (TTFB) verbeteren

Een goede LCP begint bij een snelle TTFB. Google adviseert onder de 800ms. Wij streven naar onder de 400ms.

Page cache inschakelen

Voor Magento: schakel Varnish Cache in. Gecachte pagina's leveren TTFB van 50-150ms. Ongecachte Magento-pagina's zijn 1-3 seconden.

bash

# Magento: stel Varnish in als full-page cache
php bin/magento config:set system/full_page_cache/caching_application 2
php bin/magento cache:flush

Database queries optimaliseren

Soms zit de vertraging in een trage query op de categoriepagina. Gebruik de Magento query log om de zwaarste queries te identificeren.

php

// In development: query logging inschakelen
\Magento\Framework\App\ObjectManager::getInstance()
    ->get(\Psr\Log\LoggerInterface::class)
    ->debug('Query uitgevoerd: ' . $query->__toString());

Hosting upgraden

Een VPS met 2 CPU-cores en 4GB RAM runt een middelgrote Magento-webshop acceptabel. Onder die grens wordt TTFB een structureel probleem. Gedeelde hosting is voor Magento 2 niet geschikt. Voor geoptimaliseerde Magento-hosting raden wij Hypernode aan — specifiek gebouwd voor Magento met Varnish, Redis en Elasticsearch out of the box.

Resource hints: preload, preconnect en prefetch

Resource hints vertellen de browser wat hij vroeg moet ophalen.

preload — haal dit asset direct op, ik heb het binnenkort nodig:

html

<!-- Hero image preloaden -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

<!-- Kritiek lettertype preloaden -->
<link rel="preload" as="font" type="font/woff2" href="/fonts/main.woff2" crossorigin>

preconnect — stel alvast een verbinding in met dit domein:

html

<!-- CDN-verbinding vroeg openen -->
<link rel="preconnect" href="https://cdn.mijnwebshop.nl">

<!-- Google Fonts verbinding (als je die gebruikt) -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

prefetch — laad dit asset in de achtergrond voor mogelijke toekomstige navigatie:

html

<!-- Volgende pagina prefetchen (gebruik spaarzaam) -->
<link rel="prefetch" href="/categorie/bestsellers">

Gebruik preload spaarzaam. Elk rel="preload" zorgt dat de browser dat asset prioriteit geeft. Als je tien dingen preloadet, heeft geen van alle prioriteit.

LCP en andere Core Web Vitals

LCP staat niet op zichzelf. Het hangt samen met de andere metrics in onze gids over Core Web Vitals 2026.

Een trage TTFB schaadt LCP en kan ook FCP beïnvloeden. Grote afbeeldingen die laat laden gaan vaak gepaard met layoutverschuivingen (slechte CLS). JavaScript-bundels die rendering blokkeren vertragen LCP én INP.

Het goede nieuws: LCP-optimalisaties helpen bijna altijd meerdere metrics tegelijk.

Benchmarks uit de praktijk

Wij hebben LCP-optimalisaties uitgevoerd op verschillende webshopplatformen. Typische resultaten:

Situatie	LCP voor	LCP na	Aanpak
Magento 2, geen CDN, JPEG	5,8 sec	1,9 sec	WebP, preload, Varnish
Shopify, grote bundel, geen preload	3,4 sec	1,7 sec	Preload, image format
Hyva frontend, geen preload	2,8 sec	1,2 sec	Preload, AVIF, fetchpriority

De combinatie van imageformaat-optimalisatie, preloading en server-side caching geeft de grootste winst. Elke maatregel afzonderlijk haalt je misschien 0,5-0,8 seconden eraf. Samen kom je onder de 2-secondendrempel.

Conclusie

LCP is oplosbaar. De meeste slechte LCP-scores komen van drie problemen: geen preload op de hero image, afbeeldingen in het verkeerde formaat, en een trage serverrespons. Fix die drie en je bent in de meeste gevallen al onder de 2,5 seconden.

De gedetailleerde aanpak hangt af van je platform. Voor Magento en Hyva hebben wij de optimalisaties al vele malen uitgevoerd. We weten waar de valkuilen liggen. Ook voor Shopify-shops optimaliseren wij LCP structureel.

Zie ook ons artikel over paginasnelheid en conversie-data voor de business-case achter deze technische optimalisaties.

Neem contact op als je wil weten hoe jouw LCP ervoor staat en wat het kost om het te verbeteren.

Veelgestelde vragen

Waarom is mijn LCP op mobiel veel slechter dan op desktop?

Mobiele netwerken zijn trager en mobiele CPU's minder krachtig. Google meet LCP op een gesimuleerd 4G-netwerk met een middelklasse Android-telefoon. Je desktop-score is bijna altijd beter. Optimaliseer altijd voor mobiel als prioriteit.

Mijn LCP-element is tekst, geen afbeelding. Wat doe ik dan?

Tekst als LCP-element is makkelijker te optimaliseren dan afbeeldingen. Zorg dat het lettertype snel geladen is (preload het WOFF2-bestand), gebruik system fonts als fallback en voorkom render-blokkerende CSS. font-display: swap in je font-face declaratie helpt ook.

Hoe meet ik field data LCP in plaats van lab data?

Via de Chrome User Experience Report (CrUX) of via Google Search Console onder Core Web Vitals. PageSpeed Insights toont ook field data als er genoeg Chrome-gebruikers jouw URL hebben bezocht. Lab data (Lighthouse) is een schatting. Field data is wat Google voor je ranking gebruikt.

Helpt een CDN altijd bij LCP?

Een CDN verlaagt latency voor gebruikers die ver van je server zitten. Als je primaire markt Nederland is en je server staat in Amsterdam, is de CDN-winst voor LCP beperkt. Maar voor afbeeldingen helpt een CDN altijd: ze worden gecachet dichter bij de gebruiker en geleverd via optimaal gerouteerde verbindingen.

Geschreven door Ruthger Idema

15+ jaar ervaring in e-commerce development. Gespecialiseerd in Magento, Shopify en Laravel maatwerk.

Meer over ons team →

Deel dit artikel:

Largest Contentful Paint optimaliseren — de complete gids