SEO, Website ontwikkeling

Core Web Vitals: complete gids met uitleg en tips

Wil je dat je website sneller laadt en beter scoort in Google? Bekijk hiervoor de Core Web Vitals (CWV’s). Core Web Vitals zijn statistieken die de gebruikerservaring van een website meten. Ze focussen op laadsnelheid, interactiviteit en visuele stabiliteit. Google gebruikt deze metingen om te bepalen hoe gebruiksvriendelijk een website is. Core Web Vitals worden ook wel ‘Web Vitals’ of ‘website performance metrics’ genoemd.

Wat zijn Core Web Vitals?

Core Web Vitals zijn de belangrijkste statistieken waarmee Google beoordeelt hoe gebruiksvriendelijk je website is. Voordat Google een statistiek een Core Web Vital noemt, moet het eerst drie fases door: experimental, pending en stable. Alle Web Vitals die zich in de derde fase bevinden, mogen Core Web Vitals genoemd worden. Op dit moment zijn er drie Core Web Vitals en 5 non-Core Web Vitals.

Core Web Vitals

  • Cumulative Layout Shift (CLS) = Cumulatieve lay-outverschuiving
  • Largest Contentful Paint (LCP) = Grootste weergave met content
  • Interaction to Next Paint (INP) = Interactie tot volgende content

Non-Core Web Vitals

  • First Contentful Paint (FCP) = Eerste weergave met content
  • Time to First Byte (TTFB) = Tijd tot eerste byte
  • Total Blocking Time (TBT) = Totale blokkeertijd
  • Speed Index (SI) = snelheid index

Oude Core Web Vitals

  • First Input Delay (FID) = Eerste invoervertraging

Waarom zijn Core Web Vitals belangrijk voor SEO en de gebruiker?

Core Web Vitals spelen een centrale rol in de gebruikerservaring van een website. Google heeft altijd benadrukt dat ze waarde hechten aan de ervaring van de gebruiker. De Web Vitals zijn ontworpen om precies die ervaring te meten. Een website die snel laadt, vlot reageert op interacties en een stabiele lay-out biedt, zorgt voor een plezierigere gebruikerservaring.

Voor gebruikers betekent dit:

  • Snellere laadtijden: Gebruikers willen geen lange wachttijden, en een trage website kan frustratie veroorzaken, waardoor ze sneller je site zullen verlaten.
  • Betere interacties: Wanneer gebruikers klikken of scrollen, willen ze onmiddellijke respons. Een langzame respons kan leiden tot een onprettige ervaring en verhoogt de kans dat bezoekers de site verlaten.
  • Stabiele lay-out: Geen onverwachte verschuivingen van de content tijdens het laden. Dit voorkomt dat gebruikers per ongeluk op de verkeerde knoppen klikken en verbetert de algehele interactie met de website.

Voor SEO zijn Core Web Vitals sinds 2021 een officieel onderdeel van de ranking in zoekresultaten. Google wil websites die gebruikers een goede ervaring bieden, en dit wordt beoordeeld op basis van de snelheid, responsiviteit en stabiliteit van een website. Een slechte prestatie op website performance metrics kan een negatieve invloed hebben op je zoekmachineposities, terwijl een goed geoptimaliseerde website kan bijdragen aan een hogere ranking.

Waarom? Omdat Google er belang aan hecht dat gebruikers snel vinden wat ze zoeken, zonder vertraging of frustratie. Websites die voldoen aan de gestelde prestatienormen, hebben dus een grotere kans om hoger te ranken in de zoekresultaten. Daarnaast heeft een betere gebruikerservaring vaak indirect invloed op andere SEO-factoren, zoals:

  • Minder bounces: Gebruikers die langer blijven hebben een grotere kans om te converteren.
  • Hogere gebruikersbetrokkenheid: Wanneer een website goed reageert en snel laadt, blijven gebruikers langer en hebben ze meer interactie met je content.

Samenvattend: Goede Core Web Vitals zijn niet alleen een signaal voor Google om een website hoger te plaatsen in de zoekresultaten, maar ze zorgen ook voor tevreden gebruikers die de site niet alleen langer bezoeken, maar ook sneller terugkeren en aanbevelen aan anderen.

(non-)Core Web Vitals in begrijpelijke taal

Cumulative Layout Shift (CLS) | Cumultatieve lay-outverschuiving

