Core Web Vitals: dit moet je echt weten

Core Web Vitals zijn sinds Google ze aankondigde een veelbesproken onderwerp in de wereld van SEO. En terwijl ze veelbesproken zijn, zijn er ook belangrijke details waar -in ieder geval op het moment van schrijven- nog niemand je over vertelde. Terwijl ze wel van belang zijn wanneer jij aan de slag gaat met het verbeteren van je Core Web Vitals. Je leest hier alles wat je echt moet weten over deze rankingfactor van Google, van de belangrijke basis tot de dingen waar anderen nog niet over schreven.

-Dit artikel is oorspronkelijk gepubliceerd op 8 oktober 2020 en geüpdatet en opnieuw gepubliceerd op 20 mei 2021-

Core Web Vitals: onderdeel van de Page Experience Update

In mei 2020 kondigde Google de Page Experience aan, een algoritme-update waarbij een nieuwe rankingfactor wordt geïntroduceerd: Core Web Vitals. Met deze update wordt de gebruikerservaring meetbaar met specifieke elementen die ze de Core Web Vitals noemen. We duiken eerst in de Core Web Vitals, waarna je belangrijke informatie krijgt over hoe je hiermee omgaat op jouw website. Informatie die ik nog niet op andere websites heb teruggevonden.

Wat zijn de Core Web Vitals?

De Core Web Vitals zijn elementen waarmee Google de gebruikerservaring op webpagina’s meetbaar maakt. Deze elementen wegen mee voor jouw posities in de zoekresultaten en zijn daarmee dus rankingfactoren. Ze maken deel uit van het grotere geheel aan ‘Web vitals’, waarbij deze Core Web Vitals bedoeld zijn om echt op te focussen en mee te laten wegen in de posities in de zoekresultaten.

Er zijn in eerste instantie 3 concrete onderdelen bepaald en meetbaar gemaakt:

  • Largest Contentful Paint (LCP): het moment waarop de eerste echt bruikbare content op je webpagina geladen is
  • First Input Delay (FID): het moment waarop de pagina zover geladen is dat je echt iets kunt uitvoeren op de pagina, zoals scrollen of op een link klikken
  • Cumulative Layout Shift (CLS): verschuivingen op je pagina, waardoor een actie lastig gemaakt wordt of tot een ongewenst resultaat kan leiden

Dit zijn de eerste elementen, er volgen er uiteindelijk meer. Zoals Google aangeeft op Web.dev: “The metrics that make up Core Web Vitals will evolve over time.” Het is dus zaak om deze rankingfactoren in de gaten te blijven houden, al zal Google hier vast ook updates over geven wanneer er nieuwe elementen bij komen.

We nemen de 3 elementen stuk voor stuk door én je krijgt belangrijke details mee voor als je aan de slag wilt gaan met de Core Web Vitals. Details die ik tot nu toe op geen enkele Nederlandse website ben tegengekomen.

Largest Contentful Paint: maximaal 2,5 seconden

De LCP slaat dus op de snelheid waarmee er echt bruikbare content verschijnt zodra iemand je webpagina opent. Of dat nu beeldmateriaal is of tekst, zolang er maar echt duidelijk iets staat waardoor je bezoeker het idee heeft dat er een webpagina staat. Je kunt je vast wel voorstellen dat met name video hier negatieve invloed op heeft. De drempelwaarde (‘threshold’) die Google hiervoor opgeeft is 2,5 seconden. Tot die waarde is het goed, waarna je in de zone ‘te verbeteren’ komt. Bij 4 seconden zit je in de gevarenzone.

Schema van Largest Contentful Paint: tot 2,5 seconden is goed, van 2,5 tot 4 seconden heeft verbetering nodig en boven 4 seconden is slecht.

Je kent het zelf vast wel: een webpagina die opent nadat je op een link geklikt hebt en waarbij je op een gegeven moment toch echt denkt: “duurtlang!” In dat geval is tijd van de LCP dus echt te lang.

