Core Web Vitals: wat LCP, INP en CLS meten, de drempels van Google en hoe 58 Nederlandse sites scoren

Core Web Vitals zijn drie getallen waarmee Google meet hoe een pagina aanvoelt voor een bezoeker: hoe snel het grootste element in beeld staat (LCP), hoe snel de pagina reageert op een tik of klik (INP) en hoeveel de inhoud verspringt tijdens het laden (CLS). Google meet ze bij echte Chrome-gebruikers en gebruikt ze als een van de vele signalen in de ranking. Een klein signaal, geen wondermiddel. Ze zijn de kern van het bredere Web Vitals-programma van Google. Hieronder: wat de drie meten, waar de grens ligt, veld- tegenover labdata, wat Google er zelf over zegt en de vijf oorzaken die wij het vaakst tegenkomen. Plus een meting van 58 Nederlandse homepages, met onze eigen site erbij. Die kwam er niet goed vanaf.

De drie Core Web Vitals en wat ze meten

LCP: hoe snel het grootste element in beeld staat

Largest Contentful Paint is het moment waarop het grootste zichtbare element op het scherm staat, meestal de hero-afbeelding of de kop. Voor een bezoeker is dit het moment waarop de pagina “er is”.

INP: hoe snel de pagina reageert op een klik of tik

Interaction to Next Paint kijkt naar alle klikken, tikken en toetsaanslagen tijdens een bezoek en meet hoe lang het duurt voordat het scherm zichtbaar reageert. Een menu dat pas na een halve seconde openklapt: dat is INP. De oorzaak is vrijwel altijd JavaScript dat de browser bezighoudt. Omdat INP het hele bezoek meetelt, kun je het alleen bij echte bezoekers meten; in een test klikt niemand.

CLS: hoeveel de pagina verspringt

Cumulative Layout Shift telt op hoeveel zichtbare inhoud verschuift zonder dat je iets deed. Je wilt op een knop tikken, er laadt een banner boven, en je tikt op een advertentie.

Bron: de artikelen over LCP, INP en CLS op web.dev (Google; Philip Walton, Jeremy Wagner en Barry Pollard; bijgewerkt 4 september 2025, 2 september 2025 en 12 april 2023), gelezen op 22 september 2026. Google beoordeelt op het 75e percentiel, apart voor mobiel en desktop: driekwart van je bezoekers moet onder de drempel zitten.

FID, FCP en INP: drie afkortingen die door elkaar lopen

In Nederland wordt vaker gezocht op “fid” (880 keer per maand) en “fcp” (720) dan op “core web vitals” zelf (590), volgens Google Ads-schattingen van 22 september 2026. Daarom de korte versie.

FID (First Input Delay) is vervangen door INP

First Input Delay mat alleen de vertraging van de eerste interactie; goed was 100 milliseconden of minder. Te mild, want een pagina kon daarna alsnog haperen. Google kondigde op web.dev aan (Jeremy Wagner en Rick Viscomi, bericht bijgewerkt 31 januari 2024) dat INP op 12 maart 2024 de plaats van FID zou innemen; de ondersteuning voor FID stopte op 9 september 2024 (web.dev/articles/fid, gelezen 22 september 2026). Toont een tool nog FID, dan is die tool verouderd.

FCP (First Contentful Paint) is geen Core Web Vital

First Contentful Paint is het moment waarop het eerste stukje inhoud verschijnt, een regel tekst of een logo. Het zegt iets over de start van het laden, niet over het moment dat de pagina bruikbaar is; LCP komt altijd later. Web.dev noemt 1,8 seconden of minder goed en meer dan 3,0 seconden slecht. Een trage FCP wijst bijna altijd op een trage server of op CSS en JavaScript die het tekenen blokkeren.

Velddata of labdata: CrUX tegenover Lighthouse

• Velddata komt uit het Chrome User Experience Report (CrUX). Google verzamelt bij Chrome-gebruikers die gebruiksstatistieken delen en hun browsegeschiedenis synchroniseren hoe pagina’s laden, en bundelt dat per pagina en per domein over een voortschrijdend venster van 28 dagen (developer.chrome.com/docs/crux/api, bijgewerkt 11 februari 2025, gelezen 22 september 2026). Dit gebruikt Google voor de ranking; dit zie je in Search Console en bovenaan PageSpeed Insights.
• Labdata komt uit Lighthouse, dat in PageSpeed Insights, in Chrome DevTools en los te draaien is. Het laadt de pagina één keer op een gesimuleerde middenklasse-telefoon met traag 4G. Handig om te zien wát er misgaat, maar geen echte bezoekers, één laadbeurt, en geen INP: Lighthouse gebruikt Total Blocking Time (TBT) als benadering, de tijd dat de browser tijdens het laden te druk is met scripts om te reageren (web.dev/articles/tbt, bijgewerkt 15 oktober 2025).

