Performance · LCP · 8 min lezen

LCP fixen 2026

Largest Contentful Paint is de #1 ranking-killer voor MKB-sites. Zeven concrete stappen om hem onder de 2.5 seconden te krijgen — ook zonder dev-team.

TL;DR LCP-doel: onder 2.5s op mobiel. Voor 80% van MKB-sites is de hero-foto het probleem. Zeven stappen: (1) identificeer het LCP-element, (2) zet om naar WebP, (3) lever in juiste dimensies via srcset, (4) preload de hero, (5) verwijder lazy-loading van de hero, (6) optimaliseer fonts, (7) check je hosting/TTFB. Realistische verbetering: van 5-7s naar 1.5-2.2s.

Wat is LCP precies?

Largest Contentful Paint = de tijd tussen het moment dat een bezoeker je URL opent en het moment dat het grootste zichtbare element compleet getoond is. Bij MKB-sites is dat element vrijwel altijd:

Google's doel: onder 2.5 seconden, op een 4G-mobiele verbinding, gemeten in het 75e percentiel van je echte bezoekers. Dat 75e percentiel is belangrijk: niet je beste meting telt, en niet je gemiddelde — drie van vier bezoekers moeten onder 2.5s zitten.

Stap 1 — identificeer je LCP-element

Voor je gaat fixen, weet wát je fixt. Open pagespeed.web.dev, analyseer je homepage, scroll naar "Largest Contentful Paint element". Daar staat exact welk HTML-element verantwoordelijk is. Meestal: <img class="hero" ...> of <h1>.

Doe dit voor je homepage én voor je top 3 landingspagina's. Soms is het LCP-element op verschillende pagina's anders, en moet je per pagina-type een andere fix toepassen.

Stap 2 — converteer naar WebP (of AVIF)

Een JPG van 800 KB wordt in WebP typisch 250-350 KB. Bij gelijke kwaliteit. Op een 4G-verbinding scheelt dat 2-3 seconden laadtijd. Tooling:

Diepere uitleg over wanneer welke: WebP vs JPG voor MKB.

Stap 3 — lever de juiste dimensies (srcset)

Tweede grote MKB-fout: één hero-foto van 2400×1600px laden op een telefoon met scherm 390px breed. Browser downloadt 2.5 MB voor iets dat 400 KB had gekund. Fix: srcset:

<img src="hero-1200.webp"
  srcset="hero-480.webp 480w,
          hero-800.webp 800w,
          hero-1200.webp 1200w,
          hero-1800.webp 1800w"
  sizes="(max-width: 640px) 100vw, 1200px"
  alt="..." width="1200" height="800" />

Browser kiest automatisch de versie die past bij scherm + verbinding. Vier varianten zijn genoeg voor MKB.

Stap 4 — preload de hero

Geef de browser een hint dat het LCP-element extra prioriteit heeft. In de <head>:

<link rel="preload" as="image"
  href="hero-1200.webp"
  imagesrcset="hero-480.webp 480w, hero-1200.webp 1200w"
  imagesizes="100vw" />

Effect: hero-afbeelding wordt parallel met CSS gedownload in plaats van erna. Typisch 300-700ms LCP-verbetering.

Stap 5 — verwijder lazy-loading van de hero

Tegenintuïtief maar belangrijk: loading="lazy" op je hero-afbeelding is een fout. Lazy-loading is voor afbeeldingen die onder de fold staan. Het hero-element moet juist zo snel mogelijk laden. Check je HTML, verwijder loading="lazy" op de hero. Laat het staan op alle andere foto's.

Een MKB-site die loading="lazy" op de hero heeft staan, verliest typisch 800ms-1.2s LCP. We zien dit in 30% van WordPress-installaties met optimalisatie-plugins die te aggressief geconfigureerd zijn.

Stap 6 — optimaliseer fonts

Als je LCP-element een tekstblok is (titel, niet afbeelding), is fonts vaak het probleem. Browser wacht tot de webfont gedownload is voor hij de titel toont. Twee fixes:

Op Google Fonts: gebruik de display=swap-parameter in de URL. Op WordPress met Elementor/Divi: zit meestal al ingebouwd, maar check 'em.

