Core Web Vitals van Google

Het komt niet als een verrassing dat Google steeds meer focus legt op de gebruikerservaring van bezoekers op een website. Zoals ook collega Sanne heeft beschreven in het blogartikel ‘De Google Page Experience update’, heeft Google eind vorig jaar (november) aangekondigd dat de gebruikerservaring een drastische invloed gaat hebben op jouw ranking in Google. Het algoritme van Google wordt constant bijgesteld om ervoor te zorgen dat jij als bezoeker van Google het beste resultaat krijgt bij jouw zoekopdracht.

Bovengenoemde update zal vanaf midden juni 2021 van kracht zijn en richt zich met name op de techniek van de website. Hoewel niemand nog precies weet hoe groot de impact zal zijn van deze nieuwe maatregelen, is er een grote kans dat er veel verschuivingen gaan plaatsvinden in de rankings.

Ik vertel je graag hoe jouw website (technisch) optimaal voorbereid gaat zijn voor deze update!

De Core Web Vitals groot onderdeel van de Google Page Experience

De Google Page Experience zijn een aantal onderdelen die meten hoe de gebruikerservaring van een gebruiker is op een website. Dit gaat verder dan alleen informatiewaarde, maar er wordt ook gekeken naar de zogenaamde Core Web Vitals.

Wat zijn de Web Core Vitals?

Om een goede gebruikerservaring te hebben heeft Google de nadruk gelegd op een set metrische gegevens die de gebruikerservaringen realtime meten voor laadprestaties, interactiviteit en visuele stabiliteit van een pagina.

Deze gegevens bestaan uit de volgende onderdelen:

1. Largest Contentful Paint (LCP)
2. First Input Delay (FID)
3. De Cumulative Layout Shift (CLS)

Ik zal ze één voor één doorlopen en uitleggen.

1. Largest Contentful Paint (LCP) in detail

Om een goede gebruikerservaring te bieden, moet de pagina ernaar streven dat de LCP plaatsvindt binnen de eerste 2,5 seconden vanaf het moment dat de pagina begint te laden. De LCP rapporteert de weergavetijd van het grootste element (afbeelding of tekstblok) die zichtbaar is in de viewport (scherm van jouw apparaat), vanaf het moment dat de pagina voor het eerst werd geladen.

Bepaalde elementen binnen de techniek van de website kunnen ervoor zorgen dat jouw LCP score negatief beïnvloed wordt.

JavaScripts en CSS die de paginaweergave blokkeren

Zowel scripts als stylesheets zijn render blocking bronnen die de FCP (First Contentful Paint), en vervolgens ook de LCP, kunnen vertragen. Stel niet-kritieke Javascripts en CSS uit om het laden van de belangrijkste inhoud te versnellen. Hieronder staan enkele tips om de bestanden verkleinen of uit te stellen.

• Minify CSS, minimaliseer je CSS-bestanden met behulp van een compressie.
• Defer non-critical CSS, stel het laden van de niet-belangrijke CSS uit.
• Inline critical CSS, plaats eventueel de belangrijkste CSS inline boven in het document.
• Minimaliseer en comprimeer de Javascript bestanden.
• Defer de ongebruikte Javascript.

Elementen die traag laden

Grote afbeeldingen en video’s kunnen enorm groot zijn zowel qua omvang (in kb’s) en een hoge laadtijd veroorzaken. Afbeeldingen kunnen vaak nog verkleind worden qua formaat (pixels) en gecomprimeerd worden (bijvoorbeeld Lossy).

Daarnaast kun je gebruik van verkeerde bestand extensies. Beter maak je gebruik van next-gen formats. Afbeeldingsindelingen zoals JPEG 2000, JPEG XR en WebP bieden vaak betere compressie dan PNG of JPEG, wat snellere downloads- en minder gegevensverbruik betekent.

Server reactietijd die te traag is

Het is enorm belangrijk dat de website op een goede webhosting / server staat, zodat de server de verzoeken snel kan uitvoeren en afhandelen.