De vuistregel: velddata voor het oordeel, labdata voor de diagnose. Staat je site in Search Console op groen, dan is een oranje Lighthouse-score geen reden voor paniek. Staat hij op rood, dan vertelt Lighthouse je waar je moet beginnen.

Wat Core Web Vitals doen voor je ranking, in Googles eigen woorden

Hier wordt veel bij verzonnen, dus we houden ons aan “Understanding page experience in Google Search results” van Google Search Central (bijgewerkt 10 december 2025, gelezen 22 september 2026):

• “Core Web Vitals are used by our ranking systems.” Het telt dus mee.
• Goede scores zijn geen garantie dat je bovenaan komt; een perfecte score najagen puur om SEO-redenen “may not be the best use of your time”.
• “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” Bij veel zoekopdrachten is er volop goede content, en dan kan pagina-ervaring het verschil maken.

Onze lezing: een klein signaal dat meetelt als de inhoud vergelijkbaar is, niet iets waarmee je een zwakke pagina omhoog tilt. De echte reden om het op orde te hebben, is de bezoeker die zes seconden naar een leeg scherm kijkt en weg is voordat je tekst iets heeft kunnen doen.

Hoe 58 Nederlandse homepages scoren: onze Lighthouse-meting

Op 22 september 2026 hebben we Lighthouse lokaal losgelaten op 58 Nederlandse homepages: 36 dienstverleners uit de top 10 van Google in zes branches (boekhouding, verhuizen, webbouw, logo-ontwerp, arbeidsrecht en zonnepanelen), 21 webshops uit de top 10 op zes koopzoekopdrachten, en rankpilot.nl. Mobiele emulatie met gesimuleerd traag 4G, één run per site. Lees de getallen als “onder ongunstige omstandigheden”, niet als wat een bezoeker op wifi ziet.

De mediane homepage: een Lighthouse-score van 53 van 100, een LCP van 12,7 seconden, een CLS van 0,002 en een TBT van 248 milliseconden. Geen enkele site haalde een score van 90 of hoger, 24 bleven onder de 50. CLS is het goede nieuws: verspringende pagina’s zijn zeldzaam geworden. LCP is het slechte nieuws: geen enkele site onder de 2,5 seconden, en 56 boven de 4.

En wijzelf? In een eerste test op 22 september 2026 kwam rankpilot.nl uit op een LCP van 14,6 seconden en een score van 41. In de meting hierboven, dezelfde dag, was het een score van 54, een LCP van 14,9 seconden, een CLS van 0,000 en een TBT van 243 milliseconden. Het LCP-element is een afbeelding, en de pagina laadt CSS of JavaScript die het tekenen blokkeert. Dat gaan we fixen, en het resultaat zetten we hier neer.

De vijf oorzaken die wij het vaakst zien, met de fix

De top 3 in onze meting: render-blokkerende CSS of JavaScript (45 van 58), meer dan 300 KiB ongebruikte JavaScript (33) en afbeeldingen zonder afmetingen (22). Hieronder de vijf oorzaken die wij bij klanten het vaakst tegenkomen, met de fix in gewone taal.

1. Een te grote hero-afbeelding

Bij 48 van de 58 homepages was het LCP-element een afbeelding (27 keer een gewone img, 21 keer een css-achtergrond), en bij 17 sites waren afbeeldingen groter dan het scherm. De fix: maak de foto niet breder dan hij getoond wordt (1.600 pixels is voor de meeste hero’s zat), sla hem op als WebP of AVIF, zet geen lazy loading op het eerste beeld en geef het fetchpriority="high" mee. Een slider vervang je door één foto; niemand wacht op dia twee.

2. Te veel plugins en scripts

Render-blokkerende CSS en JavaScript kwamen voor bij 45 van de 58 sites; 33 sites laadden meer dan 300 KiB aan JavaScript die op de homepage niet gebruikt werd, en de mediane homepage laadde 34 scriptbestanden. Elke plugin, chatwidget en trackingpixel brengt zijn eigen script mee, en dat is ook de grootste oorzaak van een slechte INP. De fix: zet uit wat je niet gebruikt, laad chat, video-embeds en tracking pas na de eerste interactie, en vraag bij elk script wat er gebeurt als het weg is.

3. Afbeeldingen zonder afmetingen

Weet de browser niet hoe groot een afbeelding wordt, dan reserveert hij geen ruimte en schuift de tekst opzij zodra de foto binnenkomt. Bij 22 van de 58 sites vond Lighthouse zulke afbeeldingen. De fix: geef elke afbeelding een width en height mee (WordPress doet dat zelf, mits je thema het niet sloopt) en reserveer ruimte voor embeds en de cookiebanner.

4. Webfonts die de tekst ophouden

