Google Core Web Vitals – Dit moet je weten over Core Web Vitals!

Ongetwijfeld heb je afgelopen tijd gehoord over de Google Core Web Vitals. De Google Web Vitals zijn onderdeel van de langverwachte Page Experience update van Google die op 15 juni 2021 is uitgerold over het wereldwijde web. Ook heeft Google in november 2021 aangekondigd dat de Page Experience update naar de desktop komt, verwachting: februari 2022.

In dit blog wil ik stilstaan bij de Google Core Web Vitals en vooral vertellen wat jij kunt doen om de Google Web Vitals van jouw website te analyseren én te optimaliseren.

Wat zijn de Google Core Web Vitals?

De Google Core Web Vitals bestaan uit drie aspecten waarmee Google de mobiele gebruikerservaring van een gebruiker op een pagina meet. Voor nu zijn First Input Delay (FID), Largest Contentful Paint (LCP) en Cumulative Layout Shift (CLS) de drie signalen die Google gebruikt.

Goed om te weten is dat deze signalen aangepast kunnen worden in de toekomst. Niet alleen zullen er straks nieuwe signalen komen, ook is bijvoorbeeld al aangekondigd dat de Page Experience update ook naar desktop komt.

Google Core Web Vitals

First Input Delay

De First Input Delay meet interactiviteit en is de tijd tussen hoe de gebruiker interactie heeft met de site en wanneer de browser kan beginnen met het verwerken van de interactie.

Het is natuurlijk super vervelend als jij als gebruiker klikt op een knop en je eerst een seconde moet wachten voordat er iets gebeurt. Daarom is het belangrijk om de First Input Delay onder de 100 ms te hebben. Alles langer dan 300 ms heeft écht verbetering nodig.

Largest Contentful Paint

De Largest Contentful Paint meet laadsnelheid en is de tijd voordat het grootste element van je webpagina geladen is.

Voor een gebruiker is een trage website geen prettige ervaring. Daarom is het belangrijk om de Largest Contentful Paint onder de 2.5 sec. te hebben. Alles langer dan 4 sec. heeft écht verbetering nodig.

Cumulative Layout Shift

De Cumulative Layout Shift meet visuele stabiliteit en is een score voor de hoeveelheid verschuivingen op een pagina.

Ooit wel eens samen in een Google Docs gewerkt waarin alles verspringt? Dit verspringen kan ook plaatsvinden op een webpagina en dat is super irritant. Daarom is het belangrijk om een score van minder dan 0.1 te hebben. Alles boven de 0.25 heeft écht verbetering.

Google Core Web Vitals meten

Om erachter te komen of jouw website door gebruikers als prettig ervaren wordt, is het belangrijk om met de juiste tools de Google Core Web Vitals te meten.

Field Data vs. Lab Data

Voordat we naar het meten en verbeteren van de Google Core Web Vitals gaan, is het belangrijk om te weten wat het verschil is tussen field data en lab data.

Field Data vs. Lab Data Bol.com

Het beste voorbeeld in de praktijk is de website van Bol.com. Bij de field data zie je duidelijk bij alle Google Core Web Vitals betere statistieken dan bij de lab data.

Wanneer je een tool gebruikt om jouw website te testen is dit lab data. Dit is een test met een vooraf gedefinieerd toestel, locatie en netwerk instellingen.

Ik neem even mijn eigen telefoon, een iPhone X, als voorbeeld ter vergelijking. De test die ik heb gedaan was met Pagespeed Insights wat Lighthouse gebruikt voor de verzameling van data.

We vergelijken het toestel en netwerk instellingen. We gebruiken Geekbench voor het toestel en ik heb mijn netwerk test gedaan met Speedtest, terwijl ik 4G aan had staan.

Best een verschil hè. Het is daarom ook niet gek dat Bol.com veel beter scoort met de field data dan met de lab data. Gemiddeld gezien hebben Nederlanders een snellere telefoon dan de Moto G4 – met een snellere wifi of 4g verbinding dan wat Google gebruikt.

Google gebruikt dan ook de field data om uiteindelijk de Google Core Web Vitals scores te berekenen.

Google Core Web Vitals van jouw website

Om de Google Core Web Vitals te meten, wil ik drie tools behandelen die ik graag gebruik voor het meten van de Google Web Vitals en de snelheid van een website in het algemeen: Google Pagespeed Insights, WebPageTest en Chrome DevTools.