• Optimaliseer jouw server / webhosting.
• Maak eventueel gebruik van een CDN (bij veel wereldwijde bezoekers).
• Cache / optimaliseer de assets.
• Serveer HTML pagina’s uit de cache.

Breng connecties met derden vroegtijdig in stand

Wanneer jouw website verzoeken (requests) doet naar externe partijen – wat hoogstwaarschijnlijk het geval is – kan dit invloed hebben op de LCP. Vooral wanneer deze nodig zijn om kritieke content op de pagina weer te geven. Maak gebruik van rel=”preconnect” of rel=”dns-prefetch” om zo de browser te laten weten dat jouw pagina zo snel mogelijk een verbinding tot stand wil brengen.

Client-side rendering

Wanneer jouw website de Javascript logics aan de clientzijde gebruikt om pagina’s in de browser weer te geven, overweeg dan onderstaande optimalisaties.

• Minimaliseer en comprimeer de Javascript-bestanden die gebruikt worden.
• Defer ongebruikte (niet belangrijke) Javascript.

Hoe vind ik de LCP op mijn pagina?

Er is geen standaard onderdeel wat de LCP is op een pagina, het is bijvoorbeeld niet het eerste onderdeel wat ingeladen wordt. Het kan pas bepaald worden als de volledige pagina ingeladen is.

Met de Google Chrome Dev Tools kan achterhaald worden, wat sowieso een enorm handig tool is om je laadtijd te analyseren. Doorloop onderstaande stappen om kritieke zaken op jouw website te ontdekken.

1. Open Google Chrome en ga naar de pagina die je wilt analyseren.
2. Druk vervolgens op F12 (voor mac gebruikers CMD+SHIFT+C) en de Google Chrome Dev tool zal in de website openen.
3. Klik nu op het tabje ‘Performance’.
4. Vink naast ‘Screenshots’ ook de ‘Web Vitals’
5. Klik nu op de ‘Opnemen’ knop en vernieuw de pagina.
6. Stop het opnemen en als het goed is zie je nu hetzelfde als onderstaand screenshot.
7. Als je nu met je muis over het zwarte ‘LCP’ blokje in de tijdlijn gaat, zal het element (in dit geval de tekst) blauw oplichten en weet je welk element de Largest Contentful Paint voor jouw pagina is.

Hoe los ik problemen met een te grote LCP op?

Afhankelijk wat er naar voren is gekomen uit de analyse, zal er bepaald moeten worden bepalen wat er moet gebeuren. Onderstaand enkele tips voor het LCP element. Meestal is het element een afbeelding, video of tekst.

De LCP is een afbeelding

Als de LCP een afbeelding is, kun je kijken naar de volgende zaken:

• Heeft de afbeelding de juiste bestandsindeling? Kan de afbeelding bijvoorbeeld vervangen worden door een moderne bestandsindeling als SVG, JPEG 2000, JPEG XR of WebP?
• Heeft de afbeelding het juiste formaat? Wordt de afbeelding bijvoorbeeld op 1920 pixels ingeladen op de mobiele variant, kijk dan of je een ander bestandsformaat in kunt laden op deze resolutie of laat zelfs de afbeelding weg.
• Zorg voor de juiste (html) attributen, deze zou een height en width moeten bevatten en een imagesrcset. Zo weet de browser op basis van de viewport welk afbeeldingsformaat geladen moet worden.
• Is de afbeelding voorzien van een compressie? Een afbeelding kun je soms wel tot 70% verkleinen qua kb’s. Door een goede tool te gebruiken kun je het inladen van dezelfde afbeelding zonder kwaliteitsverlies aanzienlijk verbeteren. Hiervoor kun je bijvoorbeeld tools als TinyPNG of Kraken.io gebruiken.
• Kan de afbeelding verplaatst worden? Kan de afbeelding bijvoorbeeld ook later op de pagina getoond worden. Mocht je vervolgens de afbeelding ook nog ‘Lazyloaden’, dan zal het zelfs helemaal geen impact meer op je eerste laadtijd hebben!

