Core Web Vitals

SEO Sight Core Web Vitals

Written by Ryan

01/07/2020

Introductie

Google heeft onlangs een live stream evenement gehouden waarin ze allerlei web ontwikkelingen bespreken. Dit evenement, Web.dev Live 2020 duurde drie dagen lang waarbij belangrijke seo specialisten en ontwikkelaars de revue passeerden.

 

Google Web.dev Live 2020

 

Op de eerste dag werden een aantal onderwerpen besproken. Daarvan was Core Web Vitals een belangrijke onderdeel van en waar deze blogpost ook over gaat.

Op 5 mei 2020 heeft Google de Web Vitals geintroduceerd. Core Web Vitals kun je beschouwen als de volgende evolutie in het nastreven van een goede gebruikerservaring als het gaat om het bezoeken van websites. Hoe Core Web Vitals dit doet wordt hieronder verder uitgelegd.

 

 

 

Wat is Core Web Vitals

 

Google definieert Core Web Vitals als volgt:

 

“Het is een verzameling van gebruikersgerichte statistieken en drempelwaardes  (threshold) die van toepassing zijn op alle webpagina’s in alle branches en alle soorten ervaringen op het web.”

 

Ze zijn signalen voor ontwikkelaars en stakeholders c.q. belanghebbenden over de basisgezondheid van uw site. En als zodanig moeten ze door iedereen worden gemeten.”

 

Maar er zijn al een hele hoop metrices die gemeten worden. Waarom is Core Web Vitals ineens belangrijk geworden?

 

Het belang van Core Web Vitals

 

Zoals in de voorgaande paragraaf is genoemd zijn er al een hoop metrices die gemeten worden en inzicht geven in de prestaties en kwaliteit van websites. Denk aan snelheid van de website zelf, de tijd die nodig is om een website te laden, veiligheid bij het surfen etc . Waarom dan nog eens Core Web Vitals?

 

 SEO Sight Website-scherm-banner_24b

 

 

Zoals in een andere blogpost wordt genoemd heeft Google als doel om haar gebruikers een goede gebruikerservaring te geven. Als mensen de zoekmachine van Google gebruiken dan wil Google de beste resultaten tonen die antwoord geven op de vragen die mensen stellen. Vandaar dat Google constant bezig is om haar zoekalgoritmes te verbeteren.

 

Google verwoord het als volgt:

We willen een buitengewoon fenomenale ervaring creëren voor al onze gebruikers.

 

Elke keer dat ze een gebruiker hebben die ontevreden is of gefrustreerd over het Internet betekent dat voor Google dat ze een lezer, klant of client verliezen. Daarnaast is een goede gebruikerservaring voor Google een verdienmodel daar zij onder andere via advertenties hun geld mee verdienen.

 

 

Het probleem met websites van nu

 

Dagelijks komen er miljoenen websites bij die steeds meer en meer content aanbieden. Video’s, muziek, podcasts, blogposts etc. Daarnaast worden de websites steeds geavanceerder qua functionaliteit en qua vormgeving uitdagender en interactiever. Om dit mogelijk te maken wordt er gebruik gemaakt van programmeertalen zoals Javascript, html en css.

Het toevoegen van functionaliteiten maakt dat websites steeds zwaarder worden. Dat betekent meer code die over de lijn gestuurd moet worden om de website op jouw scherm tevoorschijn te toveren. Hoewel de websites dus meer functionaliteiten bevat en gelikter uitzien betekent het wel dat ze ook qua snelheid inboeten.

 

 Website Speed

 

 

Dus Google stelde zichzelf als doel om te kijken of ze het web kunnen verbeteren. Om dat te doen moet je kunnen meten wat belangrijk is om zo te achterhalen of je vooruitgang boekt.

De vraag die ze zichzelf stelden was dan ook:  “Wat maakt een geweldige web ervaring?”

 

 

Core Dimensions of Quality

 

Wat betekent kwaliteit als het gaat om web ervaring? Welke fundamentele elementen bepalen of een website een geweldige gebruikerservaring gaat geven?

Een aantal kenmerken die genoemd worden:

Content moet snel geladen zijn

