Core Web Vitals niet geslaagd? Zo verbeter je LCP, INP en CLS

Kort antwoord: Een mislukte beoordeling van de Core Web Vitals betekent dat minstens één van drie meetwaarden bij echte bezoekers boven de grens zit: de LCP (laden) hoort 2,5 seconden of minder te zijn, de INP (reactie) 200 milliseconden of minder en de CLS (visuele stabiliteit) 0,1 of minder, elk gemeten op het 75e percentiel. Zoek de zwakke waarde in veldgegevens van echte bezoekers, niet in de labscore, en los eerst die ene op. Google zegt dat zijn rankingsystemen de Core Web Vitals gebruiken, maar goede waarden garanderen geen toppositie.

Wat betekent een mislukte Core Web Vitals-beoordeling?

De Core Web Vitals zijn het deel van het Web Vitals-initiatief van Google dat voor elke webpagina geldt. web.dev noemt drie meetwaarden, één voor elk aspect van de gebruikerservaring:

De waarden worden beoordeeld op het 75e percentiel van de paginaweergaven, apart voor mobiel en desktop. In gewone woorden: bij drie van de vier bezoeken moet de waarde goed zijn, en mobiel en desktop krijgen elk hun eigen oordeel. web.dev zegt dat tools een pagina als geslaagd moeten tellen als ze op het 75e percentiel voor alle drie de meetwaarden aan de doelen voldoet. Eén rode waarde is dus genoeg om te falen.

Een detail aan de rand: web.dev schrijft bij INP en CLS “of minder”, terwijl de documentatie over Zoeken van Google “less than 200 milliseconds” en “less than 0.1” schrijft. Mik duidelijk onder de grens, dan maakt het verschil niet uit.

Eén verandering moet je kennen: de INP heeft in maart 2024 First Input Delay (FID) vervangen als Core Web Vital, zoals de aankondiging op web.dev zegt. Een handleiding die nog FID noemt, is verouderd. Alle pagina’s die in dit artikel worden genoemd, hebben we op 4 november 2026 gelezen. Het overzicht van web.dev is voor het laatst bijgewerkt op 31 oktober 2024.

Beïnvloeden de Core Web Vitals de ranking in Google?

Volgens Google wel, maar het noemt geen gewicht. De pagina van Google over pagina-ervaring zegt: “Core Web Vitals are used by our ranking systems.” Google beveelt goede waarden aan voor succes in Zoeken en voegt toe dat er geen enkel afzonderlijk signaal voor pagina-ervaring is.

Dezelfde pagina is even duidelijk over de grenzen. Goede resultaten in het rapport over de Core Web Vitals in Search Console of in tools van derden “doesn't guarantee that your pages will rank at the top of Google Search results”. Er staat ook dat jagen op een perfecte score alleen voor SEO misschien niet de beste besteding van je tijd is. Google probeert altijd de meest relevante inhoud te tonen, ook als de pagina-ervaring zwak is.

Hoeveel gewicht de meetwaarden hebben, publiceert Google niet, dus ook wij noemen geen getal. Onze lezing, geen uitspraak van Google: zie de grenswaarden als kwaliteitslat voor je bezoekers, breng alle drie in het groen en steek je tijd daarna weer in inhoud. De kernrankingsystemen van Google beoordelen inhoud over het algemeen per pagina, dus controleer elk type pagina dat ertoe doet.

Labgegevens of veldgegevens: wat telt bij Core Web Vitals?

De beoordeling is gebaseerd op veldgegevens: metingen van echte bezoeken. Het Chrome User Experience Report (CrUX) van Google verzamelt ze bij echte Chrome-gebruikers. PageSpeed Insights en het Core Web Vitals-rapport in Search Console tonen ze. Volgens web.dev beslaat een CrUX-rapport een periode van 28 dagen.

Labgegevens ontstaan als de pagina één keer onder vaste omstandigheden wordt geladen: één apparaat, één netwerk, één locatie. Dat is ideaal om oorzaken te vinden en een oplossing voor de release te testen, maar de LCP-gids waarschuwt dat “lab tests alone may not be entirely representative”. Spreken de twee elkaar tegen, dan zegt diezelfde LCP-gids dat je je eerst op de gegevens van echte gebruikers moet richten. Ze verschillen om goede redenen:

• Het LCP-element kan verschillen. Een labrun vindt altijd hetzelfde element. Echte bezoeken hebben andere schermformaten, ingelogde inhoud of A/B-tests.
• Voor INP heb je echte mensen nodig. Lighthouse en andere labtools laden een pagina zonder dat iemand klikt, dus ze kunnen de INP niet meten. Total Blocking Time (TBT) is de vervanger in het lab. Verbeteringen aan TBT kunnen ook de INP verbeteren.
• CLS telt door na het laden. Labruns zien meestal alleen het laden zelf. In het veld kan inhoud die verschijnt terwijl bezoekers scrollen de lay-out ook laten verspringen.
• Caches helpen echte bezoekers. Labtests beginnen meestal met een lege cache, terwijl terugkerende bezoekers en de back/forward-cache pagina’s sneller laden.

Zo lees je je cijfers in vier stappen:

1. Voer je adres in bij PageSpeed Insights. Het onderdeel “Discover what your real users are experiencing” (naam in de Engelse interface) bevat veldgegevens. “Diagnose performance issues” bevat de labrun.
2. Controleer waar je naar kijkt. Schakel tussen mobiel en desktop en tussen de enkele URL en de hele origin. Heeft een URL te weinig gegevens, dan toont PageSpeed Insights in plaats daarvan de gegevens van de origin.
3. Zoek de meetwaarde die op het 75e percentiel over de grens zit. Dat is je zwakke waarde. Bij te weinig verkeer zijn er geen veldgegevens. Gebruik dan de labwaarden en meet je eigen bezoekers met de kleine web-vitals-bibliotheek van web.dev.
4. Open de labdiagnose voor die meetwaarde om de oorzaak te zien, en los eerst die ene zaak op.

LCP verbeteren: het grootste element verschijnt te laat

De LCP meldt wanneer het grootste beeld, tekstblok of de grootste video in het zichtbare gebied is weergegeven. De LCP-gids van web.dev verdeelt de tijd in vier delen die samen de LCP vormen: de serverreactie (TTFB), de vertraging voordat de browser de LCP-bron begint te laden, de tijd die die bron nodig heeft om te laden en de vertraging tot het element wordt weergegeven. Zoek het grootste deel voordat je iets verandert: wie één deel verkort, verschuift de tijd soms alleen naar een ander. Een sterker gecomprimeerd beeld helpt niet als het element verborgen blijft totdat een script is geladen.

De lijst met de meest effectieve oplossingen van het Chrome-team bevat onder meer deze:

1. Maak het LCP-beeld makkelijk vindbaar en geef het voorrang. Gebruik een gewone <img> met src of srcset, geen data-src waarvoor JavaScript nodig is. Laat de pagina liever op de server opbouwen dan alleen in de browser. Voeg fetchpriority="high" toe en haal loading="lazy" weg bij dit ene beeld.
2. Verkort de serverreactie. Lever en cache inhoud dicht bij je bezoekers, meestal met een CDN.

Dezelfde tag regelt de LCP en, via de afmetingen, ook de CLS:

<!-- Hoofdbeeld: in de HTML, hoge prioriteit, niet lazy, met afmetingen -->
<img src="/img/hero.webp" width="1200" height="630" alt="Korte beschrijving" fetchpriority="high">

<!-- Beelden verderop op de pagina: lazy loading is hier prima -->
<img src="/img/team.webp" width="600" height="400" alt="Korte beschrijving" loading="lazy">

INP verbeteren: de pagina reageert te traag

De INP volgt elke klik, tik en toetsaanslag tijdens een bezoek en meldt ongeveer de traagste (bij pagina’s met heel veel interacties blijven uitschieters buiten beschouwing). Hoveren en scrollen tellen niet mee. Volgens de INP-gids heeft elke interactie drie delen: de invoervertraging, de tijd dat de event handlers draaien en de vertraging tot het volgende beeld wordt getoond. De gebruikelijke boosdoener is JavaScript dat de hoofdthread bezet houdt. De belangrijkste oplossingen van het Chrome-team:

1. Breek lange taken op. Een taak van meer dan 50 milliseconden blokkeert de hoofdthread. Geef de controle vaak terug: met scheduler.yield() waar de browser dat ondersteunt, met setTimeout als oudere manier.
2. Lever minder JavaScript. Vind ongebruikte code met de coverage-tool in Chrome DevTools, splits code die aanvankelijk niet nodig is en ruim oude tags in je tagmanager op.
3. Vermijd grote weergave-updates. Houd de DOM klein, vermijd geforceerde lay-out en gebruik CSS-containment voor inhoud buiten het scherm.

CLS verbeteren: de lay-out springt