Preloader: geeft je het gevoel dat je echt moet wachten voor een webpagina laadt.

Nog even terug naar video: met video kun je best onder de 2,5 seconden blijven hoor, maar blijf het wel in de gaten houden en weet dat dit een risico is. Gebruik video eventueel onder de vouw, zodat het geen invloed heeft op de LCP.

First Input Delay: binnen 100 milliseconden

De First Input Delay (FID) meet hoe snel een actie van een bezoeker op een webpagina wordt uitgevoerd. Denk aan het openen van een andere webpagina nadat je bezoeker op een link klikt of een actie nadat je bezoeker op een button klikt. De scores vind je hieronder weer. Hoef ik het niet weer te typen ;-) .

Schema van First Input Delay: tot 100 milliseconden is goed, van 100 tot 300 milliseconden heeft verbetering nodig en boven 300 milliseconden is slecht.

Het is even logisch als simpel: als iemand iets wil doen op je website, moet dat niet te lang duren. Niemand houdt van lang wachten, dus een snelle verwerking van een actie op een webpagina is meer dan gewenst.

TIP: de basis van deze snelheid ligt bij je hosting. Snelle servers zorgen voor snelle reactie- en laadtijden op je website. En dat gaat natuurlijk ook op voor je Largest Contentful Paint.

Cumulative Layout Shift: onduidelijke meeteenheid

De lastigste van de Core Web Vitals is de Cumulative Layout Shift (CLS). Althans, qua marges. Hiervoor worden de getallen 0,1 en 0,25 gebruikt, maar wat betekent dat nu eigenlijk? Laten we eerst helder hebben wanneer de CLS een probleem is. Dat is wanneer er tijdens het gebruik van je webpagina verschuivingen plaatsvinden in je content (‘layout shift’). De kans dat het gebeurt is klein, maar laat ik een voorbeeld geven dat je misschien wel herkent:

Stel dat op een webpagina een aantal testimonials staat en daaronder staat je contactformulier. Die testimonials wisselen elkaar af in een zogenaamde slider, en omdat de ene tekst wat korter is dan de ander, verschuift alles dat onder die testimonials op de webpagina staat. Daardoor wordt het lastig om het formulier in te vullen en dat is precies de reden waarom de CLS een element is dat meeweegt.

Weg met je slider

Ook sliders in de header passen in dit beeld, al tellen ze niet voor de CLS, omdat de andere content op de webpagina niet verschuift. Toch leveren sliders om zo’n beetje dezelfde reden frustratie op en dat is alle reden om geen sliders op je website te gebruiken.

Nog even een overzicht van de waardes van de CLS, waarbij je je even niet druk hoeft te maken over de berekening:

Schema van Cumulative Layout Shif: tot 0,1 is goed, van 0,1 tot 0,25 heeft verbetering nodig en boven 0,25 is slecht.

Core Web Vitals scores uit ‘field data’

De scores die Google gebruikt zijn zogenaamde ‘field data’, werkelijke gebruikersdata op je website. Een test checkt deze scores puur technisch, wat zogenaamde ‘lab data’ oplevert, maar dat zegt dus niet altijd alles. Lab data en field data kunnen (iets) van elkaar afwijken. Zorg dus dat je vooral die field data in de gaten houdt als het gaat om de Core Web Vitals.

Beoordeling met 75% field data score als basis

De beoordeling van die field data is op ten minste 75% van de scores. Dus wanneer 75% van je bezoekers in de gele score voor LCP, FIP of CLS komt, is je score geel. Dat zal vast ook betekenen dat wanneer 74% een gele score haalt op je webpagina, je helaas in rood zit. Dit is ook de reden waarom je de data uit bijvoorbeeld Google Search Console moet ophalen, omdat die dus die field data ophaalt.

Het nadeel is helaas wel dat Search Console bij lage bezoekersaantallen geen data weergeeft:

