Core Web Vitals verbeteren: LCP, INP en CLS aanpakken

Core Web Vitals verbeteren doe je metric per metric, niet met één instelling.

Je versnelt het laden (LCP), je maakt de pagina reactiever (INP) en je houdt de layout stabiel (CLS).

Het verdict: elke metric heeft eigen oorzaken en eigen fixes. Begin bij de metric die op je belangrijkste pagina’s in het rood staat, niet bij een perfecte score.

Hieronder per metric wat je concreet aanpakt, hoe je controleert of het werkt, en in welke volgorde je dat best doet.

Zo heeft het effect op je leads en niet alleen op een cijfer.

Wil je eerst weten wat LCP, INP en CLS precies meten en waarom Google ze meeweegt? Lees dan onze uitleg over wat Core Web Vitals zijn. Hier gaan we meteen naar de oplossingen.

Wat zijn de drempelwaarden waar je naartoe werkt?

Een LCP onder 2,5 seconden, een INP onder 200 milliseconden en een CLS onder 0,1.

Dat zijn de grenzen die Google als “goed” bestempelt (web.dev).

Een pagina slaagt pas als ze alle drie haalt.

Wat elke metric meet

• LCP (Largest Contentful Paint): hoe snel het grootste contentblok in beeld komt, meestal je hero-afbeelding of een grote kop.
• INP (Interaction to Next Paint): hoe snel je pagina reageert als iemand klikt, tikt of typt.
• CLS (Cumulative Layout Shift): hoeveel de layout verspringt tijdens het laden.

INP is sinds 2024 de officiële maatstaf voor reactiesnelheid. Op 12 maart 2024 verving het de oudere FID-metric.

Het 75e percentiel

Google beoordeelt deze cijfers op het 75e percentiel van je paginaladingen, apart voor mobiel en desktop, op basis van echte bezoekersdata.

Anders gezegd: minstens driekwart van de paginaladingen moet een goede score halen.

Google raadt aan dat apart te meten voor mobiel en desktop.

Een mooie labmeting op jouw snelle laptop zegt dus weinig.

Het gaat om wat je publiek op een gemiddeld toestel en verbinding ervaart.

Zo ziet dat er in de praktijk uit

Kijk in PageSpeed Insights eerst naar het blok met velddata.

Bij onze eigen site is LCP goed, maar faalt de beoordeling op CLS:

Onze eigen mobiele velddata in PageSpeed Insights, oktober 2026. LCP is goed (1,9 s), maar één zwak meetpunt (CLS 0,13) laat de beoordeling falen.

Les: één metric in het oranje volstaat om te falen.

Hoe verbeter je je LCP?

Door je grootste, eerst zichtbare element lichter en sneller te maken.

In de praktijk is dat bijna altijd een afbeelding, of een zwaar laadproces dat ervoor in de weg zit.

Waar de tijd naartoe gaat

Google deelt LCP op in vier deeltijden.

Volgens web.dev over LCP optimaliseren ziet een gezonde verdeling er ongeveer zo uit:

Zie je in PageSpeed Insights een hoge render delay of een lange wachttijd op de server?

Dan weet je meteen waar je moet zoeken:

LCP-opsplitsing in PageSpeed Insights voor een van onze eigen artikels, labtest op mobiel, oktober 2026. Hoge TTFB wijst op de server, hoge render delay op CSS en scripts.

Vier fixes, in volgorde van impact

1. Comprimeer je afbeeldingen en gebruik moderne formaten zoals WebP of AVIF.

Een hero-afbeelding van enkele megabytes is een klassieke LCP-moordenaar.

Geef beelden ook de juiste afmetingen mee, in plaats van een groot bestand kleiner te schalen in de browser.

2. Zorg voor snelle hosting en een CDN.

Een trage server laat de browser wachten voor er ook maar iets verschijnt. Hosting dicht bij je publiek, in dit geval doorgaans Europa, scheelt merkbaar. Meer daarover in hosting en snelheid voor SEO.

3. Laad je belangrijkste afbeelding met voorrang.

