Core Web Vitals

Je websiteranking verbeteren met Core Web Vitals

Je wilt je website optimaal maken om zo goed mogelijk vindbaar te zijn. Dat Google hiervoor kijkt naar de gebruikservaring, of ookwel page experience, is geen geheim. Dit neemt het algoritme mee in het bepalen van de rankings van pagina’s. Hieronder vallen meerdere (technische) onderdelen. In 2021 komen hier drie onderdelen bij. Deze worden de Core Web Vitals of ookwel Site Vitaliteit genoemd. Maar wat is dit eigenlijk en waarom is dit belangrijk?

De Core Web Vitals

Onder Core Web Vitals vallen het laden, de snelheid tot interactiviteit en de visual stability van een webpagina. Deze onderdelen zijn onder de volgende benamingen terug te vinden in verschillende rapporten: Largest Contentful Paint (LCP), First Input Delay (FID) en Cumulative Layout Shift (CLS). Niet alleen gaan we deze drie bespreken, wij leggen ook graag uit hoe je kan uitzoeken wat dit veroorzaakt.

Onderdelen Page Experience Google
De verschillende onderdelen van die volgens Google invloed hebben op de page experience

Hoe belangrijk zijn de Core Web Vitals?

Dus je bent eindelijk na veel tijd en moeite bij met de optimalisatie van de website om zo hoog mogelijk in de zoekresultaten te komen. En nu komt Google opeens weer met nieuwe scores. Is dat het nu waard om direct mee aan de slag te gaan? Of is het niet erg om dit een keertje te missen? Laten we kijken naar hoe de prestatiescore van PageSpeed Insights, een tool van Google, wordt berekend.

Verdeling Lighthouse performance meting
De invloed van de verschillende metingen op de kwaliteitsscore

Op de bovenstaande afbeelding is de invloed van onderdelen op de score af te lezen. Het is duidelijk dat de LCP met 25% voor een groot percentage meetelt en de CLS relatief een stuk minder met 5%. Deze tool neemt de FID niet expliciet mee. Wanneer tools dit niet meenemen kan de tegenhanger Total Blocking Time (TBT). Ook de TBT heeft een sterke invloed op de score met ook weer 25%.

Largest Contentful Paint

Om de laadprestaties te meten is Largest Contentful Paint (LCP) in het leven geroepen. Dit is een nieuwere prestatiestatistiek die gebruiksgerichter is dan oudere statistieken zoals load of DOMContentLoaded. Google zegt met de Largest Contentful Paint een nauwkeurige manier gevonden te hebben om te meten wanneer het hoofdinhoud van een pagina geladen is. Dit is op basis van het grootste element op deze webpagina. Zie de afbeeldingen hieronder voor een beeld van wat de LCP inhoudt.

Largest Contentful Paint voorbeeld 1
De LCP wordt ingeladen voordat de gehele pagina geladen is.
Largest Contentful Paint voorbeeld 2
De LCP wordt uitgesteld ingeladen. Hierdoor verschuift ook wat Google ziet als het grootste element tijdens de totale laadtijd.
Largest Contentful Paint scores
De schaal waarop de laadtijd van de LCP gescoord wordt.

In het kort is de LCP dus het grootste tekst- of afbeeldingselement dat zichtbaar is in de viewport. Het streven is dat dit binnen de 2,5 seconden is. Dit betekent dat het element wat als de Largest Contentful Paint gezien wordt binnen 2,5 seconden vanaf het laden van het eerste zichtbare gedeelte van de pagina van op de scherm van de gebruiker moet verschijnen.

First Input Delay

De meeste mensen zullen bekend zijn met het gezegde: ‘You never get a second chance to make a good first impression’. Hoewel de eerste indruk vaak in context wordt gebracht bij het ontmoeten van mensen is dit niet minder waar bij websites. En weinig dingen maken een slechtere indruk bij bezoekers dan een website die niet snel interactief en daarmee bruikbaar is. Dit is hiermee ook logischerwijs slecht voor de gebruikservaring. 

De First Input Delay, of ook wel ‘eerste invoervertraging’, helpt met het meten van de tijd tussen dat de website zichtbaar is en dat deze interactief is. Dit is ook wel de tijd vanaf de eerste gebruikersinteractie met de webpagina tot de tijd wanneer de browser reageert op die interactie. Voorbeelden van interacties zijn het klikken op een link, tikken op een knop etc. Google heeft besloten dat dit onder de 100 milliseconden moeten blijven om een positieve ervaring te behouden.

First Input Delay scores
De schaal waarop de FID gescoord wordt.

Cumulative Layout Shift

Misschien wel de meest mysterieuze term van de drie: de Cumulative Layout Shift. De nederlandse versie van de term, cumulatieve indelingsverschuiving maakt het al iets duidelijker. Dit staat voor de mate waarin de indeling van de elementen op de pagina verschuift. Dit gebeurt bijvoorbeeld wanneer elementen of de inhoud hiervan later geladen worden en hiervoor geen ruimte ‘gereserveerd’ is. 

