LCP verbeteren: van trage hero naar groene score

Kleurt LCP oranje of rood in PageSpeed Insights, dan laadt het grootste zichtbare element te traag en voelt je hele site log aan. Hieronder spoor je het LCP-element op, herleid je de vertraging naar de oorzaak en werk je die weg met stappen die op elke WordPress-site toepasbaar zijn.

Zo vind je je LCP-element en je startpunt

LCP staat voor Largest Contentful Paint: het moment waarop het grootste zichtbare element boven de vouw op het scherm staat. Dat element is meestal een hero-afbeelding, een videoposter, een CSS-achtergrondafbeelding of een groot tekstblok zoals je paginatitel.

Test je pagina in PageSpeed Insights en kijk eerst naar de velddata: metingen van echte Chrome-bezoekers. Google beoordeelt op het 75e percentiel, met deze drempels:

Scroll daarna in het rapport naar de diagnose over het Largest Contentful Paint-element: daar staat exact welk element je score bepaalt. Controleer meerdere paginatypes, want op je homepage is het LCP-element vaak een ander dan op een product- of blogpagina.

Optimaliseer het LCP-element zelf

Is het LCP-element een afbeelding, doorloop dan deze vier stappen:

1. Schaal naar het weergaveformaat. Upload geen foto van 4000 pixels breed voor een kader van 1200 pixels. Gebruik srcset zodat mobiele bezoekers een kleinere variant krijgen.
2. Converteer naar WebP of AVIF. Die formaten zijn bij gelijke kwaliteit fors kleiner dan JPG of PNG.
3. Geef laadprioriteit. Met fetchpriority="high" haalt de browser deze afbeelding vóór al het andere op.
4. Haal lazy loading eraf. loading="lazy" op de hero stelt het laden juist uit en is een van de meest voorkomende LCP-killers.

<img src="hero.webp" width="1200" height="600" fetchpriority="high" alt="Beschrijving">

Is het LCP-element een tekstblok, dan is je webfont meestal de vertragende factor. Host fonts lokaal, beperk het aantal varianten en gebruik font-display: swap, zodat de tekst direct in een systeemfont verschijnt terwijl het webfont laadt.

Verlaag de responstijd van je server

De browser kan pas iets tonen zodra je server de HTML heeft geleverd. Een trage serverresponstijd schuift je hele LCP naar achteren, hoe goed je afbeelding ook geoptimaliseerd is. De grootste verbeteringen:

• Paginacaching: lever een kant-en-klaar HTML-bestand in plaats van elke pagina opnieuw op te bouwen uit de database.
• Actuele PHP-versie: nieuwere versies verwerken WordPress-code aanzienlijk sneller; omzetten kan meestal in je hostingpaneel.
• Hosting die past bij je bezoekersaantallen: een overvol gedeeld pakket blijft traag, wat je verder ook optimaliseert.
• CDN: serveert je bestanden vanaf een locatie dicht bij de bezoeker en vangt pieken op.

Een praktische vuistregel: blijft de responstijd in je metingen ruim boven een halve seconde hangen, los dat dan eerst op voordat je aan de rest sleutelt.

Ruim render-blokkerende bestanden op

CSS in de kop van je pagina blokkeert het renderen tot alle stylesheets binnen zijn, en JavaScript zonder defer doet hetzelfde. Elke onnodige kilobyte staat dus letterlijk tussen je bezoeker en je hero in.

• Verwijder plugins die op elke pagina eigen CSS en JavaScript laden terwijl je ze maar op één plek gebruikt.
• Laad scripts met defer, zodat de browser eerst rendert en daarna pas scripts uitvoert.
• Genereer critical CSS: het kleine stukje opmaak voor het zichtbare deel gaat inline mee in de HTML, de rest laadt later. Veel optimalisatieplugins hebben hier een kant-en-klare functie voor.

LCP in Elementor en andere pagebuilders

Pagebuilders bouwen hero-secties vaak met een CSS-achtergrondafbeelding in plaats van een los afbeeldingselement. De browser ontdekt zo'n achtergrond pas nadat de CSS verwerkt is, begint daardoor laat met laden en je LCP loopt op.

• Gebruik waar mogelijk een afbeeldingswidget in plaats van een sectie-achtergrond; een echt img-element kan prioriteit krijgen.
• Lukt dat niet, voeg dan een preload toe voor de achtergrondafbeelding, zodat de browser hem direct ophaalt.
• Zet ongebruikte widgets en addons uit; die laden anders met CSS en JavaScript op elke pagina mee.

Werk je met Elementor, dan kun je deze handmatige optimalisaties combineren met automatische bewaking: bekijk hoe ViRank naast Elementor werkt.

Veelgemaakte fouten bij LCP-optimalisatie

• De hero lazy loaden. Optimalisatieplugins zetten lazy loading soms op álle afbeeldingen. Fix: sluit het LCP-element altijd uit van lazy loading.
• Alles preloaden. Tien preloads verdringen elkaar, waardoor het prioriteitsvoordeel verdampt. Fix: preload alleen het LCP-element en hooguit je belangrijkste font.
• Alleen in de labtest kijken. Je eigen browser heeft de pagina gecachet en je zit op snelle wifi, dus voor jou voelt alles vlot. Fix: beoordeel op velddata en test op een mobiel profiel.
• Een slider als hero gebruiken. Sliderscripts laden traag en elke wissel kan een nieuw LCP-element opleveren. Fix: kies één statische afbeelding met een duidelijke boodschap.
• Verwijzen naar een verwijderde afbeelding. Na een opruimactie wijst de hero soms naar een bestand dat niet meer bestaat: de server geeft een foutmelding terug en de bezoeker kijkt naar een leeg vlak. Wat er dan precies gebeurt, lees je in de uitleg over de 404-pagina. Fix: controleer na elke mediaschoonmaak of je hero's nog laden.

Wat ViRank hierbij doet

Een rode LCP staat zelden op zichzelf: dezelfde PageSpeed-test die jouw trage hero vindt, vindt meestal ook zware scripts en ontbrekende caching. ViRank meet op het scherm Techniek je snelheid en Core Web Vitals, geeft bij elk gevonden punt een oplossingsrichting en zet de punten op volgorde van impact, zodat je weet waar je begint. De verbeteringen zelf voer je door in je hosting, thema of optimalisatieplugin, want snelheidsaanpassingen voert ViRank niet uit. Start de gratis proefperiode van 14 dagen, zonder creditcard: na de eerste analyse zie je je Findability Score en je kansen.

Veelgestelde vragen