Met technieken als preloaden vertel je de browser dat dit beeld er eerst moet zijn.

Web.dev raadt fetchpriority="high" aan op het waarschijnlijke LCP-beeld, maar op hooguit één of twee beelden.

Lazy loading hoort net niet thuis op je hero, want dan stel je uit wat je nodig hebt.

4. Beperk wat de pagina blokkeert.

Zware lettertypes, externe scripts en onnodige CSS die eerst moet inladen, vertragen het moment waarop je content zichtbaar wordt.

Hoe minder de browser moet doen voor de eerste weergave, hoe beter.

Bij de bouw is het goedkoper

Veel van deze winst is technisch werk onder de motorkap.

Het loont om dit goed te doen bij de bouw of bij een website redesign.

Achteraf bijsturen kost altijd meer.

Draai je op WordPress, lees dan ook een trage WordPress-site sneller maken.

Hoe maak je je INP beter?

Door de hoeveelheid en de zwaarte van JavaScript terug te dringen.

Zo is de pagina vrij om snel op een klik te reageren.

Een trage INP voelt aan als een knop die niet reageert, waarna je geïrriteerd nog eens klikt.

Wat het verschil maakt

1. Snoei in scripts van derden.

Denk aan trackers, chatwidgets, A/B-testtools en marketingpixels. Ze stapelen op en houden de hoofdthread bezig.

Schrap wat je niet echt gebruikt en laad de rest uitgesteld.

2. Splits zwaar werk op.

Lange, ononderbroken stukken JavaScript blokkeren elke reactie.

Door taken op te delen, geef je de browser ruimte om tussendoor op interacties te reageren.

3. Wees kritisch op zware paginabouwers en plugins.

Vooral op WordPress kan een opeenstapeling van plugins en een zware thema-builder je INP onderuithalen.

Vuistregel: minder is hier vaak sneller.

4. Houd formulieren licht.

Je contact- en offerteformulieren zijn precies de plekken waar interactie telt.

Een formulier dat hapert op het moment dat iemand wil versturen, kost je rechtstreeks een lead.

Hoe je dat formulier ook inhoudelijk lichter maakt, lees je in je leadformulier optimaliseren.

Waarom INP het gevoel bepaalt

INP is de metric die het sterkst samenhangt met hoe “snappy” je site aanvoelt.

Een pagina die meteen reageert, houdt mensen in de flow naar je conversiepunt.

Voorbeeld: stel, je offerteformulier laadt een chatwidget, een heatmap-script en twee pixels mee. Elke tik op een veld moet dan wachten tot die scripts klaar zijn.

Kort: elk script op je formulierpagina moet zijn plek verdienen.

Hoe los je CLS op?

Door alles wat ruimte inneemt op voorhand een vaste plek te geven.

Zo verspringt er niets terwijl de pagina inlaadt.

Verspringende content is irritant en kost soms letterlijk een verkeerde klik.

De vier meest voorkomende oorzaken

1. Beeld zonder vaste afmetingen.

Geef elke afbeelding en video een vaste breedte en hoogte mee, zodat de browser de ruimte reserveert voor het beeld er is.

Dit is veruit de meest voorkomende bron van layout shift.

2. Advertenties, embeds en banners.

Reserveer een vast blok voor content die later inlaadt, bijvoorbeeld een ingesloten kaart, video of cookiemelding.

Zo duwt die niets naar beneden.

3. Lettertypes die laat inladen.

Wanneer een webfont pas later verschijnt en de tekst herschikt, springt je layout.

Door fonts slim te laden en een goede terugvalstijl te kiezen, beperk je dat.

4. Content die bovenaan wordt ingeschoven.

Een melding of balk die plots boven je content verschijnt, duwt alles weg.

Plan daar ruimte voor in plaats van het erbovenop te schuiven.

Goedkoop, maar vaak vergeten

CLS is meestal de goedkoopste van de drie om te repareren. De fixes zijn vaak klein en lokaal.