Het is belangrijk bij het meten van de snelheid dat je niet alleen de homepagina neemt als test. Test zeker alle ‘soorten’ pagina’s, denk aan: categorie pagina’s, product pagina’s, blog pagina’s, configurator pagina’s, landing pagina’s. De homepagina is namelijk niet de enige pagina die een gebruiker te zien krijgt.

Wat we met de tools gaan meten, is dus de Lab Data. Daarnaast laat ik twee tools zien voor het vinden van de Field Data van jouw website. Belangrijk om te weten is dat First Input Delay niet te meten is met Lab Data, omdat deze tools geen interactie met de site hebben.

Google Pagespeed Insights

Google Pagespeed Insights is wat mij betreft een heel goede tool voor het snel inzichtelijk maken van de Google Core Web Vitals. Deze tool heb ik ook gebruikt voor het meten van de snelheid van Bol.com

Google Pagespeed Insights

Door simpel een url in te vullen, meet Google aan de hand van Lighthouse (later meer) de snelheid van de website en hangt hier een score aan vast. Niet alleen een score, maar ook gedetailleerd in seconden de Google Core Web Vitals én aanbevelingen die Google gelijk al geeft voor het verbeteren.

Voordelen: Snel, aanbevelingen

Nadelen: Geen geavanceerde data

WebPageTest

WebPageTest is een ideale tool voor wanneer je wat meer controle en inzicht over de test wilt hebben.

WebPageTest.org Instellingen

Voor het meten heb je veel meer controle over de lab data. Zo kun je de locatie, browser en het netwerk instellen, maar ook hoeveel testen er uitgevoerd moeten worden. Ook stellen we in dat een ‘repeat view’ getest moet worden en de video moet opnemen. De video is een opgenomen beeld van hoe de pagina ingeladen wordt.

Tip! -> Kijk eens in Google Analytics bij Doelgroep – Technologie – Apparaten voor de meest gebruikte apparaten en stel een 4G verbinding in. Dit is een meer representatieve instelling voor de test dan PageSpeed Insights.

Door middel van de vijf testen kun je de mediaan resultaten bekijken. Het voordeel van WebPageTest is dat je in een watervalvorm precies kunt zien hoe alle bestanden van jouw website ingeladen worden.

WebPageTest heeft ook een speciaal tabje voor de Google Core Web Vitals, waar veel informatie te vinden is over de Core Web Vitals. Zo kun je zien welk element van je site het ‘grootste’ element is en welke verschuivingen plaatsvinden op je site.

WebPageTest Google Core Web Vitals

Voordelen: Controle, geavanceerde data

Nadelen: Geavanceerder dus moeilijker

Chrome DevTools

De meest complete en geavanceerde tool is Chrome DevTools. Om Chrome DevTools te kunnen gebruiken ga je naar een website, klik je op de rechter muisknop en vervolgens op ‘inspecteren’.

Google Chrome DevTools

Niet alleen kun je bij het tabje ‘Lighthouse’ een soortgelijk rapport als Pagespeed Insights genereren, in het tabje ‘Performance’ heb je een super geavanceerde data weergave van hoe de webpagina wordt geladen. Hiervoor kun je een apparaat instellen, maar ook de netwerk én locatie instellingen. Je kunt deze instelling toepassen door rechtsboven naar instellingen te gaan. Zo heb ik een custom locatie ‘Amsterdam’ toegevoegd en een netwerk profile ‘4G’.

In het tabje performance zie je dus een geavanceerde weergave van hoe jouw website ingeladen wordt door Chrome. Als je in het tabje onder ‘Web Vitals’ naar beneden scrolt, kun je ook bijvoorbeeld bij het tabje ‘Timings’ op LCP of een Layout Shift klikken en dan precies zien welk element verschoven is, vergelijkbaar met WebPageTest.

Chrome DevTools LCP

Voordelen: Alles in 1

Nadelen: Geavanceerder dus moeilijker

Google Search Console

Naast de lab data is het belangrijker om te kijken naar de field data. In Google Search Console bij het tabje ‘site-vitaliteit’ is data te zien van jouw gebruikers. Google maakt een onderscheid tussen slechte, verbetering nodig en goede url’s. Klik je vervolgens door, dan kun je per url de FID, LCP en CLS zien. Hier is ook voor het eerst dat we de FID kunnen zien.

