LCP onder 2,5 seconden: de 7 grootste boosdoeners

LCP verbeteren begint met weten welk element de Largest Contentful Paint is en waar de vertraging zit: in de serverreactie, het laten ontdekken van de afbeelding, het downloaden ervan of het renderen. De zeven grootste boosdoeners zijn een trage server, een lazy-geladen hero, een onvindbare LCP-afbeelding, te zware afbeeldingen, render-blokkerende CSS en JavaScript, trage webfonts en hero’s die pas na een animatie of script zichtbaar worden. Los je die op, dan haal je de grens van 2,5 seconden in de meeste gevallen.

Hieronder per boosdoener wat er misgaat en wat je eraan doet, gevolgd door een stappenplan.

Wat meet LCP precies?

Largest Contentful Paint meet hoe lang het duurt tot het grootste zichtbare inhoudselement in het eerste scherm is weergegeven. Meestal is dat een hero-afbeelding, een grote kop of een tekstblok. Google beschouwt een LCP van maximaal 2,5 seconden als goed, gemeten bij het 75e percentiel van echte bezoekers. Tussen 2,5 en 4 seconden heet het “verbetering nodig”, daarboven “slecht”.

Handig om te weten: de LCP-tijd laat zich opknippen in vier delen. Die indeling, beschreven op web.dev, helpt om de oorzaak te vinden:

Onderdeel	Wat het is	Typische oorzaak bij vertraging
Time to First Byte	Tijd tot de eerste byte HTML binnenkomt	Trage hosting, geen caching
Resource load delay	Tijd tot de browser begint met het laden van de LCP-afbeelding	Afbeelding laat ontdekt, lazy loading
Resource load duration	Tijd om de afbeelding te downloaden	Te groot bestand, verkeerd formaat
Element render delay	Tijd tussen downloaden en daadwerkelijk tonen	Blokkerende CSS of JS, fonts, animaties

Meer achtergrond over de drie Core Web Vitals lees je in Core Web Vitals uitgelegd voor ondernemers.

De 7 grootste boosdoeners bij LCP verbeteren

1. Een trage serverreactie

Als de HTML al lang op zich laat wachten, begint alles later. Goedkope gedeelde hosting, geen paginacaching, zware databasequery’s of veel plugins die bij elke aanvraag code uitvoeren, verhogen de Time to First Byte. Oplossing: paginacaching, een snellere server of hosting met een moderne PHP-versie, en een CDN voor bezoekers verder weg.

2. Lazy loading op de hero-afbeelding

Lazy loading is prima voor afbeeldingen onder de vouw, maar funest voor de LCP-afbeelding. Met loading="lazy" wacht de browser met laden tot de layout bekend is. Oplossing: verwijder lazy loading van de afbeelding in het eerste scherm en geef hem fetchpriority="high".

3. Een LCP-afbeelding die de browser laat ontdekt

Staat de hero als CSS-achtergrondafbeelding in een extern stylesheet, of wordt hij door JavaScript ingevoegd, dan ziet de browser hem pas laat. Oplossing: gebruik een gewone <img> in de HTML, of preload de afbeelding met <link rel="preload" as="image">.

4. Te zware afbeeldingen

Een foto van enkele megabytes rechtstreeks van de camera of stockbank, op volle resolutie ingeladen op een telefoon, kost op mobiele verbindingen veel tijd. Oplossing: moderne formaten zoals AVIF en WebP, de juiste afmetingen met srcset en sizes, en verstandige compressie. In afbeeldingen optimaliseren staat hoe je dat aanpakt.

5. Render-blokkerende CSS en JavaScript

Stylesheets en scripts in de head houden de weergave op tot ze geladen zijn. Pagebuilders en plugins laden vaak veel CSS en JS die op die pagina niet eens wordt gebruikt. Oplossing: ongebruikte assets per pagina uitschakelen, scripts met defer laden, kritieke CSS inline zetten en de rest later laden.

6. Webfonts bij een tekst-LCP

Is je LCP-element een grote kop, dan kan een trage webfont de weergave vertragen. Oplossing: host fonts zelf, gebruik WOFF2, beperk het aantal gewichten, preload het belangrijkste font en gebruik font-display: swap zodat tekst direct zichtbaar is.

7. Hero’s die wachten op een animatie of script