Bij Cumulative Layout Shift wordt gekeken hoeveel content verschuift tijdens het inladen van de website. Het is niet de bedoeling dat content verschuift. Op het moment dat een bezoeker op een knop of link probeert te klikken en de content schuift ineens naar onder dan kan het zijn dat de bezoeker onbedoeld op iets anders klikt.

Cumulative Layout Shift (CLS)

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) | Grootste weergave met content

Bij Largest Contentful Paint wordt gekeken hoeveel seconden het duurt voordat het grootste zichtbare element ingeladen is. Het kan hierbij gaan om een afbeelding, video, achtergrondafbeelding of tekstblok.

Tijdens het laden van de pagina wordt gekeken welk element het grootst is. Hierbij wordt alleen gekeken naar de elementen die direct in beeld zijn, dus waar de bezoeker van de website niet voor hoeft te scrollen.

Interaction to Next Paint (INP) | Interactie tot volgende content

Bij Interaction to Next Paint wordt gekeken hoe goed gereageerd wordt op een interactie. Hierbij wordt gekeken hoeveel tijd het kost voordat de pagina een visuele update heeft gehad na de interactie. Er worden drie interacties bekeken hiervoor: klikken met een muis, tikken op een touchscreen en een toets indrukken op een fysiek toetsenbord of op een toetsenbord op je scherm.

Interaction to Next Paint (INP)

First Contentful Paint (FCP)

First Contentful Paint (FCP) | Eerste weergave met content

Bij First Contentful Paint wordt gekeken naar hoeveel seconden het duurt voordat de eerste zichtbare inhoud op een website verschijnt. Dit kan tekst, een afbeelding of een ander element zijn. Hoe sneller dit gebeurt, hoe sneller de website “leeft” voor de gebruiker.

Time to First Byte (TTFB) | Tijd tot eerste byte

Time to First Byte (TTFB) meet de tijd die het duurt vanaf het moment dat een gebruiker een verzoek doet naar de server (bijvoorbeeld door een website te openen) totdat de eerste byte van de data wordt ontvangen. Deze meting geeft aan hoe snel de server reageert op het verzoek van de gebruiker.

Het kan worden beïnvloed door verschillende factoren, zoals de snelheid van de server, de netwerkverbinding en eventuele vertragingen in de serverconfiguratie. Hoe lager de TTFB, hoe sneller een website kan beginnen met laden, wat resulteert in een betere gebruikerservaring.

Time to First Byte (TTFB)

Total Blocking Time (TBT) | Totale blokkeertijd

Total Blocking Time (TBT) meet de totale tijd waarin de website niet reageert op interacties van de gebruiker, zoals klikken of scrollen, omdat de pagina nog bezig is met het laden of verwerken van scripts.

Wanneer de browser bezig is met het verwerken van scripts, kan deze tijdelijk niet reageren op acties van de gebruiker. TBT meet die onderbrekingen. Hoe lager de TBT, hoe sneller de pagina interactief is en hoe beter de gebruikerservaring is tijdens het laden.

Speed Index (SI) | snelheid index

Bij Speed Index wordt gekeken hoeveel seconden het duurt voordat inhoud visueel wordt weergegeven tijdens het laden van een pagina.

First Input Delay (FID) | Eerste invoervertraging

Let op: Sinds 9 september 2024 is First Input Delay (FID) vervangen door Interaction to Next Paint (INP) als Core Web Vital. INP biedt een breder en gedetailleerder inzicht in hoe snel een website reageert op gebruikersinteracties, wat belangrijker is voor de gebruikerservaring.

Bij First Input Delay wordt gekeken hoeveel milliseconden het duurt voordat de website op een interactie reageert. Een interactie kan bijvoorbeeld het klikken op een knop of link zijn. Het meten van de tijd start op het moment dat de interactie plaatsvindt.

First Input Delay (FID)

Wat zijn goede Core Web Vitals volgens Google’s richtlijnen?

Good Needs improvement Poor
Largest Contentful Paint ≤2500ms (2400ms, 4000ms] >4000ms
Cumulative Layout Shift ≤0.1 (0.1, 0.25] >0.25
Interaction to Next Paint ≤200ms (200ms, 500ms] >500ms
First Input Delay ≤100ms (100ms, 300ms] >300ms
First Contentful Paint ≤1.8s (1.8s, 3s] >3s
Time to First Byte ≤800ms (800ms, 1800ms] >1800ms
Total Blocking Time ≤200ms (200ms, 800ms] >800ms
Speed Index 3.4s≤ (3.4s, 5.8s] >5.8s