De LCP is een video

Op het moment dat de LCP een video is, kijk dan naar de volgende punten:

• Is het nodig dat de video direct begint met afspelen of kun je de video bijvoorbeeld eerst vervangen door een afbeelding met een ‘afspeel’ icoontje, waardoor de video pas ingeladen wordt op het moment dat de bezoeker daadwerkelijk de video wil bekijken.
• Heeft de video de juiste indeling? Er zijn een aantal richtlijnen waaraan je kunt voldoen om de video te optimaliseren voor het gebruik op het web. Namelijk een MP4 bestandsformaat, 1080 pixels en een framerate van 24 of 25 fps. Maak gebruik van de juiste compressie, haal de video bijvoorbeeld door een tool als Cloudconvert.
• Maak een bewuste keuze over de plek waar de video op de pagina staat, kun je deze bijvoorbeeld ook later op de pagina inladen? Dan scheelt dit enorm wanneer het buiten de viewport valt. Combineer je dit dan ook nog eens met een Lazyload functie, dan zal het helemaal geen invloed hebben op de eerste laadtijd.

De LCP is een tekstblok

De teksten kun je via een compressiemethode ook optimaliseren, bijvoorbeeld met GZIP of Brotli. Zij kunnen de teksten aanzienlijk in bestandsgrootte verkleinen wanneer ze overgedragen moeten worden tussen de server en browser. Neem contact op met je websitebouwer of webhosting partij om te kijken of dit ingericht is (of kan worden).

Ook is het belangrijk om het font te preloaden en de juiste bestandsindeling (.woff2) te gebruiken.

2. First Input Delay (FID)

De First Input Delay meet de tijd vanaf het moment dat een bezoeker voor het eerst interactie heeft met een pagina tot op het moment dat de browser in staat is om gebeurtenissen (bijvoorbeeld klikken) te verwerken in een reactie op de interactie.

Dit is van groot belang omdat dit bijdraagt aan de gebruikersvriendelijkheid van een website. We weten allemaal hoe belangrijk een eerste indruk is, dit kan verschillen van de visuele aantrekkingskracht tot een eerste indruk van de snelheid en het reactievermogen van de website.

De visuele aantrekkingskracht is moeilijk om te meten, maar de snelheid en het reactievermogen niet! Dit kan het verschil maken tussen een gefrustreerde gebruiker die de website verlaat tot een loyale klant die regelmatig een (vervolg)aankoop doet in jouw webshop.

FID-score en hoe de score tot stand komt

Het streven van een goede website is om een eerste invoervertraging te hebben van 100 milliseconden of minder. Een invoervertraging (ook wel input latency genoemd), wordt over het algemeen veroorzaakt doordat de browser bezig is met iets anders, dus het niet kan reageren op de gebruiker.

Een veelvoorkomende oorzaak is dat de browser bezig is met het parseren en uitvoeren van een (groot) Javascript-bestand. Terwijl de browser dit doet, kan het geen andere taken uitvoeren. Zolang de browser die taak nog niet afgerond heeft, kan hij dus nog geen nieuwe taak aannemen, omdat de aanpassingen van de eerste taak nog niet (volledig) doorgevoerd zijn.

Een hoge FID wordt veroorzaakt tussen de First Contentful Paint (FCP) en de Time To Interactive (TTI), omdat er een deel van de pagina wordt weergegeven maar nog niet interactief is.  Hieronder is een schema te zien hoe een ‘doorgaanse’ website wordt ingeladen door de browser en waar de FID zit.

Hoe vind ik mijn FID-score?

Er zijn diverse tools op het internet om de FID-score inzichtelijk te krijgen, één daarvan is de online tool van Dunplab.it.

Hoe kan ik mijn FID verbeteren?

Zoals hierboven aangegeven ligt de oorzaak van een (te) hoge FID score vaak door het uitvoeren van grote Javascripts. Een verbetering die een bijzonder groot effect kan hebben op de TTI is het uitstellen- en/of verwijderen van onnodige Javascripts.