Waarom vindt Google zoiets nou belangrijk? Zoals eerder besproken beïnvloeden de verschillende Core Web Vitals de gebruikerservaring. Het verschuiven van elementen zal voor de meeste mensen in de top 3 staan van grootste irritaties online. Denk aan een knop die plotseling verplaatst waardoor je erop klikt en de pagina verlaat of een pop-up die opeens de tekst die je aan het lezen was blokkeert. Google erkent dit en neemt dit daarom mee in het algoritme.

Hoe werkt CLS?
Het verschuiven van elementen kan voor een slechte gebruikservaring zorgen. Een van de manieren om CLS te voorkomen is om plaatst reserven voor content.
Cumulative Layout Shift scores
De CLS scores op basis van de status waarin die gecategoriseerd wordt.

De CLS wordt anders gemeten dan de vorige twee metrics. De score is op basis van een schaal tussen 0 tot en met 1. Hierbij is hoe lager hoe beter, maar boven de 0,25 wordt de CLS al als slecht gerekend. De test neemt alleen de onderdelen mee die in het zicht van de gebruiker zijn.

Core Web Vitals meten

Als het goed is het duidelijker wat de Core Web Vitals zijn. Nu is het van belang om te checken wat de staat is van de site vitaliteit van jouw website. Google heeft haar tools al geupdate om de nieuwe metrics mee te nemen. Natuurlijk komen de statistieken ook steeds vaker voor in tools van derde partijen. Mijn voorkeur gaat altijd uit naar Search Console en PageSpeed Insights, hiermee krijg je alle informatie straight from the source.

Google Search Console

Veel functionaliteiten van Search Console zijn al in een eerdere blog uitgelegd. Site-vitaliteit is namelijk maar een klein onderdeel van alle mogelijkheden die de tool biedt. De tool wordt gebruikt voor het verbeteren van de vindbaarheid van websites. Het onderdeel voor de Core Web Vitals is te vinden onder ‘Site-vitaliteit‘ in het menu.

Google Search Console Site-vitaliteit
Site-vitaliteit: het onderdeel in Google Search Console waarin de scores voor de gebruikservaring terug kan worden gevonden.

Search Console checkt automatisch alle URLs op de Core Web Vitals. De URLs en scores worden weergegeven in twee grafieken. De URLs zijn opgesplitst op basis van device (mobiel of desktop). Deze geven de status aan van verschillende URLs van de website. URLs worden in drie categorieën geplaatst:

  • Slecht
  • Verbetering nodig
  • Goed

Bij de grafieken is het ook belangrijk om de trend in de gaten te houden. Wanneer je dit rapport opent wordt een overzicht weergeven. Hier zijn de URLs opgedeeld per metric én status. 

Search Console site vitaliteit overzicht
Een overzicht van de scores binnen Search Console met het aantal getroffen URLs.

Wanneer je doorklikt wordt binnen het overzicht de URLs met het probleem weergeven. Vergelijkbare URLs worden bij elkaar geplaatst omdat de veronderstelling is dat deze pagina hetzelfde probleem zullen hebben. Uit deze groep kunnen (maximaal) 20 URLs als voorbeeld worden weergeven wanneer hierop doorgeklikt wordt. De gegeven score is op basis van 75% van de bezoekers die een van deze URLs bezoekt.

De Google Search Console URL details
Het scherm met de details zoals het aantal getroffen URLs en de score hiervan. In dit geval van de LCP.

PageSpeed Insights

Deze tool maakt rapporten op basis van performance van de ingevoerde URL. In deze rapporten staan niet alleen scores maar ook adviezen over hoe deze scores verbeterd kunnen worden. Omdat scores kunnen verschillen tussen de mobiele en desktop versie worden twee afzonderlijke rapporten gemaakt.

Wanneer de Core Web Vitals deel uitmaken van een grotere analyse en/of Search Console niet beschikbaar is, is PageSpeed Insights een praktische tool om dit te checken. Houdt wel rekening ermee dat deze tool alleen kijkt naar de pagina die je invoert. Wel geeft deze tool meer informatie over de webpagina. Met deze informatie kan weer gemakkelijker een oplossing gevonden kunnen worden. Ook deze tool bekijkt de mobiele en desktop versie afzonderlijk van elkaar.

PageSpeed Insights maakt onderscheidt in lab- en fieldgegevens. Fieldgegevens worden berekend aan de hand van de daadwerkelijke statistieken die de afgelopen 28 dagen zijn verzameld. De labgegevens komen vanuit een gecontroleerde omgeving. Doordat dit andere manieren van meten zijn, is het mogelijk dat de scores afwijken

Google PageSpeed Insights Labgegevens
Een voorbeeld van labgegevens
Google PageSpeed Insights Fieldgegevens
Een voorbeeld van fieldgegevens