Field Data vs Lab Data

Bij het meten van webprestaties wordt onderscheid gemaakt tussen field data en lab data:

  • Field data: Gegevens verzameld van echte gebruikers in verschillende omstandigheden (apparaten, netwerken, browsers). Dit geeft een realistisch beeld van hoe een website presteert.
  • Lab data: Gegevens verzameld in een gesimuleerde omgeving (zoals Google Lighthouse of PageSpeed Insights). Dit is nuttig voor diagnose en debugging, maar kan afwijken van de echte gebruikerservaring.

Wanneer je je website wilt testen in een gecontroleerde omgeving en specifieke problemen wilt identificeren, zijn lab data (zoals via PageSpeed Insights of Lighthouse) nuttig. Field data, verzameld uit echte gebruikerservaringen, is echter cruciaal voor het begrijpen van de prestaties in het dagelijks gebruik. Een rapport van de field data is terug te vinden bij site-vitaliteit in Google Search Console. Houd er wel rekening mee dat deze data niet realtime is: het is een gemiddelde over de laatste 28 dagen.

Lighthouse Scoring Calculator: inzicht in de prestatiescore weging

Benieuwd hoe je prestatiescore in PageSpeed Insights precies wordt berekend? Met de Lighthouse Scoring Calculator kun je zien welke onderdelen het zwaarst meewegen. Je vindt de link ook onderaan het rapport in PageSpeed Insights.

Volgens Lighthouse v10 is de score als volgt opgebouwd:

  • First Contentful Paint (FCP): 10%
  • Speed Index (SI): 10%
  • Largest Contentful Paint (LCP): 25%
  • Total Blocking Time (TBT): 30%
  • Cumulative Layout Shift (CLS): 25%

Zo zie je meteen waar de meeste winst te behalen valt.

Lighthouse scoring calculator

Core Web Vitals check in Google PageSpeed Insights: audits uitgelegd en oplossingen voor een betere beoordeling

First Contentful Paint (FCP)

  • Verwijder bronnen die de weergave blokkeren – Dit zijn bestanden (zoals CSS en JavaScript) die het laden van de pagina vertragen.
    • Oplossing: Gebruik asynchroon laden of defer-attribuut voor JavaScript.
  • Beperk niet-gebruikte CSS – Niet-gebruikte CSS vertraagt de laadtijd.
    • Oplossing: Verwijder ongebruikte stijlen en gebruik “critical CSS”-technieken.
  • Zorg ervoor dat tekst zichtbaar blijft tijdens het laden van weblettertypen – Teksten kunnen onzichtbaar blijven totdat een lettertype is geladen.
    • Oplossing: Gebruik font-display: swap in CSS.
  • Doorlinken van kritieke verzoeken voorkomen – Te veel afhankelijkheden vertragen het laden.
    • Oplossing: Minimaliseer externe scripts en bronnen.
  • Verklein de CSS – Onnodige spaties en code verhogen de bestandsgrootte.
    • Oplossing: Gebruik een CSS-minifier.
  • Verklein JavaScript – Te grote JavaScript-bestanden vertragen de site.
    • Oplossing: Minificeer en comprimeer JavaScript.
  • Zet tekstcompressie aan – Hiermee worden bestanden gecomprimeerd voor snellere overdracht.
    • Oplossing: Gebruik Gzip of Brotli-compressie.
  • Maak vooraf verbinding met vereiste herkomsten – Dit versnelt het laden van externe bronnen.
    • Oplossing: Gebruik rel=preconnect in HTML.
  • Eerste reactietijd van server verkorten – Een trage server heeft direct impact op je laadtijd en gebruikerservaring.
    • Oplossing: Optimaliseer serverconfiguraties en caching.
  • Vermijd meerdere pagina-omleidingen – Elke redirect vertraagt de laadtijd.
    • Oplossing: Vermijd onnodige 301/302-redirects.
  • Laad belangrijke verzoeken vooraf – Hiermee laad je essentiële bronnen sneller.
    • Oplossing: Gebruik rel=preload voor essentiële bronnen.

