Wat LCP precies meet
LCP staat voor Largest Contentful Paint. Het meet hoe lang het duurt voordat het grootste zichtbare element in het venster is geladen. Dat is meestal een hero-afbeelding, een grote kop of een blok tekst boven de vouw. Kortom: het moment waarop de bezoeker het gevoel heeft dat de pagina er staat.
LCP is een van de drie Core Web Vitals, naast CLS (layout-verschuiving) en INP (reactiesnelheid). Google gebruikt deze meetwaarden als rankingsignaal. De grenswaarden voor LCP zijn duidelijk: onder 2,5 seconde is goed (groen), tussen 2,5 en 4 seconde is matig (oranje), boven 4 seconde is slecht (rood).
Waarom LCP zo belangrijk is: het correleert sterk met hoe snel een bezoeker de pagina ervaart. Een trage LCP betekent dat mensen naar een lege of half-geladen pagina staren, en dat is precies het moment waarop ze wegklikken. Snelheid verbeteren is dus geen technisch feestje maar direct verbonden met conversie.
Meet eerst, raad niet
Voordat je iets aanpast, moet je weten wat je LCP-element is en waar de vertraging zit. Anders optimaliseer je op de gok. Gebruik PageSpeed Insights: het wijst het LCP-element aan en laat zien hoe de laadtijd is opgebouwd.
PageSpeed Insights splitst de LCP op in vier fasen: de tijd tot de eerste byte van de server (TTFB), de vertraging voordat de bron begint te laden, de laadtijd van de bron zelf, en de tijd tot het renderen. Zo zie je waar je moet ingrijpen: is het de server, de afbeelding, of het renderen?
Belangrijk onderscheid: er is labdata (een gesimuleerde test) en velddata (echte bezoekers, via de Chrome UX Report). Velddata telt voor je ranking. Optimaliseer dus niet alleen voor een mooie labscore, maar controleer of echte bezoekers de winst ook voelen.
Verbetering 1 tot 2: de server en caching
De LCP begint bij de server. Als het lang duurt voordat de eerste byte binnenkomt, loopt alles daarna achter. Deze twee verbeteringen pakken de fundering aan.
1. Snellere hosting
Een trage server geeft een hoge TTFB, en dat vertraagt je LCP direct. Goede LiteSpeed-hosting met server-side caching brengt de TTFB vaak van 600 tot 800 milliseconde terug naar onder de 200. Dit is de fundering: geen enkele plugin compenseert een trage server volledig.
2. Page caching
Caching slaat een kant-en-klare versie van je pagina op, zodat WordPress en PHP niet bij elke bezoeker opnieuw hoeven te draaien. Op LiteSpeed gebruik je daarvoor de gratis LiteSpeed Cache-plugin. Dit alleen al scheelt vaak honderden milliseconden.
Verbetering 3 tot 5: de afbeeldingen
In de meeste gevallen is het LCP-element een afbeelding: de grote hero bovenaan de pagina. Grote, onbewerkte afbeeldingen zijn daarom de meest voorkomende oorzaak van een trage LCP. Deze drie ingrepen maken vaak het grootste verschil.
- 3. Comprimeer en verklein je afbeeldingen. Een hero van 2 MB is nergens voor nodig. Verklein tot de weergavegrootte en comprimeer. Vaak gaat een afbeelding van 2 MB naar onder de 200 KB zonder zichtbaar kwaliteitsverlies.
- 4. Gebruik moderne formaten zoals WebP. WebP is 25 tot 35 procent kleiner dan JPEG bij dezelfde kwaliteit. De meeste browsers ondersteunen het inmiddels.
- 5. Laad het LCP-element niet lazy. Lazy loading is goed voor afbeeldingen onder de vouw, maar juist funest voor je hero-afbeelding. Zet lazy loading uit voor het LCP-element, anders wacht de browser onnodig.
Verbetering 6 tot 7: CSS en JavaScript
Zelfs met een snelle server en lichte afbeeldingen kan je LCP traag zijn als de browser eerst zware CSS en JavaScript moet verwerken voordat hij kan renderen. Dat heet render-blokkering.
6. Verminder render-blokkerende bestanden
Grote CSS- en JS-bestanden die bovenaan laden, houden het renderen tegen. Minificeer ze, stel niet-kritieke scripts uit (defer of async) en zet de kritieke CSS inline. De LiteSpeed Cache-plugin kan veel hiervan automatisch.
7. Ruim overbodige scripts op
Veel WordPress-sites laden scripts van plugins die op de meeste pagina's niet nodig zijn (denk aan een slider die er niet staat, of een formulier-plugin op elke pagina). Elk script dat je verwijdert of gericht laadt, versnelt de pagina. Minder is bijna altijd sneller.
Verbetering 8: preload het belangrijkste
De laatste ingreep is een gerichte: vertel de browser expliciet dat hij het LCP-element met voorrang moet laden. Met een preload-hint in de HTML begint de browser de hero-afbeelding op te halen voordat hij de rest van de pagina heeft verwerkt.
Dit is subtiel maar effectief: preloading van de LCP-afbeelding kan de laadtijd van dat element merkbaar vervroegen, vaak enkele honderden milliseconden. Combineer het met het uitzetten van lazy loading op datzelfde element voor het beste resultaat.
Let op: preload alleen wat echt kritiek is. Als je te veel bestanden preloadt, concurreren ze om bandbreedte en werk je jezelf tegen. Een preload is een voorrangsregel, en die werkt alleen als je hem spaarzaam gebruikt.
De grootste fout bij LCP-optimalisatie is overal tegelijk aan sleutelen. Meet eerst wat je LCP-element is, pak de grootste blokkade aan, meet opnieuw. Een gerichte ingreep verslaat tien gokjes.
Rekenvoorbeeld: van 4,2 naar 2,0 seconde
Neem een WordPress-site met een LCP van 4,2 seconde: rood in PageSpeed Insights. PageSpeed wijst de hero-afbeelding aan als LCP-element. We pakken het stapsgewijs aan.
Server en caching: verhuizing naar LiteSpeed met caching brengt de TTFB van 700 naar 200 milliseconde. Winst: circa 0,5 seconde.
Afbeelding: de hero van 1,8 MB JPEG wordt een 180 KB WebP, en lazy loading wordt uitgezet voor dit element. Winst: circa 1,1 seconde.
Render-blokkering: kritieke CSS inline, niet-kritieke JS uitgesteld. Winst: circa 0,4 seconde.
Preload: de hero-afbeelding krijgt een preload-hint. Winst: circa 0,2 seconde.
Resultaat: 4,2 min ongeveer 2,2 seconde aan verbeteringen brengt de LCP naar circa 2,0 seconde, ruim binnen de groene zone. Dit is een realistische, geen gegarandeerde uitkomst: hoeveel je precies wint hangt af van je thema en plugins. Maar de volgorde (server, afbeelding, code, preload) klopt vrijwel altijd.
Onderhoud: LCP blijft werk
Een goede LCP is geen eenmalige klus. Elke keer dat je een nieuwe zware plugin installeert, een grote afbeelding uploadt of je thema aanpast, kan je LCP weer omhoog kruipen. Meet daarom periodiek, bijvoorbeeld elk kwartaal, of na elke grote wijziging.
Voor de meeste MKB'ers is de eerlijke aanpak: leg de basis goed (snelle hosting, caching, geoptimaliseerde afbeeldingen), en check daarna een paar keer per jaar of het nog klopt. Zo voorkom je dat je site langzaam weer traag wordt zonder dat je het merkt.
Wil je weten wat jouw LCP nu is en waar de grootste winst zit? Onze site-check meet je Core Web Vitals en wijst de concrete verbeterpunten aan, van hetzelfde team dat je hosting kan draaien.