Contact

Core Web Vitals SEO: waarom snelheid telt, maar niet als enige factor

door | sep 29, 2026 | SEO | 0 Reacties

Laadtijd van webpagina op tablet

Core Web Vitals horen bij Google’s page experience-signalen en tellen mee in rankingsystemen, maar goede scores garanderen geen hogere positie. Verbeter LCP, INP en CLS dus primair voor je bezoekers, niet om een score groen te krijgen. Gebruik field-data om te bepalen waar de winst echt zit, want dat is de plek waar tijd besteden loont.

Kort samengevat:

  • Verbeter eerst de server en het netwerk door caching, CDN en compressie toe te passen, omdat dit grote invloed heeft op alle Core Web Vitals.
  • Focus op de kritieke renderingpad door laadtaken zoals preload en inline CSS te optimaliseren, want hier wint je vooral op LCP.
  • Optimaliseer afbeeldingen door compressie en juiste formaten, en let op dat lazy loading niet de LCP-elementen vertraagt.
  • Structureer je scripts door lange taken te splitsen en web workers te gebruiken, zodat de interactietijd binnen de 200 milliseconden blijft.
  • Gebruik field-data uit Google’s rapportages om prioriteiten te stellen en test verbeteringen continu met realistische gebruikerssituaties.
Nebber
nebber.nl
Maak technische SEO praktisch
Nebber combineert technische optimalisatie met strategisch SEO-advies om organisch verkeer en zichtbaarheid voor bedrijven te verbeteren.

Bekijk Nebber

Inhoudsopgave

Wat meten LCP, INP en CLS precies?

Drie metrics, drie soorten pijn voor de bezoeker. LCP (Largest Contentful Paint) meet hoe lang het duurt voordat het grootste zichtbare element op het scherm staat, meestal een hero-afbeelding of kop. Zie het als de tijd die het duurt voordat je de voordeur openzwaait: te lang wachten en de bezoeker staat alweer bij de buren.

INP (Interaction to Next Paint) meet de vertraging tussen een klik of tik en de zichtbare reactie van de pagina. Een trage INP voelt als een kraan die je opendraait en waar het water pas na een paar seconden komt: de actie is er, de reactie hapert.

CLS (Cumulative Layout Shift) meet hoeveel de pagina visueel verspringt tijdens het laden. Elke ongeplande verschuiving is een verzetje van de vloer onder de voeten van je bezoeker.

De streefwaarden liggen vast: LCP hoort op 2,5 seconden of minder te zitten, INP op 200 milliseconden of minder, en CLS op 0,1 of lager, gemeten op het 75e percentiel van je bezoekers, Web. Google labelt URL-groepen vervolgens als Good, Need improvement of Poor op basis van die drempels, zoals te zien is in het Core Web Vitals-rapport in Search Console.

Drempelwaarden voor LCP, INP en CLS

Waarom Core Web Vitals wel meetellen, maar niet de motor van SEO zijn

Google gebruikt Core Web Vitals als onderdeel van de rankingsystemen, maar zegt zelf dat een perfecte score geen garantie is voor een hogere positie, zoals Search Central documenteert. Dat is geen vrijbrief om de metrics te negeren. Het is een waarschuwing tegen tunnelvisie.

Google adviseert om page experience breed te bekijken: naast Core Web Vitals spelen mobiele bruikbaarheid, HTTPS en het ontbreken van opdringerige interstitials mee. Wie alleen op de drie metrics jaagt, dweilt met de kraan open terwijl de rest van het huis blijft lekken.

De praktische afweging is simpel: kijk eerst naar de metrics die je conversie en gebruikerservaring daadwerkelijk raken. Een LCP van 4 seconden op je belangrijkste landingspagina is een probleem dat geld kost. Een INP die van 210 naar 190 milliseconden gaat op een pagina met weinig verkeer levert weinig op. Zet ontwikkeltijd in waar de schade het grootst is, niet waar de rapportage het makkelijkst groen kleurt.

Welke tool gebruik je voor welke meting?

Lab-data en field-data zijn geen synoniemen, ook al worden ze vaak verward. Lab-data komt uit gecontroleerde tests, zoals Lighthouse, en is nuttig om een probleem te diagnosticeren. Field-data komt van echte bezoekers, via de Chrome User Experience Report, en bepaalt wat Google werkelijk ziet.

Field-data is leidend voor prioritering, omdat het de werkelijke omstandigheden van je bezoekers weerspiegelt: verschillende netwerken, verschillende apparaten, verschillende Wifi-signalen in de achtertuin. Lab-data is de sectie in het ziekenhuis: nuttig om precies te zien wat er misgaat, maar geen weerspiegeling van de dagelijkse realiteit, zoals web.dev uitlegt.