Gebruikers willen niet wachten totdat content geladen is. Als een website niet binnen 4 secondes geladen is dan zullen je bezoekers je website verlaten.

 

Interactiviteit is belangrijk

Je bent op een website en je klikt of veegt links of rechts maar er gebeurt niets. Dat is natuurlijk niet fijn en je gaat twijfelen of de website het wel doet. Content moet niet alleen zichtbaar zijn maar je  moet er ook wat mee kunnen doen.

 

Pagina moet stabiel en voorspelbaar zijn

Je herkent het vast wel. Je bent op een pagina wat aan het lezen en ineens verspringt de tekst naar beneden. Of er komt ineens een afbeelding of video in beeld die alles wegdrukt met waar je mee bezig was. Dat is hinderlijk en zorgt voor frustraties. Want je kunt ongewild ineens op de verkeerde knop kunnen drukken.

 

 Deze drie factoren bepalen de Core Dimensions of Quality. De kern factoren die bepalend zijn voor kwaliteit.

 

 

De parameters van quality dimensions

 

Voor het meten van deze drie factoren heeft Google een drietal bijbehorende termen in het leven geroepen. Dit zijn:

 

LCP – Largest Contentful Paint

FID – First Input Delay

CLS – Cumulative Layout Shift

TBT – Total Blocking Time

 

We zullen elk van deze termen hieronder bespreken en daarbij aangeven wat goede kengetallen zijn om na te streven. 

Hoe belangrijk zijn deze kwaliteitsfactoren? Google stelt dat van de honderd web sessies die je website ontvangt moeten 75 daarvan goede cijfers overleggen om als een kwalitatief goede en gezonde website te worden gekenmerkt.

Andere factoren die een belangrijke rol spelen zijn toegankelijkheid, veiligheid en mobiel vriendelijk. Ook zij hebben volgens Google invloed op de algehele gebruikerservaring die mensen hebben als ze een website bezoeken.

 

 

LCP – Largest Contentful Paint

 

LCP beschrijft hoe snel een webpagina geladen is. Oftewel hoe snel een gebruiker de webpagina daadwerkelijk kan zien en of dat overeenkomt met wat zij verwachtte.

Google stelt dat je goed op weg bent als je LCP 2.5 secondes of lager is. Als het tussen 2.5 en 4 secondes ligt zul je verder moeten finetunen. Alles boven 4 secondes betekent dat er echt werk te verrichten valt.

 

 

 

 

 

FID – First Input Delay

 

FID beschrijft hoe lang het duurt voordat een webpagina reageert op interactie van een gebruiker. Het kan wel zijn dat een webpagina geladen en zichtbaar is maar dat het soms nog even kan duren voordat je er wat mee kunt.

 

 

web vitals FCP

 

 

 

CLS – Cumulative Layout Shift

 

De cumulatieve verschuiving van de layout meet hoeveel elementen van een webpagina verschuift tijdens het laden van de webpagina. Doordat mensen met verschillende apparaten surfen op het Internet en webpagina’s die dynamisch opgebouwd worden moeten webbrowsers aanpassingen doen wanneer ze de webpagina laten zien.

 

 

web vitals CLS

 

 

 

TBT – Total Blocking Time

 

De Total Blocking Time (TBT) -metriek meet de totale tijd tussen First Contentful Paint (FCP) en Time to Interactive (TTI) waarbij de sessie lang genoeg werd geblokkeerd om respons op invoer te voorkomen.

Een sessie kan bestaan uit een of meerdere opeenvolgende taken. Wanneer een pagina traag is of schokkerig aanvoelt kan dat duiden op geblokkeerde taken.

Web Vitals TBT - Total Blocking Time

De afbeelding laat zien dat er 5 taken zijn waarbij taak 1, 2 en 5 verwerkingstijd hebben wat de sessie blokkeert. De TBT is de som van al deze momenten.

 

Aan de slag met Core Web Vitals

 

Nu we weten waar je jouw website verder op kunt verbeteren moet je ook gereedschap hebben om deze 3 elementen te kunnen meten. Google maakt dit voor je mogelijk op een aantal verschillende manieren. Allereerst door middel van RUM data vergaring of het gebruiken van tools die Google ter beschikking stelt.

 