Stap 7 — check je hosting (TTFB)

Als alle bovenstaande stappen gedaan zijn en LCP nog steeds boven 3 seconden zit, kijk naar je TTFB (Time to First Byte). Dat is hoe lang je server doet over de eerste reactie. Onder 200ms = goed. Boven 600ms = je hosting is je bottleneck.

Goedkope shared hosting (€3-€7/maand) is vaak de boosdoener bij WordPress-sites met grotere traffic. Managed WordPress hosting (Kinsta, WP Engine, Cloudways) ligt €15-€25/maand maar geeft TTFB onder 200ms. Verschil in LCP: 400-1.000ms direct.

Realistische verwachting per CMS

Wat is haalbaar als je deze stappen toepast?

Wanneer optimalisatie niet meer helpt

Als je na alle 7 stappen onder PageSpeed 60 blijft en LCP boven 3.5s, is de codebase je probleem. WordPress-sites met 10 jaar opgestapelde plugins zijn niet meer te redden zonder rebuild. Een DesignCheck-rebuild garandeert Lighthouse 90+ vast — zie prijzen (€1.995-€6.995). Wat dat oplevert in euro's: vul de verliescalculator in.

LCP-audit — gratis

Wij meten je LCP op homepage + 3 hoofdpagina's, identificeren het LCP-element en sturen binnen 48 uur het concrete fix-pad.

Audit aanvragen →

fetchpriority — de onbekende attribuut die je hero versnelt

Sinds Chrome 101 en uitgerold naar 92% van browsers in 2026 bestaat er een HTML-attribuut waar je hero-afbeelding direct van profiteert: fetchpriority="high". Plaats 'em op je hero-img en de browser pakt het op met dezelfde prioriteit als CSS en kritisch JavaScript.

Het verschil met preload: preload zet een hint in de head, fetchpriority zet de prioriteit direct op het element. Beide samen leveren de beste resultaten. Voor MKB-sites die hun LCP onder 1,5 seconde willen krijgen is dit een fix van 30 seconden werk:

<img src="hero.webp"
  fetchpriority="high"
  width="1200" height="800"
  alt="..." />

Combineer met preload in de head en je hero start de download bij byte 1 van je HTML, niet pas wanneer de parser het <img>-element tegenkomt. Op trage 4G-verbindingen is dat een verschil van 400-700 ms LCP.

Render-blocking resources — de stille killer

Veel MKB-sites halen LCP niet onder 2,5 seconden ondanks WebP, srcset, preload én snelle hosting. De oorzaak in negen van de tien gevallen: render-blocking CSS en JS. Een 90 KB stylesheet bovenin je HTML pauzeert het tekenen tot hij volledig binnen is. Een synchroon script doet hetzelfde, plus het pauzeert ook de HTML-parser.

De oplossingen, ranked op impact:

Wij gebruiken bij DesignCheck-builds standaard een critical-CSS-pipeline. De build extraheert per pagina automatisch de relevante selectoren voor de boven-de-fold-content. Niemand denkt eraan op een handmatige WordPress-installatie, en het is precies waar 0,5-1,0 seconde LCP-winst zit.

De rol van TTFB en hosting — dieper bekeken

TTFB is de eerste byte HTML die bij de browser binnenkomt. Op shared hosting met PHP en MySQL voor een dynamische WordPress-site zit dit vaak op 800-1.500 ms. De server moet de databasequery uitvoeren, PHP renderen, het resultaat sturen. Bij elke pageview opnieuw.

Drie aanpakken om TTFB te verlagen:

Bij Keurmeesters (NL energielabel-bureau) hebben we voor de derde aanpak gekozen. De BAG-API-call gebeurt server-side bij elke aanvraag, maar de site-shell is statisch. Resultaat: TTFB 67 ms gemiddeld over 30 dagen, LCP 1,1 seconde, Lighthouse 96/100/100/100 op mobiel. Geen caching-plugin nodig, geen managed hosting-kosten, geen onderhoud aan de hosting-laag.

LCP per pagina-type — wat je per template moet checken