Google Search Console feeft aan "Onvoldoende gegevens voor dit apparaattype"en verwijst naar PageSpeed Insights om data voor Core Web Vitals op te halen.

Je hebt dus wel voldoende bezoekers naar je webpagina’s nodig zodat Google die 75% kan wegen.

Mobiele scores zijn bepalend

Allemaal leuk als het goed in orde is op desktop, de scores die tellen zijn de mobiele scores. Bij een goede responsive website zul je daar niet gauw verschil in zien, maar het is niet uitgesloten dat er verschil is tussen mobiel en desktop. Dat betekent ook dat wanneer je bepaalde elementen niet op mobiel vertoont en wel op desktop, je dus goed kunt scoren op de Core Web Vitals, maar je bezoeker op desktop mogelijk wel een minder goede gebruikerservaring heeft.

Page Experience komt ook naar desktop

En terwijl ik dit schrijf maakt Google ook even bekend dat Page Experience ook naar desktop komt. Op 7:10 in de video volgt de aankondiging van Page Experience voor desktop. Veel meer weten we nog niet, maar het verbeteren van je Core Web Vitals helpt je uiteindelijk ook in je scores op desktop. Dus elementen alleen weglaten op mobiel gaat je uiteindelijk niet echt helpen. Als die elementen zorgen voor een negatieve score, haal ze gewoon helemaal weg of zoek er een andere oplossing voor.

Geen AMP meer nodig voor ‘top stories’

Een positief onderdeel van de Page Experience Ranking, zoals Google het zelf noemt (zie je hoe ze het niet als algoritme-update behandelen?) is dat je geen AMP meer nodig hebt om in de ‘Top stories‘ te komen. Vooropgesteld: AMP kan je wel helpen om te voldoen aan de scores voor de Core Web Vitals, maar het is dus niet per se meer nodig om in de Top Stories te komen zodra Page Experience Ranking uitgerold is.

Aanpassingen in de normen

Omdat soms blijkt dat de normen van Googles rankingfactoren te strikt zijn, zo ook bij de Core Web Vitals. Dus past Google de normen voor de scores aan waar dat nodig blijkt te zijn. In 2021 is dat al 2 keer gebeurd: in februari en april. Dat zie je terug in Google Search Console in de sectie Site-vitaliteit.

In Search Console geeft Google bij de grafieken van Site-vitaliteit met een informatiebolletje weer wanneer er iets gewijzigd is. In dit geval zijn in februari en april 2021 wijzigingen in de metrics (oftewel de normen) gewijzigd.

Als je dan doorklikt op ‘Meer informatie’, zie je ook wat er gewijzigd is. Zo zie je dat er op 17 februari 2021 en 13 april 2021 wijzigingen zijn doorgevoerd:

Februari 2021: metrics zijn gewijzigd van 'minder dan' naar 'gelijk aan of minder dan' en in april 2021 zijn de metrics van de layout shifts aangepast.

Kort samengevat:

  • Februari: waar je eerder onder de limiet per onderdeel moest blijven, is de ‘metric’ nu aangepast naar “minder dan of gelijk aan”, zo is er geen onduidelijkheid wanneer je score ‘slecht’, ‘ verbetering nodig’ of ‘goed’ is
  • April: de normen (‘metrics’) voor CLS zijn gewijzigd

Voor wat betreft de wijziging voor CLS verwijs ik je graag naar Web.dev, waar je de details vindt. Wat mij betreft is dit alleen relevant om exact te weten wanneer je echt aan de slag wilt met het verbeteren van je CLS omdat je score (te) laag is. Verder zou ik het ter kennisgeving aannemen, zeker als je scores goed zijn.

Over die scores gesproken:

Groene score? Verder optimaliseren is niet nodig