RUM data

Het begint met RUM data vergaren. Nee daar wordt niet het drankje mee bedoeld. RUM staat voor “Real User Monitoring” en bevat gegevens van echte gebruikers die jouw website bezoeken. RUM data is ook dat wat Google gebruikt om te bepalen of je website voldoet aan de maatstaven van Core Web Vitals.

 

 

 Monitis omschrijft het als volgt:

Real User Monitoring is een vorm van webmonitoring die alle interacties van eindgebruikers met een website of een applicatie op een veel gedetailleerder niveau vastlegt en zich verdiept in statistieken waar de gemiddelde gebruiker waarschijnlijk nog nooit van heeft gehoord. Deze analyse omvat gebeurtenissen als DNS-resolutie, tijd voor TCP-verbinding, onderhandeling over SSL-codering, verzending via de eerste byte, navigatiedisplay, tijd voor het renderen van pagina’s, segmenten buiten de TCP-volgorde en denktijd voor gebruikers.

 

RUM data geeft de beste weergave van hoe je website het doet. Het laat op een gedetailleerde manier en met directe feedback zien hoe je website presteert. Het loont dus de moeite om RUM te op te zetten.  

 

 

RUM vs Google Analytics

 

Velen zullen vaak Google Analytics (GA) geinstalleerd hebben op hun website voor analyse. Echter, RUM en GA verschillen nogal van elkaar omdat zij verschillende doelen hebben.

 

Waar GA vooral gebruikt dient te worden is het verzamelen en analyseren van web data ten behoeve van SEO, lead generatie en conversie tracking. Het verbeteren van de algehele marketing van de website zowel technisch als inhoudelijk.

RUM daarentegen richt zich meer op het vinden van de kern van prestatie problemen die gebruikers kunnen ervaren. Dit kan zijn van lange laadtijden van webpagina’s, welke veroorzaakt kan worden door de browser, netwerk, server of de inhoud die binnengehaald moet worden en veel tijd nodig heeft om verwerkt te worden. Misschien speelt de geografische lokatie een rol? Welke impact heeft al deze zaken op de service level agreements (SLA)?

 

Er zijn nog een aantal andere aspecten waarin RUM verschilt van Google Analytics. Voor meer informatie kun je dit hier lezen:

Bron: https://www.monitis.com/blog/6-ways-real-user-monitoring-differs-from-google-analytics/

 

 

 

Web Vitals Tools

Indien je geen RUM hebt geïnstalleerd dan kun je de tools die hierna volgen gebruiken om toch inzicht krijgen in de werkelijke prestaties van je website. 

Hier een handig overzicht welke tools er zijn om de web vital rapportages mee te maken:

 

 Core Web Vitals-Tools

 

Web.dev/measure

 

De makkelijkste manier om inzicht te krijgen in de prestaties van je website kun je zien door naar de URL hieronder te gaan.

 

https://web.dev/measure/

 

 

web.dev-measure-nu.nl-top_metrics

 

 

Vul de URL in die je wilt onderzoeken. Wacht 20-30 secondes en je krijgt een overzicht te zien van:

  • Indicatie Prestaties
  • Toegankelijkheid
  • Best Practies
  • SEO

 

Daarnaast zie je ook de meetwaarden voor:

  • First Contentful Paint (FCP)
  • Speed Index
  • Largest Contentful Paint (LCP)
  • Time to Interactive (TTI)
  • Total Blocking Time (TBT)
  • Cumulative Layout Shift (CLS)

 

De tool geeft tevens aan op welke vlakken je het e.e.a. kunt verbeteren. Daarbij wordt er een onderscheid gemaakt in de impact (van hoog naar laag), de categorie (bv prestatie, toegankelijkheid etc.), waar het specifiek betrekking op heeft en een link naar meer informatie erover.

 

 

 

PageSpeed Insights