Sliders, fade-in-effecten en hero’s die met opacity: 0 beginnen tot een script ze zichtbaar maakt, verschuiven het moment waarop het element echt wordt getoond. Ook client-side rendering, waarbij de inhoud pas na JavaScript verschijnt, vertraagt LCP. Oplossing: toon de hero direct, gebruik animaties alleen als extraatje dat niet wacht op scripts, en kies bij voorkeur voor een statische hero boven een slider.

LCP verbeteren in WordPress: snelle winst

Draait je site op WordPress, dan zitten de grootste boosdoeners vaak in dezelfde hoek. Thema’s en pagebuilders zetten soms standaard lazy loading op alle afbeeldingen, ook op de hero. Sliderplugins laden scripts op elke pagina, ook waar geen slider staat. En optimalisatieplugins die alles tegelijk proberen, kunnen elkaar juist in de weg zitten. Een paar gerichte ingrepen leveren vaak meer op dan een extra plugin:

• Controleer of de eerste afbeelding op elke template zonder lazy loading en met hoge prioriteit wordt geladen.
• Vervang een slider in de hero door één sterke, statische afbeelding of een typografische hero.
• Schakel CSS en scripts van plugins uit op pagina’s waar ze niet nodig zijn.
• Zorg voor paginacaching op serverniveau of via één betrouwbare cachingplugin.

Meer over een slanke WordPress-installatie lees je in WordPress sneller maken zonder tien plugins. Zit de vertraging dieper, bijvoorbeeld in de opbouw van het thema, dan is een technische SEO-analyse de logische volgende stap.

Hoe vind je de boosdoener op jouw site?

Begin met meten. Er zijn twee soorten gegevens:

• Velddata van echte bezoekers, zichtbaar in het Core Web Vitals-rapport in Search Console en in PageSpeed Insights. Dit is wat telt.
• Labdata uit een gesimuleerde test, zoals Lighthouse of het Performance-paneel in Chrome DevTools. Dit is handig om de oorzaak te vinden.

In PageSpeed Insights en Lighthouse zie je welk element als LCP is aangemerkt en hoe de tijd over de vier onderdelen verdeeld is. Is de Time to First Byte hoog, kijk dan naar de server. Is de load delay groot, dan ontdekt de browser de afbeelding te laat. Is de render delay groot, dan blokkeert er iets. Zo hoef je niet te gokken.

Let op het verschil tussen mobiel en desktop. LCP is op mobiel bijna altijd slechter door tragere processors en verbindingen, en Google kijkt bij de beoordeling vooral naar de mobiele ervaring. Test daarom altijd mobiel.

Zo pak je het aan

1. Bepaal per template het LCP-element: homepage, dienstpagina, blogartikel, productpagina.
2. Bekijk de velddata in Search Console om te zien welke groepen pagina’s boven 2,5 seconden zitten.
3. Splits de tijd op in de vier onderdelen met PageSpeed Insights of DevTools.
4. Los de grootste vertraging eerst op. Vaak is dat lazy loading op de hero of een te zware afbeelding: snel te verhelpen, groot effect.
5. Voeg fetchpriority="high" toe aan de LCP-afbeelding en verwijder lazy loading.
6. Pak server en caching aan als de Time to First Byte hoog blijft.
7. Ruim render-blokkerende assets op en optimaliseer fonts.
8. Meet opnieuw in het lab, en volg de velddata in de weken erna. Velddata reageren met vertraging, omdat ze over een periode van echte bezoeken worden verzameld.

Stel: een webshop in Eindhoven heeft een LCP van ruim vier seconden op mobiel. De analyse laat zien dat de hero een CSS-achtergrondafbeelding van meerdere megabytes is, met daarbovenop een slider-script. Een gewone afbeelding in AVIF met fetchpriority="high" en een statische hero pakken dan in één keer twee boosdoeners aan.

Liever eerst weten waar jouw site staat? Een gratis SEO-scan geeft je een eerste beeld van de snelheid en de grootste knelpunten.

Conclusie

LCP verbeteren is geen kwestie van willekeurig plugins installeren, maar van gericht zoeken waar de tijd verloren gaat. Bepaal het LCP-element, splits de tijd op in serverreactie, ontdekking, download en weergave, en pak de grootste vertraging eerst aan. De zeven boosdoeners in dit artikel verklaren het overgrote deel van de trage pagina’s, en de meeste zijn met een paar gerichte aanpassingen op te lossen.

Wil je dat iemand de snelheid van je site structureel op orde brengt? Bekijk onze aanpak voor technische SEO.