Waarom LCP de metric is die je ranking echt schaadt
Van de drie Core Web Vitals — LCP, INP en CLS — is Largest Contentful Paint degene waarop de meeste WordPress-sites falen, en degene die het meest direct aan één oorzaak is gekoppeld: afbeeldingen.
LCP meet hoe lang het duurt voordat het grootste zichtbare element op de pagina wordt gerenderd. Bij de overgrote meerderheid van WordPress-sites — blogs, productpagina's, portfolio's van bureaus — is dat element een afbeelding: een hero-banner, een uitgelichte afbeelding, een productfoto boven de vouw.
Als je LCP-score rood is in PageSpeed Insights of Search Console, is de kans groot dat de oplossing geen nieuwe host of cache-plugin is. Het is de afbeelding zelf.
De checklist
Werk deze stappen in volgorde af. Elke stap richt zich op een specifieke manier waarop afbeeldingen LCP vertragen.
1. Identificeer je daadwerkelijke LCP-element
Voordat je iets oplost, bevestig wat er werkelijk gemeten wordt. Open Chrome DevTools → tabblad Performance → leg een paginalaad vast → zoek naar de "LCP"-markering in de tijdlijn. Die wijst exact naar het element.
Je kunt de pagina ook door PageSpeed Insights halen — het rapport noemt het LCP-element direct onder "Diagnostics".
Raad niet. De verkeerde afbeelding optimaliseren kost tijd en verandert de score niet.
2. Controleer het bestandsformaat
JPEG en PNG zijn formaten uit de jaren 90 die nog op veel te veel sites worden geserveerd. WebP is bij gelijke kwaliteit ongeveer 25–35% kleiner dan JPEG, en AVIF gaat nog verder — vaak 50% kleiner dan JPEG.
Als je LCP-afbeelding nog een rauwe JPEG of PNG is, is dit bijna altijd de meest impactvolle beschikbare fix. Zie onze volledige gids voor het converteren van WordPress-afbeeldingen naar WebP voor de technische details — kort gezegd doet Erdo Image Optimizer dit automatisch, met de eigen GD- of Imagick-bibliotheek van je server, zonder API-key.
3. Controleer de daadwerkelijk gerenderde afmetingen
Een foto van 4000×3000px die wordt weergegeven in een hero-container van 800px breed, verspilt ongeveer 90% van de gedownloade bytes. De browser moet het volledige bestand downloaden voordat hij het kan verkleinen.
Controleer dit door rechts te klikken op de afbeelding → Inspecteren → vergelijk de natuurlijke grootte met de gerenderde width/height in de berekende stijlen. Is de natuurlijke grootte meer dan ~1,5x de gerenderde grootte, dan moet de afbeelding worden verkleind — niet alleen gecomprimeerd.
4. Stel expliciete width- en height-attributen in
Ontbrekende width/height-attributen schaden LCP niet direct, maar wel CLS (de layout-shift-metric), en een pagina die de layout verschuift tijdens het laden vertraagt vaak ook de LCP-meting. Elke <img>-tag moet expliciete afmetingen hebben, zodat de browser ruimte kan reserveren voordat het bestand wordt gedownload.
5. Lazy-load de LCP-kandidaat nooit
Dit is de fout die we het vaakst zien: een "performance"-plugin voegt loading="lazy" toe aan elke afbeelding op de pagina, inclusief de hero-afbeelding. Lazy loading vertelt de browser om te wachten met ophalen tot de afbeelding bij de viewport komt — precies het tegenovergestelde van wat je wilt voor de afbeelding die je LCP-score bepaalt.
De oplossing: afbeeldingen boven de vouw moeten eager geladen worden (zonder loading="lazy"-attribuut, of expliciet met loading="eager"), idealiter met fetchpriority="high". Alleen afbeeldingen onder de vouw moeten lazy-loaded worden.
6. Preload de LCP-afbeelding als het niet het eerste is wat de browser ziet
Als je LCP-afbeelding via een CSS background-image wordt geladen, of verstopt zit in een slider/carrousel die JavaScript pas na het laden van de pagina rendert, ontdekt de browser deze pas laat in het laadproces. Een <link rel="preload" as="image">-tag voor die specifieke afbeelding in de <head> vertelt de browser om deze direct op te halen, parallel aan alles andere.
7. Controleer de serverresponstijd voor de afbeelding zelf
Een correct geformatteerde WebP-afbeelding met de juiste afmetingen laadt nog steeds niet snel als deze wordt geserveerd vanaf een niet-geoptimaliseerde origin zonder cache-headers. Controleer of je afbeeldingen worden geserveerd met lange cache-levensduur (Cache-Control: max-age=31536000 voor statische assets) en overweeg een CDN als je relevant verkeer uit meerdere regio's hebt.
8. Test opnieuw na elke wijziging
Voer niet alle acht stappen gebundeld uit en test pas aan het einde. Corrigeer het formaat, test opnieuw. Corrigeer de afmetingen, test opnieuw. Zo zie je welke wijziging echt iets veranderde — handig wanneer je een site oplost waar meerdere dingen tegelijk mis zijn.
Dit op schaal doen
Elke afbeelding op een site van 50 pagina's handmatig controleren is niet realistisch. Dit is precies het gat dat de ingebouwde SEO-audit van Erdo Image Optimizer opvult — die scant elke afbeelding op je site en signaleert te grote bestanden, ontbrekende lazy-loading-attributen (en de omgekeerde fout — lazy-loaden van afbeeldingen boven de vouw), verkeerde formaten en ontbrekende alt-tekst, allemaal in één rapport.
Gecombineerd met automatische WebP/AVIF-conversie bij upload wordt het grootste deel van deze checklist een eenmalige instelling in plaats van een terugkerende handmatige controle.
Kortom
LCP-problemen voelen als een hosting- of cacheprobleem omdat dat is wat de meeste generieke "maak je site sneller"-adviezen aannemen. In de praktijk is de oplossing op een typische WordPress-site bijna altijd: het juiste formaat serveren, op de juiste grootte, geladen met de juiste prioriteit. Werk de checklist hierboven door voordat je naar een duurdere host of een server-side cachelaag grijpt — daar zit het probleem meestal niet.