PageSpeed Insights rapporteert over de totale prestaties op paginaniveau en bronniveau in de afgelopen 28 dagen. Daarnaast geeft het suggesties om de prestaties te verbeteren. Als je op zoek bent naar een enkele manier om aan de slag te gaan met het meten en verbeteren van de web core vitals van je sit dan raad Google aan om PSI te gebruiken. PSI is beschikbaar via het Internet en als API.

 

 

PageSpeedInsights - nu.nl 

 

 

 

CrUX – Chrome User eXperience Report

CrUX-dashboard is een vooraf gebouwd dashboard dat CrUX-gegevens weergeeft voor een bron c.q. apparaat naar keuze. Het is met behulp van Google Data Studio gebouwd en het installatieproces duurt ongeveer een minuut. Vergeleken met PageSpeed Insights en Search Console bevat CrUX-dashboardrapportage meer dimensies. Gegevens kunnen bijvoorbeeld worden uitgesplitst naar apparaat en verbindingstype. Het voordeel met de CrUX is dat je de meetresultaten over een bepaalde tijd kunt bezichtigen.

Je kunt toegang krijgen tot je eigen CrUX via Google Data Studio via de volgende link:

 

https://g.co/chromeuxdash

Video hoe je de Chrome UX Dashboard instelt:

 

https://www.youtube.com/watch?v=DmFWL-O7EwA

Voorbeeld van de dashboard:

The monthly distribution of form factors for     developers.google.com 

 

 

 

 

Search Console

Search Console geeft prestatiegegevens per pagina weer. Dit maakt het zeer geschikt voor het identificeren van specifieke pagina’s die verbeterd moeten worden. In tegenstelling tot PageSpeed Insights bevat Search Console-rapportage historische prestatiegegevens. Search Console kan alleen worden gebruikt met sites waar jij eigenaar of beheerder van bent en waarvan de eigendom is geverifieerd.

Je vindt de Core Web Vitals optie aan de linkerkant van het scherm onder het kopje “Enhancements.”

 

 

 Google-Search-Console_sidebar Core Web Vitals

 

 

 

 

 

 

Chrome DevTools

 

Je kunt de Core Web Vitals report terugvinden in de Chrome Web browser. De stappen die je moet nemen om dat te doen wordt in het volgende hoofdstuk “Lighthouse Lab Data” verder uitgewerkt.

 

 

Lighthouse

 

Lighthouse rapporteert over LCP, CLS en TBT en benadrukt ook mogelijke prestatieverbeteringen. Lighthouse is beschikbaar in Chrome DevTools, als een Chrome-extensie en als een npm-pakket. Lighthouse kan ook worden geïntegreerd in workflows voor continue integratie via Lighthouse CI. Lighthouse is tevens beschikbaar in Firefox webbrowser.

 

Lighthouse vind je in de Audit-paneel van Chrome DevTools. Een rapport uitvoeren doe je als volgt:

  1. Download Google Chrome voor desktop als je die nog niet hebt.
  2. Ga met Google Chrome naar de site URL die je wilt controleren. Je kunt elke URL op het Internet controleren. Let wel dat je maar 1 tabblad hebt openstaan naar dezelfde website.
  3. Open Chrome Developers Tools (Win: ctrl+shift+i)
  4. Klik op het tabblad Lighthouse.

 

 

Voorbeeld van Lighthouse in Chrome:

 

The Audits panel of Chrome DevTools

 

05. Developer Tools toont u een lijst met controlecategorieën. Laat ze allemaal ingeschakeld.
06. Klik op “Generate report”.
07. Na 30 tot 60 seconden geeft Lighthouse je een rapport op de pagina.

 

A Lighthouse report in Chrome DevTools

 

 

 

 

Web Vitals Chrome Extension

De Chrome-extensie Web Vitals meet en rapporteert de Core Web Vitals (LCP, FID en CLS) voor een bepaalde pagina. Deze tool is bedoeld om web ontwikkelaars realtime prestatiefeedback te geven terwijl ze codewijzigingen aanbrengen.

 

Deze plugin kun je downloaden van de Google Chrome Extension webstore via de link hieronder.

https://chrome.google.com/webstore/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk

Nadat je de plugin hebt geïnstalleerd zal rechtsboven een vuurtoren-icoon in je browser verschijnen.

 