Toch wordt hij vaak vergeten, juist omdat het op een snelle ontwikkelmachine nauwelijks opvalt.

Ook wij zien dat in onze eigen Search Console. Het probleem zit daar in layoutverschuiving op mobiel:

Het Core Web Vitals-rapport in onze eigen Search Console, oktober 2026. Het probleem zit in layoutverschuiving, niet in het platform.

Les: 349 URL’s met hetzelfde probleem wijzen vaak op één gedeeld sjabloon.

Eén fix in dat sjabloon lost ze dan samen op.

Hoe controleer je of je verbeteringen werken?

Meet vooraf en achteraf, en kijk naar je echte bezoekers, niet enkel naar een labtest.

Anders verbeter je een cijfer dat je publiek nooit te zien krijgt.

Velddata en labdata samen

In de praktijk gebruik je twee soorten bronnen samen:

• Veldgegevens (echte bezoekers): Search Console toont de Core Web Vitals voor je hele site, met de URL’s die aandacht vragen. Dit is je waarheidsbron.
• Labgegevens (diagnose): PageSpeed Insights en Google Lighthouse draaien een test in een gesimuleerde omgeving.

Labtests zijn handig om te zien wat een pagina vertraagt.

Maar de cijfers schommelen en zijn een diagnose, geen eindoordeel.

Hoe Search Console groepeert en valideert

Search Console groepeert URL’s met een vergelijkbare ervaring en geeft elke groep één status (Search Console Help).

Na een fix klik je op validatie starten. Dan volgt Google het probleem 28 dagen lang. Pas als het in die periode nergens meer opduikt, geldt het als opgelost.

Een werkwijze in drie stappen

1. Meet de huidige stand.
2. Voer één fix door.
3. Kijk na een paar weken in Search Console of je veldscores meebewegen.

Veldgegevens lopen wat achter omdat ze over een periode worden opgebouwd.

Verwacht dus niet meteen na het deployen een ander cijfer.

Welke fix pak je eerst aan?

De metric die op je belangrijkste pagina’s het verst van de drempel zit en de meeste bezoekers raakt.

Niet wat technisch het leukst is om op te lossen.

Een volgorde in drie stappen

1. Kijk welke pagina’s verkeer en leads opleveren. Je homepage, je belangrijkste website laten maken en je sterkste landingspagina’s wegen zwaarder dan een diep weggestopte blogpost.
2. Pak daar de metric aan die in het rood staat. Staat je LCP op vier seconden, dan levert beeldcompressie meer op dan een laatste CLS-detail.
3. Doe de goedkope wins mee. Vaste afmetingen voor beeld en een paar overbodige scripts schrappen kosten weinig en helpen direct.

Voor je homepage loont het dubbel. Waarom, lees je in de B2B-homepage die converteert. Betaal je voor verkeer, dan telt snelheid ook in Google Ads, zie landingspaginasnelheid en kwaliteitsscore.

Jaag geen perfecte scores na

Een pagina van 100 op 100 die niemand naar je formulier leidt, levert niets op.

Het doel is dat bezoekers blijven, vlot doorklikken en converteren. Snelheid is daarin een hefboom, geen eindstreep.

Hoe snelheid en conversie samenhangen, lees je in de impact van paginasnelheid op SEO en conversie.

De korte samenvatting

Core Web Vitals verbeter je per metric:

• LCP: lichtere afbeeldingen en snelle hosting.
• INP: minder en lichter JavaScript.
• CLS: vaste afmetingen, zodat niets verspringt.

Werk vanuit echte bezoekersdata in Search Console, gebruik labtools voor diagnose, en begin bij de pagina’s en metrics die het meeste verkeer en de meeste leads raken.

Zo wordt een snellere site geen doel op zich, maar een directe manier om meer bezoekers om te zetten.

Scoren je Core Web Vitals slecht en wil je weten waar de echte winst zit? Wij brengen in kaart wat je site vertraagt en lossen het op bij de wortel. Snelheid bewaken we daarna in ons website-onderhoud. Neem contact op en je hoort waar je kansen liggen.