Bij 21 van de 58 sites ontbrak font-display, waardoor de browser de tekst verbergt tot het lettertype binnen is. Een halve seconde onzichtbare tekst is een halve seconde latere LCP. De fix: font-display: swap, de fonts op je eigen server, hooguit twee gewichten en het hoofdlettertype preloaden. Of een systeemlettertype; niemand haakt af omdat je bodytekst in Arial staat.

5. Goedkope hosting

Alles hierboven begint pas nadat de server het eerste byte heeft teruggestuurd. De mediane server deed daar 72 milliseconden over, bij 4 van de 58 sites langer dan 800 milliseconden; dat is echte servertijd, want die fase wordt niet gesimuleerd. Gedeelde hosting van een paar euro per maand, zonder cache, met een zware WordPress erop: dan redt geen plugin je meer. De fix, in volgorde: een paginacache, een CDN, en pas daarna een duurder hostingpakket.

Wat nu?

Begin bij de velddata in Search Console of bovenaan PageSpeed Insights. Staat daar niets omdat je site te klein is, ga dan op de labdata af en pak de vijf punten hierboven op volgorde. Wil je dat iemand meekijkt? Bij de gratis SEO-analyse beoordeelt een specialist je site binnen 1 werkdag, inclusief snelheid. Bij RankPilot zit technische SEO wekelijks in elk pakket, vanaf 399 euro per maand exclusief btw, maandelijks opzegbaar. De volledige lijst technische punten staat in ons artikel over de technische SEO checklist; de afkortingen uit dit stuk staan in onze woordenlijst met SEO-termen.

Veelgestelde vragen

Wat zijn de Core Web Vitals?

Drie meetwaarden van Google voor de ervaring van een bezoeker: Largest Contentful Paint (laadsnelheid), Interaction to Next Paint (reactiesnelheid) en Cumulative Layout Shift (verspringen). Google meet ze bij echte Chrome-gebruikers en toont ze in Search Console.

Welke waarden zijn goed?

LCP 2,5 seconden of minder, INP 200 milliseconden of minder en CLS 0,1 of minder, bij het 75e percentiel van de bezoeken. Slecht is een LCP boven 4 seconden, een INP boven 500 milliseconden of een CLS boven 0,25 (web.dev, gelezen 22 september 2026).

Is First Input Delay (FID) nog een Core Web Vital?

Nee. Interaction to Next Paint (INP) nam op 12 maart 2024 de plaats van FID in, en sinds 9 september 2024 wordt FID niet meer ondersteund (web.dev).

Hoe zwaar wegen Core Web Vitals voor de ranking in Google?

Google schrijft dat Core Web Vitals door zijn rankingsystemen worden gebruikt, maar ook dat goede scores geen garantie zijn en dat Google altijd de meest relevante inhoud wil tonen, ook als de pagina-ervaring tegenvalt (Google Search Central, bijgewerkt 10 december 2025). Een klein signaal dus.

Waarom laat PageSpeed Insights andere cijfers zien dan Search Console?

Search Console toont velddata: wat echte Chrome-gebruikers de afgelopen 28 dagen meemaakten. PageSpeed Insights toont diezelfde velddata bovenaan en daaronder labdata van Lighthouse, één gesimuleerde laadbeurt op een trage telefoon. Die twee horen te verschillen.

Zo is dit gemeten

60 homepages, gemeten op 22 september 2026 met Lighthouse 12.8.2 lokaal (npx lighthouse@12), alleen Performance, mobiele emulatie met de standaard gesimuleerde throttling van Lighthouse (150 ms latency, 1,6 Mbps, viermaal tragere processor), één run per site, strikt na elkaar. 58 sites leverden een geldige meting op; kerstpakkettenplaza.nl weigerde de test (403, ook bij een tweede poging); bij fonteyn.nl vond Lighthouse twee keer geen LCP-element. Geen representatieve steekproef, wel sites die goed ranken. Het is labdata: geen echte bezoekers, geen CrUX, geen INP. Voor INP hebben we Total Blocking Time gebruikt met de Lighthouse-band voor mobiel (0 tot 200 ms goed, 200 tot 600 matig, daarboven slecht; developer.chrome.com, gelezen 22 september 2026); voor LCP, CLS en FCP de drempels van web.dev. De ruwe uitkomsten per site bewaren we in een JSON.

Bronnen, zelf gelezen op 22 september 2026: web.dev (artikelen vitals, lcp, inp, cls, fcp, fid en tbt, plus het blogbericht van Jeremy Wagner en Rick Viscomi over INP, bijgewerkt 31 januari 2024), Google Search Central (“Understanding page experience in Google Search results”, bijgewerkt 10 december 2025) en developer.chrome.com (CrUX API, bijgewerkt 11 februari 2025). Zoekvolumes: Google Ads via DataForSEO, 22 september 2026.