Een audit te draaien doe je als volgt:

 

01. Ga naar de URL of site waar je een audit voor wilt doen.

02. Klik op de vuurtoren-icoon en een scherm zal uitklappen zoals de afbeelding hieronder.

 

The Lighthouse extension

 

03. Klik op “Generate report”

04. Wacht 30-60 secondes voor het resultaat. Een nieuwe tabblad met de resultaten zal geopend worden.

 

The Lighthouse report

 

Heb je in het verleden al eens een audit report gedraaid en wil je daar de resultaten van terugzien? Dat kan.

Je gaat naar de URL hieronder en upload de json of voert de GIST url in.

https://googlechrome.github.io/lighthouse/viewer/

 

 

WebPageTest

 

WebPageTest bevat Core Web Vitals als onderdeel van de standaardrapportage. WebPageTest is handig voor het verzamelen van informatie over Web Vitals onder bepaalde apparaat- en netwerkomstandigheden.

 

WebPageTest - Web-Vitals

 

Een voordeel van WebPageTest is dat deze de test drie keer uitvoert om zo een gemiddelde te berekenen. Daarnaast laat WebPageTest een waterfalmodel zien van de laadtijd van de diverse elementen die geladen worden.

Hiermee kun je achterhalen welke elementen de meeste tijd kost en eventuele blokkades.

 

 

WebPageTest - Waterfall

 

 

Bron: https://web.dev/vitals-measurement-getting-started/

 

Al met al zijn er legio manieren om web vitals statistieken op te vragen via diverse tools. De beste manier is om verschillende tools te gebruiken waarbij je rekening houdt met de bron van waaruit je de web vitals data opvraagt. Zo zal de web vitals data vanuit je eigen web browser ietwat anders zijn dan wanneer je RUM data hebt.

In het volgende hoofdstuk gaan we kijken wat de mogelijkheden zijn wat betreft het verbeteren van je LCP, FID en CLS. 

 

Het verbeteren van je Core Web Vitals

 

Nu je een aantal tools in handen hebt om de Core Web Vitals te meten van je website is het nu de vraag hoe kun je nu je website verbeteren? We zullen elke factor de revue passeren en aangeven hoe je deze kunt optimaliseren.

 

 

 

 

 

LCP optimaliseren

 

LCP oftewel Largest Contentful Paint beschrijft hoe lang het duurt voordat er wat zichtbaar is op het apparaat waarmee je een website of pagina bezoekt.

 

Web vitals LCP

 

 

De meest voorkomende oorzaken van een slechte score op LCP komt door:

 

Mijn eigen ervaring wat betreft (WordPress) web optimalisatie is dat je veel winst kunt behalen met  het aanpakken van de lange laadtijd van de webserver.

Je kunt bijvoorbeeld de htaccess file optimaliseren. Denk aan redirect van SSL of het invoegen van caching tijd voor de diverse content die je gebruikt. Daarnaast gebruik maken van een CDN (content delivery network) die als een soort caching fungeert tussen de webserver en de webgebruiker.

Een andere manier wat veel winst op zal leveren is het optimaliseren van je content. Doordat websites steeds meer multimedia bevat kan het gebeuren dat we te grote afbeeldingen gebruiken. Door ze te verkleinen of een betere compressietechniek kan er veel winst gehaald worden.

Voor een overzicht van LCP specifieke optimalisaties kun je hier terecht:

https://web.dev/optimize-lcp/

 

Voor wat algemene web optimalisatie tips kun je het een en ander hier vinden:

https://www.youtube.com/playlist?list=PLNYkxOF6rcICVl6Vb-AFlw81bQLuv6a_P

.

 

FID optimaliseren

 

First Input Delay beschrijft hoe lang het duurt voordat een webpagina reageert op interactie van een gebruiker. Het geeft een indruk hoe iemand een website ervaart als het gaat om interactiviteit en reactievermogen.

 

Web vitals FID

 

 

De voornaamste oorzaak van een lange FID komt door het gebruik van veel en zware Javascripts. Met Javascript kun je fantastische dingen doen en je website allerlei extra mogelijkheden geven. Echter, vanuit een gebruikersperspectief moet je je afvragen of dat wel nodig is of puur vanwege een gimmick.