Een MKB-site heeft meerdere pagina-types. Per type is het LCP-element anders en vraagt het andere fixes:

Per pagina-type één keer instellen, en je hele site profiteert. Een goed CMS-template-systeem zorgt dat je dit één keer doet en alle nieuwe pagina's automatisch goede patterns erven. Op de meeste WordPress-installaties moet je per templatebestand (.php) handmatig de img-tag aanpassen — dat is omslachtig maar haalbaar. Op Astro of Next.js zit het in één component dat overal hergebruikt wordt.

Complete LCP-checklist — 12 stappen voor MKB

  1. Open PageSpeed Insights op je belangrijkste pagina (mobiel). Noteer veld-LCP en lab-LCP.
  2. Identificeer het LCP-element in de Diagnostics-sectie. Schrijf op of het een img, h1 of background-image is.
  3. Bij img-LCP: converteer naar WebP op quality 82, schaal naar maximaal 2x display-grootte.
  4. Genereer 4 srcset-varianten: 480w, 800w, 1200w, 1800w. Voeg sizes-attribuut toe.
  5. Voeg fetchpriority="high" toe aan het hero-element.
  6. Voeg preload-hint toe in de head voor het hero-bestand.
  7. Verwijder loading="lazy" van het LCP-element. Laat 'em staan op alles eronder.
  8. Bij tekst-LCP: preload je primaire font, voeg font-display: swap toe.
  9. Inline critical CSS in de head. Async-laad de rest.
  10. Voeg defer aan elke externe script die niet kritiek is voor de eerste render.
  11. Check je TTFB via webpagetest.org. Boven 600 ms? Activeer caching-plugin of upgrade hosting.
  12. Run Lighthouse opnieuw. Wacht 28 dagen voor veld-data om bij te trekken.

Wat een LCP-rebuild oplevert in cijfers

Klanten op een DesignCheck-rebuild starten typisch op LCP 4,5-7,2 seconden (lab, mobiel). Na rebuild zit dat op 0,9-1,8 seconden. Geen halve seconde verbetering — een factor 3-7 sneller.

Wat dat oplevert in business-termen, gebaseerd op onze audit-cohort van de afgelopen 12 maanden:

Het rebuild-pakket dat hier achter zit (€1.995 starter, €3.995 groei, €6.995 premium) verdient zichzelf bij de meeste MKB-sites terug binnen 4-8 weken. De verliescalculator op designcheck.nl/verliescalculator rekent dit door op je eigen bezoekers- en omzet-cijfers. Wereldwijd beschikbaar voor remote-projecten, op locatie binnen De Ronde Venen.

Hoe LCP zich verhoudt tot de andere Core Web Vitals

LCP is zelden geïsoleerd op een MKB-site. Sites met trage LCP hebben vrijwel altijd ook CLS of INP-problemen. Dat is geen toeval — de onderliggende oorzaken overlappen.

Een ongeoptimaliseerde hero-afbeelding veroorzaakt LCP (te traag laden) én CLS (verspringt content als hij binnenkomt). Een zware JavaScript-bundle veroorzaakt LCP (blokkeert paint) én INP (blokkeert interactie). Tijd in je hosting kost LCP én INP omdat alles vanaf het eerste byte vertraagd binnen druppelt.

Praktisch betekent dit: een goede LCP-fix lost vaak meerdere problemen tegelijk op. Een hero-afbeelding die je WebP-tet, met width/height attribueert, met fetchpriority hoog zet — die verbetert LCP, CLS én vaak ook overall page-weight (en daarmee indirect INP). Eén fix, drie metrieken verbeterd.

De volgorde die wij hanteren bij audits: eerst LCP fixen (omdat het de zwaarste impact heeft op gebruikers en het breedste effect), dan CLS (omdat het direct conversie-impact heeft), dan INP (omdat het de meeste tijd kost om grondig te fixen). Drie weken werk voor een typische MKB-site die alle drie de drempels haalt.

Wanneer LCP onder 1 seconde haalbaar is

Veel optimalisatie-gidsen stoppen bij "onder 2,5 seconden". Voor MKB-sites die echt willen excelleren is sub-1-seconde-LCP haalbaar. Niet op WordPress met Elementor — wel op moderne stacks.