Een praktische toolset:

  • Search Console toont je Core Web Vitals-rapport per URL-groep, gebaseerd op field-data, maar heeft een minimum aan verkeer nodig voordat een groep verschijnt.
  • PageSpeed Insights combineert field-data (waar beschikbaar) met een Lighthouse-lab-test voor directe diagnose.
  • RUM (Real User Monitoring) of een eigen implementatie van de web-vitals-library geeft je continue, gesegmenteerde field-data buiten Google’s rapportages.

Gebruik Search Console om te zien waar het schoentje wringt, en PageSpeed Insights of Lighthouse om precies te ontleden waarom.

Zo verbeter je de LCP in de praktijk

De grootste winst zit meestal in vier gebieden, in deze volgorde:

  1. Server en netwerk: verlaag de TTFB (time to first byte) met caching, een CDN en compressie. Elke honderd milliseconden die je hier wint, is pure winst zonder bijwerkingen.
  2. Critical rendering path: preload het hero-beeld of lettertype, en zet kritieke CSS inline zodat de browser niet moet wachten op een extern bestand.
  3. Afbeeldingen: comprimeer, gebruik moderne formaten en werk met srcset zodat elk apparaat de juiste maat krijgt. Lazy loading is hier een valkuil: pas het nooit toe op het element dat de LCP bepaalt, want dan vertraag je precies wat je wilde versnellen.
  4. JavaScript: minimaliseer scripts, gebruik defer of async, en overweeg server-side rendering of edge rendering als het framework dat toelaat.

Meet elke maatregel apart. Verander één ding, test opnieuw, en schrijf de winst in seconden op, zoals web.dev adviseert. Dat is de enige manier om te weten wat werkt en wat alleen goed voelt.

Pro-tip: begin bij de server. Een trage TTFB maakt elke volgende optimalisatie kleiner dan hij zou moeten zijn.

Voor een dieper stappenplan rond beeldoptimalisatie en caching kun je de gids over website snelheid verbeteren voor SEO erbij pakken.

Zo houd je de INP onder controle

INP verving FID in mei 2023, omdat FID alleen de eerste interactie meette en INP kijkt naar de volledige interactietijd tijdens het bezoek, zoals Search Central destijds aankondigde. Dat is een fundamenteel andere meting: niet de eerste handdruk, maar het hele gesprek.

De streefwaarde is 200 milliseconden of minder, volgens web.dev. Lange JavaScript-taken zijn de meest voorkomende oorzaak: het hoofdproces raakt geblokkeerd en elke klik moet in de wachtrij.

Concrete technieken:

  • Splits lange taken op in kleinere stukken zodat de browser tussendoor kan reageren op input.
  • Gebruik web workers voor zware berekeningen die niets met de weergave te maken hebben.
  • Optimaliseer event handlers door onnodige herberekeningen en re-renders te vermijden.
  • Vermijd blocking scripts die de hoofdthread vasthouden terwijl een gebruiker al aan het klikken is.

Meet dit met RUM-traces op de interactieve onderdelen die er het meest toe doen, zoals een winkelwagen of een formulier, en vul aan met gerichte lab-tests in PageSpeed Insights.

Zo voorkom je layout shifts en verlaag je de CLS

De meest voorkomende oorzaken zijn bekend: afbeeldingen zonder vaste afmetingen, dynamisch ingeladen content zoals advertenties, en lettertypes die pas laat verschijnen en de tekst laten opschuiven.

De oplossing is in elk geval structureel, nooit een pleister:

  1. Geef elke afbeelding en video een vaste width en height, of gebruik aspect-ratio in de CSS zodat de browser ruimte reserveert voordat het bestand geladen is.
  2. Reserveer vaste ruimte voor advertentiecontainers, ook als de advertentie zelf nog niet geladen is.
  3. Zet font-display: optional of swap in met een zorgvuldig gekozen fallback-lettertype, zodat de tekst niet ineens van grootte verandert.
  4. Voeg nieuwe content nooit boven bestaande content toe, tenzij de gebruiker daar zelf om vraagt.

Test dit interactief, niet alleen met een geautomatiseerde score. Scroll door de pagina zoals een echte bezoeker en let op elke sprong. Een screenshot-vergelijking voor en na een fix is vaak overtuigender dan een getal alleen, zoals web.dev’s uitleg over lab- en field-verschillen ook laat zien.