Het gebruik van Javascript betekent dat je apparaat deze net als elk programmeertaal het een en ander moet verwerken. Is bijvoorbeeld je computer of smartphone niet zo snel of draaien er op de achtergrond nog vele andere processen dan heeft dit impact hoe snel de website op iemands apparaat reageert.

De winst die je kunt behalen is door Javascript gebruik te minimaliseren of indien noodzakelijk de taken in Javascript op te delen. Wellicht hoeven niet alle taken synchroon verwerkt te worden maar kunnen delen ook asynchroon gedaan worden.

 

Voor meer informatie kun je dit hier lezen: 

https://web.dev/optimize-fid/

.

 

CLS optimaliseren

 

De Cumulative Layout Shift meet hoeveel elementen van een webpagina verschuift tijdens het laden van de webpagina.

 

Web vitals CLS

 

Verschuivingen van elementen op een webpagina, nadat deze is geladen of op het moment dat er interactie mogelijk is voor de gebruiker, is erg hinderlijk. Het kan ervoor zorgen dat er op verkeerde knoppen worden gedrukt of andere onverwachte bedoelingen.

Popups is bijvoorbeeld een goed voorbeeld waarbij je scherm ineens wordt overgenomen door een script terwijl de gebruiker dat zelf niet initieerde.

 

De meest voorkomende oorzaken van een slechte CLS zijn:

  • Afbeeldingen zonder afmetingen gedefinieerd
  • Advertenties, insluitingen en iframes zonder afmetingen
  • Dynamisch geïnjecteerde inhoud (denk aan pop ups)
  • Weblettertypen die FOIT / FOUT veroorzaken
  • Acties die wachten op een netwerkreactie voordat DOM wordt bijgewerkt

 

Voorbeeld van een afbeelding zonder afmetingen gedefinieerd:

 

 

No Image Dimension

 

Je voorkomt dit door de afmetingen te definieren zoals hier:

<img src="foto.jpg" width="640" height="360" alt="Foto">

 

Tegenwoordig gebruikt men web builders, zoals Divi en Elementor, die dit automatisch toevoegen. Toch is het goed om hierop te letten indien je de web pagina’s met de hand bouwt.

 

Een andere tip die Google adviseert is om van te voren ruimtes vrij te houden voor de advertenties en andere stukken die later in de pagina dynamisch toegevoegd worden. Hierdoor zullen geen verplaatsingen meer gebeuren en blijft de pagina qua layout hetzelfde.

 

Men adviseert ook geen content toe te voegen bovenop reeds bestaande en geladen content. Dit zorgt namelijk voor verschuivingen vanaf de bovenkant. Het toevoegen van content aan de onderkant is de aangewezen manier.

 

Web fonts die later worden toegepast op de reeds geladen tekst is wat men vaak tegenkomt bij trage verbindingen. Ook dit kan een verschuiving van de layout veroorzaken. De manier om dit te voorkomen is door ervoor te zorgen dat de Web fonts bij de gebruiker al geladen zijn voordat de webpagina opgebouwd wordt.

 

Voor meer tips over het optimaliseren van de CLS kun je hier vinden:

 

https://web.dev/optimize-cls/

 

 

Samenvatting

 

Web vitals is een belangrijke stap naar een meer robuste en verhoogde gebruikersvriendelijk voor Internet gebruikers. Google geeft ontwikkelaars tools om zo dieper in te zoomen naar belangrijke meetpunten als het gaat om het laden van een webpagina en de opbouw van de layout van pagina’s. 

Google laat hiermee zien dat zij en gebruikers snel willen zien wat er op een pagina staat, dat gebruikers vrij snel meteen interactie willen en ook dat het beeld van de pagina consistent blijft.

Gebruik de tools en optimaliseer zo je webpagina’s!

 

 

 

Wat ook interessant is…

SEO Specialist

SEO Specialist

SEO Specialist Als goed vindbaar zijn op Google belangrijk isAls SEO Specialist zijn wij er voor bedrijven en...

0 reacties