Om de FID voor jouw website te verbeteren, kun je gebruik maken van de Lighthouse Prestatie audit. Deze zit tegenwoordig onder een tabje in de Google Chrome Dev Tools. Voer deze audit uit op jouw pagina en besteed aandacht aan de eventuele verbeterpunten die de audit aanraadt.

Heel globaal gezegd kun je de FID verbeteren door specifiek bezig te gaan met de volgende onderdelen:

1. Beperk het gebruik (en impact) van de code van derden, denk hierbij aan Javascripts van Google Analytics, HotJar, Facebook pixels en anderen.
2. Verkort de JavaScript-uitvoertijd, houd hier rekening met het aantal verzoeken, de omvang en de rekenkracht van de scripts die je toepast op jouw website.
3. Minimaliseer de ‘Main thread’ (de hoofddraad) van de website, trigger pas Javascripts als het nodig is en niet direct bij het inladen van de pagina, zodat dit de tijd tot interactie met de bezoeker uitstelt.
4. Houd het aantal verzoeken laag en de bestanden klein qua omvang.

3. De Cumulative Layout Shift (CLS) uitgelicht

De CLS meet het totaal van alle individuele lay-out verschuivingsscores voor elke onverwachte lay-out verschuiving die optreedt gedurende het inladen van een webpagina. Een lay-out verschuiving vindt plaats wanneer een zichtbaar element van positie verandert van het ene gerenderde frame naar het volgende.

Waarom is dit schadelijk voor je gebruikerservaring?

Heb jij wel eens ervaren dat je een artikel wilt lezen op een website en je wilt een button aanklikken, maar plotseling verandert er iets op de pagina, waardoor je een andere button aan klikt? Zonder waarschuwing beweegt de tekst en voor je het weet klik je op iets anders.

Meestal zijn dergelijke ervaringen gewoon vervelend, maar in het slechtste geval kunnen ze ook flinke schade aanrichten. Om een goede gebruikerservaring te bieden, moet een webpagina er naar streven om een CLS-score van 0.1 of minder te scoren.

Hoe wordt het veroorzaakt?

Onverwachte lay-out verschuivingen gebeuren meestal omdat bronnen asynchroon worden geladen of dat er door Javascript DOM-elementen toegevoegd worden aan de pagina boven bestaande inhoud.

Vaak zijn de boosdoeners afbeeldingen of video’s met onbekende afmetingen, een lettertype dat groter of kleiner wordt weergegeven dan de fallback of een advertentie/widget van derden die zichzelf dynamisch op de website plaatst.

Het berekenen van de CLS score

Er zijn diverse tools om de CLS score te verkrijgen. De meest populaire (en meest eenvoudige) is het gebruiken van de Google Chrome Dev Tools. Deze bevat een tabje ‘Lighthouse’ en dit genereert een rapport waar jouw CLS-score ook in zit.

Ook heb je een aantal websites waar je je website kunt laten scannen, zoals via: https://layoutstability.rocks/.

Impact fraction

De impact fraction meet hoe onstabiele elementen tussen het kijkvenster tussen twee (render) frames beïnvloeden.

Distance fraction

De distance fraction meet de lay-outverschuiving van de afstand die onstabiele elementen hebben verplaatst ten opzichte van de viewport.

In het voorbeeld is te zien dat de ‘Click me!’ knop is toegevoegd aan de onderkant van het grijze vlak. Waardoor het groene vak naar beneden en zelfs uit de viewport wordt gedrukt.

• Het grijze vlak wordt dus groter, maar de startpositie verandert niet, dus is het geen onstabiel
• De ‘Click me!’ knop, bevond zich niet in de DOM en verandert hierdoor ook niet van startpositie.
• De startpositie van het groene vlak verandert wel, maar aangezien het gedeeltelijk uit de viewport is verplaatst, komt dit laatste gedeelte niet in aanmerking voor het berekenen van de CLS.

De impactfractie wordt berekend door te kijken hoe groot het vlak is waar het impact op heeft gehad. In dit geval was dit 50% van de viewport. De impactfractie is dan dus 0.5.