Largest Contentful Paint (LCP)

  • Verwijder bronnen die de weergave blokkerenZie uitleg bij FCP.
  • Beperk niet-gebruikte CSSZie uitleg bij FCP.
  • Beperk niet-gebruikt JavaScript – Overtollig JavaScript kan het renderen vertragen.
    • Oplossing: Verwijder ongebruikte scripts en optimaliseer code.
  • Zorg ervoor dat tekst zichtbaar blijft tijdens het laden van weblettertypenZie uitleg bij FCP.
  • Vermijd enorme netwerkpayloads – Te veel data-overdracht vertraagt het laden.
    • Oplossing: Optimaliseer afbeeldingen en gebruik compressie.
  • Doorlinken van kritieke verzoeken voorkomenZie uitleg bij FCP.
  • LCP-element (grootste weergave met content) – Dit is het grootste zichtbare element dat wordt gemeten bij LCP.
    • Oplossing: Zorg dat dit element zo snel mogelijk wordt geladen.
  • Verklein de CSSZie uitleg bij FCP.
  • Verklein JavaScriptZie uitleg bij FCP.
  • Zet tekstcompressie aanZie uitleg bij FCP.
  • Maak vooraf verbinding met vereiste herkomstenZie uitleg bij FCP.
  • Eerste reactietijd van server verkortenZie uitleg bij FCP.
  • Vermijd meerdere pagina-omleidingenZie uitleg bij FCP.
  • Laad belangrijke verzoeken voorafZie uitleg bij FCP.
  • Gebruik video-indelingen voor content met animaties – Videoformaten zoals WebM kunnen efficiënter zijn dan GIFs.
    • Oplossing: Gebruik moderne bestandsformaten.
  • Afbeelding voor Grootste weergave met content (LCP) vooraf laden – Laad de belangrijkste afbeelding eerder in om LCP te verbeteren.
    • Oplossing: Gebruik preload voor deze afbeelding.
  • Afbeelding voor Grootste weergave met content (LCP) is niet geladen met lazy loading – Vermijd lazy loading voor de LCP-afbeelding om vertraging te voorkomen.
    • Oplossing: Laad deze afbeelding direct in plaats van uit te stellen.

Total Blocking Time (TBT)

  • Primaire threadbewerkingen minimaliseren – Het blokkeren van de primaire thread vertraagt interacties.
    • Oplossing: Optimaliseer JavaScript en voorkom lange taken op de hoofdthread.
  • De impact van code van derden beperken – Externe scripts kunnen de prestaties vertragen.
    • Oplossing: Minimaliseer en laad externe scripts asynchroon.
  • Verkort de JavaScript-uitvoeringstijd – Lange JavaScript-taken blokkeren de hoofdthread.
    • Oplossing: Splits grote bestanden op en optimaliseer de uitvoeringstijd.
  • Vermijd een overmatig grote DOM – Een grote DOM zorgt voor vertraging bij het renderen.
    • Oplossing: Houd de DOM klein door overbodige elementen te verwijderen.
  • Lange taken in de primaire thread vermijden – Lange taken blokkeren de thread en vertragen de interactie.
    • Oplossing: Gebruik webworkers of stel taken uit om de hoofdthread vrij te houden.
  • Dubbele modules verwijderen uit JavaScript-bundels – Dubbele modules vergroten de bestandsgrootte en vertragen de pagina.
    • Oplossing: Gebruik bundlers om dubbele modules te elimineren.
  • Voorkomen dat verouderde JavaScript wordt geleverd aan moderne browsers – Verouderde JavaScript vertraagt moderne browsers.
    • Oplossing: Lever geoptimaliseerde code aan moderne browsers via browserdetectie.
  • Resources van derden laden via lazy loading met façades – Externe bronnen kunnen de pagina vertragen.
    • Oplossing: Laad bronnen pas in wanneer ze nodig zijn via lazy loading.
  • Bevat een <meta name=”viewport”>-tag met width of initial-scale – Een ontbrekende of onjuiste viewport-tag vertraagt de weergave.
    • Oplossing: Voeg een correcte viewport-tag toe voor mobiele optimalisatie.

Cumulative Layout Shift (CLS)

  • Afbeeldingselementen hebben geen expliciete width en height – Afbeeldingen zonder afmetingen veroorzaken verschuivingen in de lay-out tijdens het laden.
    • Oplossing: Stel altijd een breedte en hoogte in voor afbeeldingen.
  • Grote indelingsverschuivingen vermijden – Grote verschuivingen van de lay-out kunnen de gebruikerservaring verstoren.
    • Oplossing: Geef elementen een vaste grootte en positie om verschuivingen te voorkomen.
  • Niet-samengestelde animaties vermijden – Animaties die de lay-out beïnvloeden kunnen verschuivingen veroorzaken.
    • Oplossing: Gebruik animaties die de lay-out niet veranderen, zoals opaciteit of kleur.

