De klacht is bijna altijd hetzelfde: “Mijn site voelt traag, vooral op de telefoon.” U opent de pagina, ziet een paar seconden een witte of halflege ruimte, en dan verschijnt ineens de grote foto bovenaan. Alles daarna gaat snel genoeg, maar die eerste indruk is al verpest. In Search Console heet dat een slechte LCP.

LCP verbeteren is in de meeste gevallen geen groot project. Het is een kwestie van weten welk element Google als “het grootste” ziet, en dat element vervolgens kleiner, eerder en zonder obstakels laden. Dit stappenplan loopt die volgorde af, van simpel naar technisch.

Wat LCP meet en waarom het bijna altijd een foto is

Largest Contentful Paint is het moment waarop het grootste zichtbare element in het schermdeel boven de vouw klaar is met tekenen. Op een bedrijfssite is dat in negen van de tien gevallen de headerafbeelding of de eerste afbeelding in een slider. Soms is het een groot tekstblok, en op productpagina’s is het de productfoto.

Google vindt 2,5 seconden of minder goed. Dat lijkt ruim, maar op een telefoon met een matige verbinding is een foto van 2 MB al genoeg om erboven te komen. Onthoud dit: LCP gaat niet over “de hele pagina”, maar over dat ene element. Alles wat u doet om precies dat element sneller te krijgen, telt direct mee. Wilt u eerst het bredere plaatje, lees dan de uitleg over Core Web Vitals in gewone taal.

Stap 1: vind het LCP-element van uw pagina

Ga naar PageSpeed Insights, voer uw pagina in en kies het tabblad Mobiel. Onder “Diagnose” staat een regel “Largest Contentful Paint-element”. Klik die open en u ziet een miniatuur van het element, meestal met een bestandsnaam. Dat is uw doelwit.

Doe dit voor de homepage, een dienstenpagina en, als u een webshop heeft, een productpagina. Elk pagina-type heeft vaak een ander LCP-element, en dus een andere oplossing.

Stap 2: maak het element kleiner

Dit is de stap met het grootste effect en de minste techniek. Controleer de afbeelding die u in stap 1 vond:

  1. Afmetingen. Een headerfoto hoeft niet breder te zijn dan de breedte waarop hij getoond wordt. Voor een full-width header is 1920 pixels ruim voldoende; voor een foto in een kolom vaak 800 of minder. Foto’s rechtstreeks van een camera zijn 4000 tot 6000 pixels breed.
  2. Bestandsgrootte. Een goed gecomprimeerde header van 1920 pixels breed weegt in onze ervaring 150 tot 300 KB. Zit u boven de 500 KB, dan is hier winst.
  3. Formaat. WebP is meestal 25 tot 35 procent kleiner dan JPEG bij dezelfde kwaliteit. WordPress ondersteunt WebP standaard sinds versie 5.8.

Hoe u dat in WordPress netjes regelt, zonder drie plugins over elkaar, leest u in het artikel over afbeeldingen optimaliseren voor WordPress. Voor dit stappenplan volstaat: vervang de foto door een kleinere versie en meet opnieuw.

Stap 3: zorg dat het element niet lazy laadt

Lazy loading stelt het laden van afbeeldingen uit tot ze in beeld komen. Prima voor foto’s onderaan de pagina, rampzalig voor uw LCP-element. WordPress voegt sinds versie 5.5 automatisch loading=”lazy” toe aan afbeeldingen, en slaat het eerste beeld in de inhoud weliswaar over, maar thema’s en page builders zetten het er regelmatig alsnog op.

Controleer dit door in de broncode van de pagina te zoeken naar de bestandsnaam van uw headerfoto. Staat er loading=”lazy” bij, dan moet dat eraf. In Elementor en Divi zit daar per afbeelding een instelling voor; bij een thema-header is het vaak een regel in het child-thema of een instelling in uw cacheplugin (“lazy loading uitsluiten voor de eerste N afbeeldingen”).

Stap 4: laat de browser de foto eerder ophalen

De browser ontdekt uw headerfoto pas als hij bij die regel in de HTML aankomt, of erger, pas nadat de CSS is geladen als de foto een achtergrondafbeelding is. Twee technieken helpen:

  • Preload. Een regel in de head van de pagina die zegt: haal dit bestand alvast op. Cacheplugins als WP Rocket en LiteSpeed Cache hebben hier een instelling voor; Perfmatters ook. Gebruik het alleen voor het LCP-element, niet voor tien bestanden tegelijk.
  • fetchpriority=”high”. Een attribuut op de afbeelding zelf. WordPress zet dit sinds versie 6.3 automatisch op de afbeelding die het als belangrijkste ziet, maar dat werkt niet bij achtergrondafbeeldingen in page builders.

Overweeg bij een header als CSS-achtergrond om die om te bouwen naar een gewone afbeelding. Dat klinkt als een detail, maar het scheelt vaak een halve seconde.

Stap 5: haal de blokkades vóór het element weg

Zelfs een kleine foto komt laat in beeld als de browser eerst moet wachten op stylesheets en scripts. Kijk in PageSpeed Insights bij “Renderblokkerende bronnen”. Typische verdachten: het CSS van vijf plugins die op deze pagina niet eens gebruikt worden, Google Fonts van een externe server, en trackingscripts in de head.

Wat helpt: JavaScript uitstellen (defer), niet-kritieke CSS later laden, en lettertypen lokaal hosten. Dit is het punt waar de meeste mensen zonder technische achtergrond afhaken, en dat is redelijk. Een verkeerd uitgesteld script breekt een menu of een formulier.

Stap 6: kijk naar de server

Als de server pas na een seconde begint met leveren, is uw LCP nooit onder de 2,5 seconden te krijgen, hoe klein de foto ook is. Kijk in PageSpeed Insights naar “Initiële reactietijd van de server”. Boven de 600 milliseconden is er werk aan de winkel: paginacaching aanzetten, een zwaar thema of plugin opsporen, of in het uiterste geval een betere hosting.

Stap 7: meet opnieuw, met echte bezoekers

De labtest van PageSpeed geeft een indicatie; de velddata in Search Console zijn wat Google echt gebruikt. Die worden over 28 dagen gemeten, dus verwacht geen groen balkje de dag na uw aanpassing. Noteer de labwaarde voor en na, en controleer na een maand of de velddata volgen.

Wat u zelf doet en wanneer u hulp vraagt

Stappen 1 tot en met 3 zijn voor de meeste ondernemers zelf te doen op een rustige middag. Stappen 4 tot en met 6 raken de code, de cacheplugin en de server, en daar kan een verkeerde instelling meer kapotmaken dan de winst waard is. Een eenmalige snelheidsoptimalisatie door een specialist neemt in dat geval alle stappen in één keer mee, met een back-up vooraf en een meting achteraf.

Een voorbeeld uit de praktijk: een installatiebedrijf in Apeldoorn had een LCP van 4,8 seconden op mobiel. De headerfoto bleek 3,1 MB en werd als achtergrond geladen via de page builder. Na verkleinen naar 240 KB WebP, ombouwen naar een gewone afbeelding met preload en het uitstellen van twee trackingscripts, stond de LCP in de labtest op 1,7 seconden. Het ontwerp veranderde niet.

Begin vandaag met stap 1. Als u het element kent, is de helft van het werk al gedaan.