Pro-tip: reserveer ruimte alsof je een tafel dekt voor gasten die nog niet gearriveerd zijn. Je zet het bord al klaar, ook al is het gerecht nog niet op.

Meer over de regels rond uitgesteld laden vind je in de checklist over lazy loading en SEO.

Wanneer schakel je een technische scan of interim-specialist in

Niet elke site heeft een audit nodig. Een klein blog met een simpele thema-installatie kan meestal zelf de grootste knelpunten oplossen met de stappen hierboven. Uitbesteden wordt de logische keuze zodra drie dingen samenkomen: hoog verkeer waarbij een paar honderd milliseconden vertraging omzet raakt, een technisch complexe stack met meerdere ontwikkelaars, en een Search Console-rapport dat al maanden op Poor of Need improvement blijft steken.

Een technische scan levert dan een prioriteitenlijst op: welke fixes het snelst winst geven, welke quick wins er zijn, en een uitvoerplan van 30 tot 90 dagen waarin de grootste problemen worden aangepakt. Dat plan wordt afgestemd met de webprofessionals die de code daadwerkelijk aanpassen, omdat een lijst zonder uitvoering waardeloos is.

Kort: wat ik vaak zie misgaan

De meeste sites jagen op een paar punten scoreverbetering terwijl de echte winst elders ligt. Dat is tijd verspild aan symptomen.

Drie prioriteiten die wel resultaat geven: pak eerst de server en TTFB aan, want dat werkt door in elke andere metric. Fix daarna afbeeldingen en lazy loading, want dat raakt zowel LCP als CLS. Kijk pas als laatste naar JavaScript-architectuur, want die verandering kost het meest en is niet altijd nodig.

Wortel eruit, altijd. Een pleister op een symptoom houdt het probleem alleen in leven.

— Ramon

Zo helpt een technische scan van Nebber je verder

Weet je niet zeker waar je LCP, INP of CLS vastloopt, of heb je het rapport in Search Console al weken op Poor zien staan zonder dat je weet welke fix eerst? Dan is een technische scan de snelste weg naar een concrete prioriteitenlijst in plaats van nog een generieke checklist.

Nebber

Een technische scan levert:

  • een concrete lijst met de knelpunten die je Core Web Vitals het hardst raken;
  • een inschatting van de impact per fix, zodat je weet waar je ontwikkelaars het eerst aan het werk zet;
  • directe afstemming met je webprofessionals, omdat een lijst zonder uitvoering niets oplevert.

Bekijk wat een technische scan inhoudt en vraag een intake aan via Nebber.

Praktische kernbronnen om mee te meten

Voor wie zelf verder wil meten: het Core Web Vitals-rapport in Search Console toont je field-data per URL-groep, PageSpeed Insights en Lighthouse geven je lab-diagnostiek, en de CrUX-dataset onderbouwt beide met echte gebruikersdata. De artikelen van web.dev over LCP en INP blijven de meest praktische uitleg over meten en verbeteren.

Bronnen

Veelgestelde vragen

Beïnvloeden Core Web Vitals daadwerkelijk je SEO-ranking?

Ja, Core Web Vitals worden gebruikt binnen Google’s rankingsystemen, maar ze vormen slechts één onderdeel van page experience en garanderen geen hogere positie, zoals Google zelf documenteert. Andere factoren, zoals relevantie en autoriteit van content, wegen vaak zwaarder.

Wat is het verschil tussen CLS, LCP en INP?

LCP meet hoe snel het grootste zichtbare element laadt, INP meet hoe snel de pagina reageert op een klik of tik, en CLS meet hoeveel de pagina tijdens het laden visueel verspringt. Samen vormen ze de drie Core Web Vitals die Google gebruikt om laadsnelheid, interactiviteit en visuele stabiliteit te beoordelen.

Hoe zorg je dat je site aan de Core Web Vitals-eisen voldoet?

Zorg dat LCP op 2,5 seconden of minder blijft, INP op 200 milliseconden of minder en CLS op 0,1 of lager, gemeten op het 75e percentiel van je bezoekers, volgens web.dev. Gebruik het Core Web Vitals-rapport in Search Console om te zien welke URL-groepen nog op Need improvement of Poor staan, en pak die eerst aan.

Waarom verschillen mijn Lighthouse-score en mijn Search Console-rapport?

Lighthouse geeft lab-data uit een gecontroleerde test, terwijl Search Console field-data toont van je echte bezoekers met hun eigen apparaten en netwerken. Die twee kunnen flink uiteenlopen, en field-data is leidend omdat het de werkelijke ervaring van bezoekers weerspiegelt, zoals web.dev uitlegt.

Aanbevelingen