De afstandsfractie wordt geïllustreerd met de paarse pijl. Het groene vak is ongeveer 14% van de viewport naar beneden verplaatst. Dus de afstandsfractie is 0.14.

De score voor lay-outverschuiving (CLS) is dan dus 0,5 x 0,14 = 0,07.

Hoe verbeter ik mijn CLS?

Om je CLS te verbeteren bestaat er geen standaardregel of oplossing die je maar even toepast op je pagina waarmee het opgelost is. Wel zijn er een aantal richtlijnen waar je je aan kunt houden om zo de kans op problemen te minimaliseren.

1. Voeg altijd afmetingen (dimensies) toe aan je afbeelding- en video-elementen.
   Op deze manier reserveer je direct de vereiste ruimte die de het element nodig heeft op een pagina. Zodat de overige inhoud niet verschuift als het media-element ingeladen is. Dit kun je door bijvoorbeeld een 16:9 of 4:3 beeldverhoudingsvak om het element heen te zetten.
2. Voeg nooit inhoud toe boven bestaande inhoud, behalve als reactie op een gebruikersinteractie.
   Dit zorgt namelijk voor onverwachte verschuivingen in de lay-out voor de gebruiker.
3. Maak gebruik van zogenaamde CSS ‘Transform animaties’ om geanimeerde overgangen aan je website toe te voegen.
   Wanneer je het op deze manier doet, zullen er geen elementen verspringen op jouw website, gebruik dus geen ‘margins’ en ‘paddings’ voor dergelijke effecten.

Overige Web Vitals

Hoewel de Core Web Vitals momenteel de cruciale statistieken zijn voor het begrijpen en leveren van een geweldige gebruikerservaring, zijn er ook andere zeker niet onbelangrijke Web Vitals. Deze dienen vaak als aanvullende statistieken om de Core Web Vitals te bepalen.

Dit zijn de volgende onderdelen.

• De Time To First Byte (TTFB), dit is de tijd die de browser nodig heeft om de gebruiker de eerste byte aan pagina-inhoud te laten ontvangen.
• First Contentful Paint (FCP), dit meet de tijd vanaf het moment dat de pagina begint te laden tot het moment waarop inhoud (tekst, afbeeldingen, etc.) op het scherm worden weergegeven.
• Total Blocking Time (TBT), meet de totale hoeveelheid tijd tussen de FCP en de TTI, waarbij de hoofdthread lang genoeg wordt geblokkeerd om interactie/ reactie van de server te voorkomen.
• Time to Interactive (TTI), meet de tijd vanaf met moment dat de pagina begint te laden tot het moment waarop de belangrijkste (sub)bronnen zijn geladen en snel en betrouwbaar te reageren op gebruikersinvoer.

Maak gebruik van handige tools

Om alle data inzichtelijk te maken en tips te krijgen raden wij de volgende tools aan. Veel van deze tools maken gebruik van de Lighthouse auditing tool.

1. Google Chrome Dev tool: deze zit in de Google Chrome browser.
2. De tool van web.dev
3. Google Pagespeed Insights
4. Dunplab Web Vitals Tester
5. De CLS-checker van Layoutstabilty

Een goede website is enorm belangrijk, maar een goede website bestaat niet alleen uit goede (Core) Web Vitals. Het zal een samenhang moeten zijn van een aantrekkelijk design, gebruiksvriendelijkheid, gericht op conversie en ook nog eens geschikt voor SEO/ zoekmachine optimalisatie.

Het is ook absoluut niet zo dat al deze onderdelen elkaar versterken, sterker nog het kan elkaar bijten. Daarom is het belangrijk dat je bij het opzetten van een nieuwe website goed na denkt over de strategie en opbouw van de website, zodat je op alle vlakken het maximale uit je website kan halen en dit ook technisch haalbaar is.

Heb jij vragen naar aanleiding van mijn artikel of ben je benieuwd wat wij voor jou kunnen doen? Schroom niet en neem vrijblijvend contact met ons op!