Google Search Console Site-Vitaliteit

Google Analytics

Met weinig gebruikers op je site is het lastig om field data te verzamelen. In Google Search Console kan het bijvoorbeeld zijn dat er niet genoeg gegevens zijn verzameld om de data aan je te laten zien.

Een oplossing voor het verkrijgen van de field data is het handmatig meten van de Core Web Vitals in Google Tag Manager of BigQuery en deze in te laten schieten naar Google Analytics. Als je vervolgens in Google Data Studio een aangepaste parameter aanmaakt om het gemiddelde van de gebeurtenis te berekenen, kun je per pagina precies de gemeten FID, LCP en CLS zien.

Google Core Web Vitals in Google Data Studio

Wil je dit instellen? Check dan mijn tutorial waarin ik je stap voor stap meeneem in het instellen hiervan.

Google Core Web Vitals verbeteren

En, heb je al genoeg van de termen FID, LCP en CLS? We zijn er bijna! 😉

Na het meten van de Google Core Web Vitals is het belangrijk om te kijken wat voor verbeteringen jij door dient te voeren op jouw website om de scores van de Google Web Vitals te verbeteren.

Dit kan natuurlijk per site verschillen, maar ik wil voor de FID, LCP en CLS kort stilstaan bij veel voorkomende problemen die zich voordoen op websites en de oplossing ervoor. Het is belangrijk om te bepalen wat er technisch mogelijk is op jouw site, kijk daarom zelf welke aanbevelingen er mogelijk zijn en overleg met je webbouwer over de implementatie.

Largest Contentful Paint

Een lage LCP score heeft alles te maken met elementen die het inladen van een website vertragen. Een aantal belangrijke elementen zijn: html, css, javascript, afbeeldingen en video’s.

Hoe groter deze bestanden zijn, hoe meer een browser moet downloaden en om moet zetten (renderen) en dus hoe langer het duurt voordat een gebruiker de pagina ziet.

Laten we beginnen met super standaard zaken. Als je deze niet voor je website ingesteld hebt, zijn dit écht quick wins. Zorg dat je cache ingeschakeld hebt, gzip compressie aan hebt staan voor html, css en javascript bestanden en zorg te allen tijden dat je afbeeldingen comprimeert op je pagina’s. Voor de beste methoden om je afbeeldingen te comprimeren, check dat zeker de video van Ewoud over het verkleinen van afbeeldingen.

Met de basis ingesteld kunnen we verder met render blocking. Render blocking is één van de meest voorkomende verbeteringen die Pagespeed Insights geeft aan sites.

Render blocking

Een browser verwerkt de code van een pagina van boven naar beneden. Staat daar een css of javascript bestand tussen? Dan stopt de browser, wordt eerst het hele bestand opgehaald en verwerkt en gaat dan pas weer door met de rest. Deze bestanden blokkeren dus het renderen van de rest van de pagina. Helemaal met grote css en javascript bestanden zorgt dit voor veel vertraging.

Het is belangrijk om je css en javascript bestanden goed na te kijken, een handige tool hiervoor is DevTools Coverage rapport waarin je precies kunt zien hoeveel procent van een bestand niet gebruikt wordt.

Chrome DevTools Coverage Rapport

In het geval van Bol.com wordt dus soms meer dan 80% van een bestand niet gebruikt. Enkele zaken die uitgevoerd kunnen worden:

Het eerste is het verkleinen van de css en javascript bestanden. Hiermee worden overbodige tekens verwijderd, denk aan spaties.

Een belangrijke optimalisatie is het gebruiken van async en defer bij css en javascript bestanden. Hiermee controleer jij wat er gebeurt met het inladen. Met async wordt het bestand alvast opgehaald en enkel apart verwerkt en met defer wordt het bestand alvast opgehaald en pas aan het einde verwerkt.

Async en Defer Tag

Maak voor elk type pagina een css bestand met alle kritieke css & javascript, verwijder niet gebruikte css en javascript en async / defer niet kritieke css of javascript. Bedenk goed of de css of javascript al snel nodig is of dat het pas aan het einde ingeladen kan worden.