De combinatie die nodig is: edge-hosting (Vercel, Cloudflare Pages, Netlify), static site generation (Astro of Next.js in static mode), HTTP/3 of HTTP/2, brotli-compressie, WebP of AVIF voor afbeeldingen, geen render-blocking resources, geen third-party scripts in de critical path, en preload-hints voor de hero. Met deze stack zit LCP standaard tussen 0,7 en 1,2 seconde.

Op Keurmeesters draait deze full-stack. Veld-LCP gemiddeld 0,9 seconde over 30 dagen. Dat is niet alleen "groen" in PageSpeed — het is een ervaring waar bezoekers niet eens registreren dat de site iets laadde. Ze zien de pagina, ze beginnen direct te lezen of klikken. Snelheid wordt vanzelfsprekend.

Voor wie dit niveau wil voor zijn eigen site is het gesprek met DesignCheck eenvoudig: rebuild op Astro of vergelijkbare stack, hosting op Vercel, image-pipeline ingebouwd, real-user monitoring aan. Pakket-prijs €3.995 (groei) of €6.995 (premium) afhankelijk van scope. Verdient zichzelf bij de meeste MKB-sites terug binnen het kwartaal.

Wat doe je vandaag?

Open je site op je telefoon. Tik op de Chrome-knop links, kies "Tap to test page speed" (of open pagespeed.web.dev op je laptop en plak je URL). Wacht op het rapport. Scroll naar het LCP-element en lees welk HTML-element verantwoordelijk is. Is het een img? Open de bron, kopieer de URL, sleep 'em naar squoosh.app, exporteer als WebP op quality 82, vervang. Voeg fetchpriority="high" toe in de HTML, en een preload-hint in de head. Drie stappen, 20 minuten werk. Meet morgen opnieuw — je LCP zit waarschijnlijk 0,8-1,5 seconde lager. Eén concrete fix vandaag is meer waard dan een week plannen maken.

Gerelateerde gidsen

FAQ — LCP fixen

Wat is een goede LCP?
Onder 2.5 seconden op mobiel = goed. 2.5-4s = matig. Boven 4s = slecht en Google straft je structureel.
Hoe identificeer ik het LCP-element?
Open pagespeed.web.dev, analyseer je pagina, scroll naar "Largest Contentful Paint element". Of in Chrome DevTools: Performance-tab → record → refresh → stop → zoek de oranje LCP-marker.
Werkt dit ook op WordPress zonder dev?
Ja, stappen 1-4 kun je zelf doen met plugins zoals ShortPixel (WebP) en WP Rocket (preload). Stappen 5-6 vragen lichte HTML-aanpassingen. Stap 7 (hosting) hoef je alleen bij te springen als de rest niet helpt.
Hoe lang voordat ik resultaat zie in ranking?
Lab-data (Lighthouse) direct. Veld-data (Search Console) na ~28 dagen, want Google werkt met een rolling 28-day window. Ranking-effect 1-3 maanden later.
Wat is fetchpriority en wanneer gebruik ik 'em?
Fetchpriority=high is een HTML-attribuut dat de browser vertelt deze resource prioritair op te halen. Plaats het op je hero-afbeelding voor 100-300 ms snellere LCP. Werkt in 92% van browsers per 2026.
Helpt een CDN echt mijn LCP?
Voor sites met internationaal verkeer of buiten een groot stadsknooppunt: ja, 300-600 ms winst. Voor lokale NL-MKB met bezoekers binnen 100 km van de server: marginaal, 50-150 ms.
Wat is render-blocking en hoe los ik dat op?
Render-blocking CSS of JS pauzeert het tekenen van de pagina tot het bestand binnen en geparsed is. Inline critical CSS in de head, voeg defer/async toe aan scripts, splits grote stylesheets. Elk render-blocking bestand kost typisch 200-500 ms LCP.

Door Lorenzo Ruisi — DesignCheck. Laatst bijgewerkt 16 mei 2026.

Zit jouw LCP onder 2.5s?

De gratis audit meet 'em en stuurt het concrete fix-pad binnen 48 uur.

Site checken →