De CLS heeft geen eenheid. Ze combineert hoeveel zichtbare inhoud er is verschoven en hoe ver. In het veld telt ze over het hele bezoek, maar verschuivingen binnen 500 milliseconden na een gebruikersinteractie blijven buiten beschouwing. De CLS-gids van web.dev noemt de gangbare oorzaken: beelden zonder afmetingen, advertenties, embeds en iframes zonder afmetingen, dynamisch ingevoegde inhoud en webfonts. Dit helpt:

• Reserveer ruimte. Geef beelden en video’s width en height, of gebruik de CSS-eigenschap aspect-ratio. Voor inhoud van onbekende grootte is een zinnige min-height beter dan de standaardwaarde nul.
• Animeer met transform. Wie top, left of margin animeert, verschuift de lay-out. Cookiebanners die naar binnen schuiven zijn een typisch geval.
• Laat de back/forward-cache werken. Die herstelt volledig weergegeven pagina’s. Veelvoorkomende blokkades zijn cache-instructies met no-store en unload-event-listeners.
• Pak webfonts aan. font-display: optional, bijpassende terugvalfonts met size-adjust en het vooraf laden van kritieke fonts verminderen ze alle drie de verschuivingen die door fonts ontstaan.

Zo controleert SEOgrinder Core Web Vitals

SEOgrinder is ons eigen gereedschap, dat we zelf bouwen. Voer bij SEOgrinder een openbaar adres in en de snelheidscijfers komen van Google PageSpeed Insights, voor mobiel en voor desktop. De kaart “Core Web Vitals” toont LCP en CLS uit de Lighthouse-labrun en de INP van echte bezoekers. Een apart vak, “Gegevens van echte gebruikers”, toont de gegevens van echte bezoekers uit de afgelopen 28 dagen. Heeft Google te weinig gegevens voor de pagina, dan zegt het rapport dat, in plaats van te gokken. Taken zoals “Echte bezoekers op mobiel wachten … op de inhoud” noemen de meetwaarde, het getal en de oplossing. Een trage serverreactie, die doorwerkt in de LCP, krijgt een eigen taak: “Trage serverreactie”.

Grenzen: SEOgrinder leest de cijfers van Google en vervangt je eigen monitoring van echte bezoekers niet. Rankings meet het niet. Is het dagelijkse quotum van Google voor de snelheidsmeting op, dan komt het rapport zonder die meting.

Veelgemaakte fouten

• Alleen op de labscore vertrouwen. Ze kan de INP niet meten en kan er anders uitzien dan wat bezoekers ervaren. Begin met de waarden van echte bezoekers.
• Maar één apparaat controleren. Mobiel en desktop worden apart beoordeeld.
• Het hoofdbeeld lazy laden. loading="lazy" op het LCP-beeld voegt vertraging toe.
• Beeldafmetingen weglaten. Zonder width en height kan de browser geen ruimte reserveren.
• Het verkeerde deel van de LCP aanpakken. Comprimeer beelden pas als de uitsplitsing laat zien dat de laadtijd het probleem is.
• Een direct resultaat verwachten. Veldgegevens beslaan 28 dagen, dus ze veranderen geleidelijk. Controleer de labrun direct na een oplossing en de waarden van echte bezoekers in de weken erna.

Veelgestelde vragen

Wat is een goede score voor de Core Web Vitals?

Eén enkele score bestaat niet. Een pagina slaagt als de LCP op het 75e percentiel 2,5 seconden of minder is, de INP 200 milliseconden of minder en de CLS 0,1 of minder. Het getal van 0 tot 100 dat je misschien kent van Lighthouse is een labwaarde en iets anders.

Waarom toont PageSpeed Insights geen gegevens van echte gebruikers voor mijn site?

Meestal zijn er te weinig bezoeken om CrUX iets te laten melden. web.dev stelt voor in dat geval zelf de echte bezoekers te meten. Werk tot dan met de labwaarden.

Heb ik een perfecte score nodig?

Nee. Slagen is het doel. Google zelf zegt dat jagen op een perfecte score alleen om SEO-redenen misschien niet de beste besteding van je tijd is.

Je volgende stap

Laat je belangrijkste pagina door SEOgrinder lopen, open de kaart “Core Web Vitals” en kijk eerst naar de waarden van echte bezoekers. Los de ene meetwaarde op die faalt, klik op Opnieuw controleren en lees daarna de labwaarden. Het grotere plaatje staat in onze SEO-audit checklist.

Lees ook

• Hoger in Google komen: 3 dingen die Google zelf aanraadt
• Interne links: verweesde pagina’s vinden en klikdiepte verkleinen
• Gestructureerde gegevens: 2 JSON-LD-voorbeelden om te kopiëren