Je kan ook kritieke css en javascript direct inline in de code plaatsen, zo voorkom je het verwerken van een bestand. Het direct plaatsen in de code kan je ook perfect doen voor kleine elementen die je bijvoorbeeld maar op één pagina hebt, zo voorkom je dat je deze in een algemeen bestand zet die vervolgens elke keer voor niks wordt ingeladen.

Voor de kritieke css en javascript en externe bronnen kan ook het <preload> element gebruikt worden. Net als DNS-prefetch, preconnect en prefetch helpt het met het inladen van bestanden:

• ​​DNS-prefetch – Doet alvast een DNS lookup, voordat er begonnen wordt aan het downloaden van het bestand
• Preconnect – Doet de DNS lookup en maakt al verbinding met de server
• Prefetch – Prefetch doet wat preload doet, maar dan voor iets wat nog niet direct nodig is op de pagina
• Preload – Preload doet alles wat een preconnect doet én het daadwerkelijk downloaden van het bestand, voor gebruik op de huidige pagina

Door belangrijke bestanden te preloaden, verminder je render blocking. Let wel op! Alles preloaden is hetzelfde als niks preloaden, omdat je dan geen voorrang meer geeft aan belangrijke bestanden.

Cumulative Layout Shift

De onverwachte verspringingen op een website gebeuren vaak doordat afbeeldingen, advertenties, embedded content en iframes ingeladen worden, waardoor content naar beneden of boven schuift.

Cumulative Layout Shift Slecht

Tip! Je kunt in Chrome DevTools – maar ook in WebPageTest – zien welke elementen voor verschuivingen op de website zorgen!

Het is belangrijk dat vooraf in de broncode ruimte gereserveerd wordt voor afbeeldingen, advertenties, embedded content en iframes. In plaats van verschoven content is er nu al ruimte gereserveerd voor deze content, zodra deze ingeladen wordt, is de ruimte al gereserveerd en verspringt de content niet.

Cumulative Layout Shift Goed

Ook moet je oppassen met animaties. Alhoewel vele animaties verwachte animaties kunnen zijn, dien je toch op te passen dat jouw animaties niet voor een onverwachte verschuiving zorgen. Maak je gebruik van animaties? Gebruik dan ‘transform’ animaties.

First Input Delay

Het optimaliseren van de First Input Delay is moeilijker dan andere metrics, omdat de First Input Delay niet gemeten kan worden met tests. Een metric om naar te kijken is de Total Blocking Time (TBT). Alhoewel dit natuurlijk niet de First Input Delay is, zorgt een verbetering in de TBT ook voor een verbetering van de FID.

Klikken op een element en dan lang moeten wachten voor er iets gebeurt, komt vaak doordat de browser bezig is met grote javascript bestanden. In plaats van druk bezig te zijn met het verwerken van een interactie, is de browser druk bezig met het verwerken van javascript.

Mocht je al bezig zijn met het optimaliseren van render blocking, dan zal je ook een verbetering in FID zien. Het is belangrijk dat grote javascript bestanden nagekeken worden. Zo kun je onnodige code verwijderen, niet kritieke javascript een async of defer attribuut toekennen en 1 groot javascript bestand opdelen in kleinere bestanden. In plaats van 1 keer lang een javascript bestand verwerken, krijg je dat de browser meerdere kleinere bestanden moet verwerken. Het voordeel daarvan is dat zodra de browser klaar is met zo’n klein bestand, hij de interactie van de gebruiker kan verwerken.

Je kunt lange taken in Chrome DevTools makkelijk zien in het performance tabblad. Onder het kopje ‘main threat’ zie je precies welk proces bezig is.

Google Chrome DevTools Long Tasks en Main Threat

In het geval van de website van Pure ziet Chrome het verwerken van de html code als een lange taak. Taken die langer dan 50 ms duren worden toegekend als lange taak.

Let wel op dat een FID onder 100 ms als ‘goed’ ervaren wordt. Het verwerken van bijvoorbeeld de Google Tag Manager code duurt gemiddeld iets langer dan 100 ms, staar je dus niet helemaal blind op 50 ms, maar kijk naar echt grote taken.

Ben je er nog? Het was – al zeg ik het zelf – een aardig lang verhaal, maar dit is dan alles wat jij als online marketeer moet weten over de Google Core Web Vitals. Heb je na het lezen van deze blog vragen over de Google Web Vitals of heb je hulp nodig bij het optimaliseren ervan? Aarzel dan niet om contact op te nemen!