Een heel belangrijk punt wat niemand je vertelt is dat het niet uitmaakt hoe hoog je score werkelijk is als je in een bepaalde bandbreedte zit. Kort gezegd: rood is rood, geel is geel en groen is groen. Er is geen winst te behalen voor je SEO-score door je LCP van 1,5 naar 1 seconde terug te brengen. Als je groen scoort, is dat wat telt voor Google. Voor je bezoeker is het natuurlijk wel prettig dat die score zo hoog mogelijk is. Als je verder optimaliseert, doe je dat dus voor je bezoeker, wat sowieso de basis moet zijn voor alles op je website.

Verbeteringen: wel direct effect, scores pas later zichtbaar

Wanneer je verbeteringen doorvoert en je daarmee van rood naar geel gaat of van geel naar groen, is een eventueel SEO-effect (vrijwel) direct zichtbaar. De verbeterde score zie je alleen niet direct in Google Search Console (GSC). Omdat GSC zich baseert op gebruikersdata en die iedere 28 dagen ververst worden, zie je dat dus pas na 28 dagen terug in GSC. Voorkom dus teleurstellingen en weet dat je verbeterde scores pas 4 weken later terugziet in Search Console.

Je hoeft niet op alle onderdelen goed te scoren

Het lijkt zo logisch: als er drie onderdelen zijn waarop je beoordeeld wordt, moet je toch op alle drie goed scoren? Bij de Core Web Vitals dus niet. Als je op een van de onderdelen groen scoort, kan dat al een rankingboost geven.

Meer weten? Check dan de Web Vitals Q&A:

Core Web Vitals meten en bijhouden: je kan het zelf

Vanuit Google zijn er tools om te kijken of jouw website voldoet en ook SEO-tools hebben de handschoen opgepakt en Core Web Vitals onderdeel gemaakt van hun site checks. In ieder geval Siteguru* meet deze 3 elementen nu en het kan niet anders dan dat de grote SEO-suites als Ahrefs, Moz en SEMRush dit opnemen in hun site audits. Verder kun je het zelf ook controleren met diverse tools van Google zelf:

Sowieso is het prima om met de informatie vanuit Google Search Console te werken, daar krijg je altijd al veel en duidelijke informatie over je website.

Gratis tools vs. betaalde tools

Betaalde tools maken het je makkelijk, die checken en rapporteren je scores op de Core Web Vitals voor iedere pagina. Bij gratis tools zul je per pagina een test moeten draaien om te achterhalen waar je verbeterpunten zitten. Dat neemt niet weg dat je zelf prima gratis tools kunt gebruiken. In Google Search Console zie je welke pagina’s

*Als enthousiast gebruiker van SiteGuru beveel ik deze tool van harte aan, waarvoor ik een affiliate-vergoeding ontvang. Mijn enthousiasme wordt nooit bepaald door een vergoeding en je krijgt ook altijd de nadelen van mij mee wanneer ik die opmerk. Ook als je mij advies vraagt, raad ik je tools af wanneer ik denk dat ze echt niet voor jou zijn.

Dit is het begin van de Core Web Vitals

Deze 3 onderdelen zijn eigenlijk nog maar het begin van de Core Web Vitals. Google heeft zelf aangegeven dat ze dit zullen blijven doorontwikkelen, dus er kunnen zomaar meer onderdelen bij komen. Er kan ook zomaar van alles aan worden aangepast, zoals de marges waarbinnen je score goed is. Neem in ieder geval -ook voor de toekomst- altijd als uitgangspunt dat wat voor jouzelf onprettig is als gebruiker is, geen goede ervaring is en dus invloed kan hebben op je SEO. Als het maar meetbaar te maken is :-) .

Je hebt nu een goed beeld van wat de Core Web Vitals inhouden. Heb je toch nog vragen, laat het dan zeker even weten. Heb je iets aan te vullen of ken je een tool die ook de scores meet, laat het dan ook weten in de reacties.

De afbeeldingen van de Core Web Vitals zijn afkomstig van web.dev.

0 antwoorden

Plaats een Reactie

Meepraten?
Draag gerust bij!

Geef een antwoord

You have to agree to the comment policy.

Deze website gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.