Het probleem identificeren 🔍

We hebben eerder al besproken hoe gekeken kan worden wat de huidige status de verschillende pagina’s zijn. Echter houdt het daar niet op. Gelukkig kan in de meeste gevallen ook opgespoord worden waar de negatieve scores vandaan komen.

LCP en CLS

De LCP en CLS kan gemakkelijk via de Chrome DevTools worden opgespoord. Hieronder een korte stappenplan om de meting te starten en details te bekijken.

  • Open de tool door met de rechtermuisknop op een webpagina te klikken en dan naar inspecteren te gaan. 
  • Verander eventueel linksboven het device waar je de meeting van wilt maken.
  • Start bij het tabje performance een nieuwe meting door middel van het rondgaande (reload) pijltje
De manier om LCP en CLS te meten
Een overzicht van het tabblad performance binnen de Chrome DevTools.
  • Klik voor meer informatie op de statistiek. Hierdoor wordt het onderste paneel gevuld. Hier kan onder andere de score gevonden worden.
  • Door de muis op de statistiek te houden wordt het element die dit veroorzaakt weergeven ook visueel gemarkeerd door middel van een blauw vlak. Wanneer deze niet of slecht weergeven wordt kan in de onderste paneel ook gekeken worden naar related node. Hier staat de naam van het element. Dit is de naam zoals het element ook heet als in de code.

Zie de afbeeldingen hieronder voor de stappen uitgevoerd voor de Largest Contentful Paint en Cumulative Layout Shift.

In Lighthouse de LCP opzoeken
De LCP van de voorbeeldpagina.
In Chrome DevTool de CLS opzoeken
De grootste veroorzaker van de CLS op de voorbeeldpagina.

Let op: De LCP is altijd zichtbaar in de meeting. Dit betekend niet dat deze een negatieve score veroorzaakt. De CLS is niet altijd zichtbaar omdat dit in sommige gevallen niet plaatsvindt. Wanneer dit wel zo is hoeft dit niet te beteken dat deze te hoog scoort. Dit moet nog los bekeken worden door een van de eerdere tools of dit af te lezen in de details die zichtbaar worden door op de statistiek te klikken. 

FID

De First Input Delay kan niet gemeten worden met de eerder besproken Chrome Devtool. De FID wordt namelijk berekend aan de hand van het daadwerkelijk gebruik van een websitebezoeker. De Chrome DevTool werkt met een simulatieomgeving (Lab). In deze omgeving wordt gebruik gemaakt van de statistiek Total Blocking Time. Dit is de tegenhanger van FID en kan hiermee vervangen worden. Google geeft aan dat het verbeteren van de TBT ook moet leiden aan het verbeteren van de FID.

Oplossingen voor een hoge TBT zijn bijvoorbeeld het verwijderen van ongebruikte JavaScript of deze opknippen in kleinere onderdelen. Maar voordat dit kan gebeuren is het belangrijk hier inzicht in te krijgen. Dit kan in dezelfde omgeving die net besproken is, maar dan wel in een ander tabblad. Dit is het tabblad sources.

Hoe meet je de FID
Een overzicht van het tabblad sources binnen de Chrome DevTools.
  1. Open de Chrome DevTools. Doe dit door de rechtermuisknop te gebruiken op de website en naar inspecteren te gaan.
  2. Ga naar het tabblad sources.
  3. Als het vak onderaan niet geopend is kan deze worden geopend door te klikken op ‘Coverage n/a’. Dit is onderaan de middelste kolom te vinden.
  4. Klik op de ronddraaide pijl (reload) links bovenaan in het onderste vak om de meting te starten.

In de meting is niet alleen de JavaScript/CSS zichtbaar, maar ook per onderdeel hoe groot dit is en hoeveel daadwerkelijk hiervan gebruikt wordt. Wil je dit in meer details zien? Klik dan op een URL in de lijst onderaan. In de middelste kolom wordt dan aangegeven welke specifieke lijnen in de code wel of niet gebruikt worden. Zie de afbeelding hieronder voor een voorbeeld van deze weergave.

Instructie ongebruikte JavaScript opzoeken
Voorbeeld van een gedetailleerd overzicht van de wel en niet gebruikte lijnen van de JavaScript/CSS binnen de broncode. Hierbij zijn de lijnen met rood ervoor niet gebruikt.

De smaak te pakken?

Een optimale website moet voldoen aan veel eisen. Hiervoor moet je veel stappen doorlopen. Dit is meer dan alleen het meten van de Core Web Vitals. Weet je niet waar je moet beginnen? Onze technische SEO checklist helpt je op weg!

Share on facebook
Share on twitter
Share on linkedin
Share on pinterest
Share on skype
Categories
Scroll to Top

Deze website gebruikt cookies om je de best mogelijke ervaring te bieden.