Site-vitaliteit in Google Search Console

In Google Search Console kun je onder het onderdeel Site-vitaliteit precies zien hoe je website presteert op het gebied van gebruikerservaring. Je vindt hier uitgebreide informatie over de drie belangrijkste Core Web Vitals: LCP, INP en CLS.

De gegevens in dit rapport zijn gebaseerd op echte gebruikservaringen van bezoekers van je site (field data), afkomstig uit het Chrome User Experience (CrUX) report. Google gebruikt deze informatie bij het beoordelen van je website in de zoekresultaten.

De rapportage is opgedeeld in mobiel en desktop, omdat de prestaties per apparaat kunnen verschillen.

Wat zie je in het site-vitaliteit rapport?

In de eerste grafiek zie je een overzicht van al je gemeten URL’s, verdeeld in drie categorieën:

  • Goede URL’s (groen)
  • URL’s hebben verbetering nodig (oranje)
  • Slechte URL’s (rood)

Door op één van deze categorieën te klikken, krijg je inzicht in welke URL’s onder die categorie vallen.

Google Search Console site-vitaliteit mobiel

Google Search Console site-vitaliteit rapport voor mobiel

Waarom worden sommige URL’s als slecht beschouwd?

Klik je door naar een specifieke groep van URL’s, dan zie je exact welke Core Web Vitals de oorzaak is (zoals een te hoge LCP of een lage INP-score). Je ziet daarbij ook het precieze drempelprobleem en soms de bijbehorende pagina’s.

Wat kun je met de site-vitaliteit informatie?

  • Prioriteren: Zie welke URL-groepen het meest kritiek zijn en pak die als eerste aan.
  • Segmenteren: Herken patronen, zoals problemen die alleen op mobiel spelen.
  • Monitoren: Na optimalisaties kun je zien of de status van de URL’s verandert van rood naar oranje of groen.

Door regelmatig dit rapport te bekijken en actie te ondernemen, verbeter je niet alleen je SEO-positie, maar bied je ook een betere ervaring aan je bezoekers.

Aan de slag met Core Web Vitals

Wil je de prestaties van je website verbeteren? Volg dan deze stappen:

  1. Begin met het rapport ‘Site-vitaliteit’ in Google Search Console
    Dit geeft je een overzicht van hoe echte bezoekers jouw site ervaren. Je ziet per apparaat (mobiel en desktop) of je URL’s goed zijn, verbetering nodig hebben of slecht scoren.
  2. Gebruik PageSpeed Insights of Lighthouse
    Hiermee kun je per pagina inzoomen en precies zien waarom iets traag is of verspringt. Denk aan te grote afbeeldingen, trage scripts of blokkerende stylesheets.
  3. Bepaal wat het belangrijkst is om aan te pakken
    Begin bij de slecht scorende pagina’s die veel bezoekers krijgen. Zo haal je de meeste winst met de minste moeite.
  4. Schakel je ontwikkelaar of webbouwer in
    In de meeste gevallen heb je echt iemand nodig die technisch onderlegd is. Veel verbeteringen draaien om het herschrijven van code, aanpassen van laadmethode of optimaliseren van hosting.
  5. Voer de verbeteringen door en test opnieuw
    Na de aanpassingen check je opnieuw in Pagespeed Insights én houd je Google Search Console in de gaten. Houd er rekening mee dat Search Console wat vertraging heeft in het bijwerken van gegevens.
  6. Blijf regelmatig controleren
    Iedere update aan je site (zoals een nieuwe plugin, script of cookiemelding) kan invloed hebben op je scores. Controleer daarom regelmatig je prestaties. Gebruik hiervoor eventueel een RUM (Real User Monitoring) tool zoals RUMvision of CoreDash. Deze bieden realtime data, in tegenstelling tot de standaard tools van Google waarbij de data een gemiddelde is van de laatste 28 dagen.

Hoewel Core Web Vitals misschien wat technisch klinken, zijn ze echt belangrijk voor een goede gebruikerservaring. Door deze aandacht te geven, zorg je dat je site sneller en stabieler wordt, wat niet alleen fijn is voor je bezoekers maar ook kan helpen om beter gevonden te worden in Google. Het is goed om hier stap voor stap mee aan de slag te gaan en regelmatig te checken hoe het gaat.