Google is hard bezig om de prestaties overal op het web te verbeteren, door middel van Core Web Vitals. Waarom? Omdat Google hun geld vooral verdient op het web, en trage websites en webtoepassingen duwen gebruikers juist naar ingebouwde, onafhankelijke apps.
Je plek in de zoekresultaten van Google hangt in sterke mate af van de keywords in de zoekopdracht, het gebruik van die keywords op je pagina’s en de populariteit van je pagina volgens het aantal (en de kwaliteit van) links vanuit andere plekken naar je website. Sinds augustus 2021 is Google ook hard bezig om pagina’s te scoren op basis van hun prestaties, en dat mee te nemen bij de ranking.
Dit artikel laat je daarom zien hoe je jouw website kan optimaliseren voor de metrics van Google’s Core Web Vitals.
Waarom de Core Web Vitals?
Content blijft altijd het belangrijkst. Maar als je twee websites met vergelijkbare teksten en populariteit naast elkaar zet, zal de website met de beste gebruikerservaring hoger komen te staan in de zoekresultaten bij Google.
Naast een hogere ranking voor de pagina’s, komen websites met hoge prestaties ook in aanmerking om meegenomen te worden in de carrousel voor mobiele zoekresultaten. Dit was vroeger uitsluitend voor Accelerated Mobile Pages (AMP), waarbij je content moest overzetten naar een aparte website die gehost werd door Google. AMP heeft echter veel kritiek gekregen, met name omdat deze pagina’s lang niet altijd sneller zijn dan goed geoptimaliseerde WordPress websites of statische websites. Het is inmiddels dus geen vereiste meer.
Hoe je het ook bekijkt, hoe sneller en meer responsive je website is, hoe groter de kans dat je hoger in de zoekresultaten van Google komt.
Wanneer je bedenkt dat de gemiddeld pagina online zo’n 2 MB groot is, meer dan 60 HTTP verzoeken stuurt, en 16 seconden kost om volledig weergegeven te worden op een mobiel apparaat, dan snap je waarom er voor de meeste websites genoeg ruimte voor verbetering is. We laten je zien hoe je die verbeteringen het beste kan bereiken.
De belangrijkste ranking-factoren van Google
Er zijn vier belangrijke ranking-factoren die je mee moet nemen voordat je naar je prestaties gaat kijken:
- HTTPS: HTTPS is essentieel. Gebruikt je website een beveiligde verbinding tussen de webserver en de browser van je bezoeker?
- Mobielvriendelijkheid: Je website moet goed werken op een mobiel apparaat. Is je website inderdaad goed bruikbaar op een apparaat met een kleiner scherm? Worden de pagina’s weergegeven zonder dat er content buiten beeld blijft en gebruikers opzij moeten scrollen? Is de tekst groot genoeg om te kunnen lezen? Zijn klikbare plekken groot genoeg om met je vinger te kunnen aanklikken?
- Geen interstitials: Gebruik geen vervelende interstitials, de mobiele advertenties die het hele scherm innemen wanneer je binnen een mobiele site naar een andere pagina gaat, en die dus extreem veel ruimte innemen. Is je content altijd goed leesbaar? Of wordt het gedeeltelijk verborgen door banners of pop-up advertenties? Zorgen je advertenties of promoties ervoor dat je website moeilijker te gebruiken is?
- Veilig browsen: Je website moet natuurlijk vrij van malware, virussen, phishing, fraude en andere ongein zijn.
Nadat je aan deze voorvereisten voldoet, zal je website beoordeeld worden op de werkelijke prestaties.
Hoe meet Google webprestaties?
Ervoor zorgen dat je website snel laadt, meteen weergegeven wordt, en sneller responsive is, maakt een hoop uit. Maar voelt het ook inderdaad snel aan voor je bezoekers?
Toepassingen voor het meten van prestaties, zoals de Devtools van je browser, geven je technische informatie, zoals:
- Blocking time: De tijd dat er gewachten moet worden tot een download begint, meestal omdat andere bestanden, zoals stylesheets en scripts, een hogere prioriteit hebben.
- DNS resolution: De tijd die het kost tot een hostnaam omgezet kan worden naar een IP-adres om een bestand op te kunnen halen.
- Connect time: Hoe lang het duurt voordat er een TCP verbinding gemaakt kan worden.
- Time to First Byte (TTFB): De totale tijd tussen het eerste verzoek en de eerste byte van het antwoord.
- Receive time: De tijd die het kost om de gehele asset binnen te halen.
- DOM load time: Hoe lang het duurt om het HTML Document Object Model te downloaden en te tonen. Dat is meestal ook het moment dat scripts die het DOM analyseren of aanpassen voor het eerst goed uitgevoerd kunnen worden.
- Page load time: De tijd die het kost om de pagina te downloaden, inclusief alle bijbehorende zaken, zoals afbeeldingen, stylesheets, scripts en dergelijke.
- Total page weight: De totale grootte van alle bestanden van de website. Dit wordt vaak vermeld als zowel gecomprimeerde grootte (tijdens de download) als uitgepakte grootte.
- The number of DOM elements: Het totale aantal HTML elementen op de pagina. Hoe meer elementen, hoe langer het duurt voordat een pagina verwerkt is.
- First Contentful Paint (FCP): Hoe lang het duurt voordat de browser de eerste pixel van de content kan tonen.
- First Meaningful Paint (FMP): De tijd die het kost voordat de primaire content van de pagina zichtbaar is voor de gebruiker.
- Time to Interactive (TTI): De tijd die nodig is voordat een pagina volledig interactief is en betrouwbaar kan reageren om de input van een bezoeker.
- First CPU Idle: De tijd die het duurt tot de CPU de hele pagina en alle initialisatie-scripts heeft uitgevoerd, en nu wacht op verdere opdrachten.
- CPU usage: De verwerkingscapaciteit die nodig is om de pagina te tonen en te reageren op input van de bezoeker.
- Layouts per second: Hoe snel de browser de styles en layouts van de pagina kan herberekenen.
Dit is een handige lijst met indicatoren om probleempunten te identificeren, zoals de belasting van de server, CMS caching, browsercaching, downloadsnelheid en JavaScript efficiëntie. Maar al deze indicatoren geven nog altijd niet aan of de website nou een goede of slechte gebruikerservaring kan bieden. Bijvoorbeeld:
- Een app kan snel downloaden en direct getoond worden, maar na de eerste interactie meteen bevriezen, omdat er nog een grote hoeveelheid niet-geoptimaliseerde JavaScript code verwerkt moet worden.
- Een chattoepassing kan de hele tijd data downloaden wanneer gebruikers een bericht plaatsen. Een assessmenttool denkt dat het laden nog altijd niet voltooid is, terwijl de pagina wel responsive aanvoelt.
Core Web Vitals is Google’s poging om deze dilemma’s op te lossen, en een beter beeld te bieden.
Wat zijn de Core Web Vitals?
De Core Web Vitals (CWV) van Google zijn drie prestatie-indicatoren die de werkelijke gebruikerservaring aangeven:
- Largest Contentful Paint (LCP): Prestaties voor het laden
- First Input Delay (FID): Prestaties voor interactiviteit
- Cumulative Layout Shift (CLS): Prestaties voor visuele stabiliteit
Deze nieuwe update in het algoritme van Google is wereldwijd geïntroduceerd vanaf het eind van augustus 2021. De Core Web Vitals metrics richten zich met name op mobiele zoekresultaten, maar als dat goed gaat zullen de zoekresultaten voor computers snel volgen.
De LCP, FID, en CLS scores van een pagina zijn gebaseerd op de echte gebruikersdata van de afgelopen 28 dagen, die anoniem worden verzameld via de Chrome browser. Deze metingen kunnen variëren op basis van apparaten van gebruikers, verschillende verbindingen, en verschillende gelijktijdige activiteiten, dus ze gebruiken het 75e percentiel in plaats van het gemiddelde.
Dat wil zeggen dat de data van alle gebruikers wordt gesorteerd van best naar slechtst, en de prestaties op driekwart van die “ladder” wordt genomen als uitkomst. Dit betekent dat drie van de vier bezoekers dus een betere prestaties ervaart dan dat niveau.
Elke pagina die een goede (groene) score haalt op alledrie de metrics van Core Web Vitals, krijgt een hogere ranking in de zoekresultaten, en zal opgenomen worden in de carroussel met “Top Stories” in de Google News app.
In de volgende alinea’s kijken we verder naar het algoritme dat gebruikt wordt om de verschillende indicatoren te berekenen, de tools die je kan gebruiken om de score van een pagina te bepalen, de gebruikelijke oorzaken van lage scores, en wat je kan doen op problemen met je prestaties op te lossen.
Largest Contentful Paint (LCP)
Largest Contentful Paint meet de prestaties voor het laden. Dat wil dus in feite zeggen, hoe snel wordt er bruikbare content weergegeven op de pagina?
LCP analyseert hoe lang het duurt tot de grootste afbeelding of stuk tekst zichtbaar is geworden in de browser viewport (het deel dat dus direct zichtbaar is zonder te scrollen). In de meeste gevallen is het belangrijkste item een hero-afbeelding, banner, heading of een groot stuk tekst.
De volgende soort elementen kunnen allemaal gebruikt worden voor de analyse van Largest Contentful Paint:
- Afbeeldingen (<
img>element) - Afbeeldingen binnen vector graphics (een
<image>binnen een<svg>) - video thumbnails (een poster attribuut dat ingesteld is op een image URL binnen een
<video>element) - Elementen met een achtergrondafbeelding (meestal geladen met de CSS
background-image url()eigenschap) - Block-level elementen met tekst
Pagina’s waarbij de Largest Contentful Paint voltooid wordt binnen de eerste 2,5 seconden van het laden van de pagina worden gezien als goed (groen). Pagina’s die boven de 4 seconden zitten worden gezien als slecht (rood):
Largest Contentful Paint analysetools
LCP is de eenvoudigste Core Web Vital metric om te begrijpen, maar het is niet altijd direct duidelijk welk element gekozen wordt voor de analyse.
Het DevTools Lighthouse panel is te vinden in Chromium-based browsers zoals Chrome, Edge, Brave, Opera, en Vivaldi. Open DevTools via het browsermenu – meestal bij More tools > Developer tools of de sneltoetsen Ctrl | Cmd + Shift + i or F12 – en ga vervolgens naar het tabblad Lighthouse (oudere versies noemen dit soms Audit).
Maak een Mobile Performance rapport aan, en kijk vervolgens naar het onderdeel Performance. De Largest Contentful Paint tijd wordt getoond met een uitklapbaar deel, waar je het gekozen element kan vinden:
Je kan dezelfde informatie vinden in de online PageSpeed Insights en web.dev Measure tools als je geen Chromium-based browser bij de hand hebt:
Het DevTools Performance panel toont ook een LCP indicator. Om hiermee aan de slag te gaan klik je op het ronde Record icoon, vervolgens laad je de pagina opnieuw, en klik je op Stop om het rapport te maken en te bekijken. Klik op het LCP icoon in het onderdeel Timings om het element te bekijken en een overzicht van de statistieken te bekijken.
De Web Vitals extension is beschikbaar voor Google Chrome, maar kan ook geïnstalleerd worden op de meeste Chromium-based browsers. Daarin worden de Core Web Vitals berekend voor elke website die je bezoekt, en het icoon wordt groen, oranje of rood, afhankelijk van het resultaat. Je kan ook op het icoon van de extensie klikken om meer details over de LCP te zien:
Google’s Search Console biedt nu ook een onderdeel voor Core Web Vitals section als je website toegevoegd is als jouw eigendom. Dat rapport laat zien hoe de CWV metrics veranderd zijn in de afgelopen tijd. Er worden hier geen specifieke LCP metrics getoond, en alleen de websites die genoeg verkeer krijgen zijn te zien:
Het Chrome User Experience Report biedt je de mogelijkheid om de echte gebruiksstatistieken te bekijken, inclusief de LCP voor verschillende landen, verbindingen, en apparaten, voor een specifieke URL. Dit is een publiek project op Google BigQuery, dus je moet je wel eerst aanmelden voor een Google Cloud Platform en factuurgegevens opgeven. Ook hierbij geldt weer dat het rapport alleen nuttig is wanneer een URL genoeg verkeer binnenkrijgt.
Als laatste is web-vitals JavaScript library een klein script van 1 KB dat de LCP en andere indicatoren van de Core Web Vitals kan berekenen voor echte gebruikers op je live website. Aangezien dit gedownload kan worden vanaf een CDN, kan je het volgende script toevoegen aan je HTML <head>:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getLCP } from 'https://unpkg.com/web-vitals?module';
getLCP(console.log);
</script>
<!-- rest of page -->
getLCP() is een asynchrone functie die een callback krijgt, die geactiveerd wordt wanneer de LCP waarde berekend is (maar die ook nooit geactiveerd kan worden wanneer de pagina in een achtergrondtabblad laadt). De callback functie krijgt een object met het volgende:
name: de naam van de indicator (in dit geval “LCP”)value: de berekende waardeid: een uniek ID dat de metric voor deze specifieke pagina identificeertdelta: de verandering (delta) tussen de huidige waarde en de vorige gerapporteerde waardeentries: een array van entries die gebruikt zijn bij het berekenen van de waarde
Het bovenstaande script stuurt het object naar de console, al is het praktischer om de data naar een server te laten sturen of naar Google Analytics voor verdere analyse.
Oorzaken van slechte scores voor Largest Contentful Paint
Slechte LCP scores komen meestal door pagina’s die traag laden, waardoor het grootste block niet snel weergegeven kan worden:
- De respons van de server kan ook traag zijn, omdat deze overbelast is, of gewoon teveel moet doen om de pagina weer te geven. Dit ligt niet per definitie aan jouw website, het kan namelijk ook komen doordat de servercapaciteit beperkt is omdat je gedeelde hostingservice gebruikt in plaats van managed WordPress hosting.
- Render-blocking CSS en JavaScript kunnen ervoor zorgen dat een pagina langzamer laadt als ze in de HMTL genoemd worden boven de primaire content.
- Andere bestanden, zoals grote afbeeldingen en video’s kunnen de beschikbare bandbreedte opeten, en trager weergegeven worden.
- De content van een pagina die gemaakt wordt aan de kant van de client in plaats van de server, kan ook trager getoond worden.
De Largest Contentful Paint scores verbeteren
Een uitgebreide audit kan de problemen met het laden identificeren, maar meestal draait het om het verminderen van de hoeveelheid data die naar de browser gestuurd wordt. De volgende tips helpen je richting een betere LCP score:
- Upgrade je servercapaciteit of je hostingservice. Zorg ervoor dat downloadsnelheden ook hoog zijn bij pieken in het verkeer.
- Activeer servercompressie en HTTP/2+. Er is geen enkele reden om dat niet te doen.
- Verminder de belasting op de server. Verwijder ongebruikte code en CMS plugins, en gebruik effectieve caching.
- Zorg ervoor dat de browser bestanden effectief kan cachen. Stel de juiste Expires, Last-Modified, en ETag hashes in bij de HTTP header, zodat bestanden niet onnodig nogmaals opgevraagd worden.
- Gebruik een Content Delivery Network (CDN) om de belasting te verdelen en om je bestanden zo dicht mogelijk bij je gebruikers te hosten.
- Geef je algemene optimalisatie een boost middels de codeminificatie-feature die is ingebouwd in het MyKinsta dashboard.
- Optimaliseer je afbeeldingen. Verklein ze tot de kleinst mogelijke afmetingen, en gebruik het juiste bestandstype om de bestandsgrootte te minimaliseren. Zorg ervoor dat elke afbeelding in het grootste content-block zo vroeg mogelijk aangevraagd wordt. Hierbij kan een preload veel helpen.
- Lazy-load afbeelding door een
loading="lazy"attribuut toe te voegen. Voeg attributen voor hoogte en breedte toe om ervoor te zorgen dat er genoeg ruimte gereserveerd wordt op de pagina totdat de afbeelding geladen is. - Minimaliseer externe verzoeken, en overweeg bestanden naar je primaire domein over te zetten, om onnodige DNS lookup te beperken.
- Minimaliseer het aantal en de grootte van bestandsverzoeken, met name bovenaan je HTML.
- Zorg ervoor dat je alleen de benodigde webfonts laadt. Gebruik web-safe lettertypen voor de beste prestaties.
- Verwijder ongebruikte JavaScript en CSS bestanden.
- Minimaliseer je JavaScript en CSS bestanden.
- Voorkom @import statements in CSS, aangezien ze de weergave blokkeren en styles achter elkaar laden, in plaats van parallel.
- Gebruik geen Base64 encoding, aangezien dit de bestandsgrootte vergroot en extra bewerkingen vereist.
- Overweeg belangrijk inline CSS. Voeg belangrijke CSS die direct bij het laden zichtbaar is (zonder scrollen) toe in een
<link>block bovenaan de pagina, en laadt de andere stylesheets asynchroon. - Gebruik asynchrone, uitgestelde of ES module JavaScript om het uitvoeren van scripts uit te stellen. Voer langdraaiende JavaScript processen uit in een service worker.
First Input Delay (FID)
First Input Delay meet hoe responsive je pagina is. Het gaat hier in feite om hoe lang het duurt tot je pagina reageert op de acties van je bezoekers, zoals klikken en scrollen.
De FID metric wordt berekend als de tijd tussen de actie van de gebruiker en het moment dat de browser dat verzoek verwerkt. Hierbij wordt niet de benodigde tijd gemeten voor het uitvoeren van de handler functie, die meestal de input zou verwerken en het DOM zou updaten.
Pagina’s met een FID tijd van 100 milliseconden of minder worden meestal gezien als goed (groen). Pagina’s boven de 300 milliseconden worden gezien als slecht (rood):
First Input Delay analysetools
First Input Delay is onmogelijk te simuleren omdat het alleen gemeten kan worden wanneer de pagina geladen wordt bij een echte bezoeker die de pagina gebruikt. Het resultaat is daarom ook afhankelijk van de capaciteit van het gebruikte apparaat.
FID wordt niet berekend in het DevTools Lighthouse panel of PageSpeed Insights. Maar deze tools bepalen wel de Total Blocking Time (TBT). En dat is al een heel redelijke benadering van de First Input Delay. Hierbij wordt de tijd gemeten tussen:
- De First Contentful Paint (FCP), oftewel het moment waarop de content van de pagina weergegeven begint te worden en
- De Time to Interactive (TTI), oftewel het moment waarop de pagina kan reageren op de input van de bezoeker. TTI wordt gezien als het moment dat er geen langlopende taken meer actief zijn, en er nog minder dan drie HTTP verzoeken afgehandeld moeten worden.
De Web Vitals extension voor Google Chrome kan ook een FID metric berekenen wanneer je een pagina gebruikt, dus erop klikt of scrollt. Klik op het icoon van de extensie om meer informatie te tonen:
Net als bij LCP kan het Chrome User Experience Report de mogelijkheid bieden om de echte gebruiksstatistieken te bekijken, inclusief de FID voor verschillende landen, verbindingen, en apparaten, voor een specifieke URL.
En de web-vitals JavaScript library kan ook de FID gegevens berekenen voor echte gebruikers op je website. Je kan dan het volgende script toevoegen aan je HTML <head> om de FID metrics door te geven naar een callback functie:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getFID } from 'https://unpkg.com/web-vitals?module';
getFID(console.log);
</script>
<!-- rest of page -->
Oorzaken van slechte scores voor First Input Delay
Slechte FID en TBT scores worden meestal veroorzaakt door client-side code die de processor van de bezoeker overbelast, zoals:
- Grote hoeveelheden render-blocking CSS en JavaScript, die het laden van de pagina pauzeren tot de code gedownload en verwerkt is
- Grote, proces-intensieve scripts die meteen uitgevoerd worden bij het laden van de pagina
- Langlopende of slecht geoptimaliseerde JavaScript taken
Standaard worden browsers op één enkele thread uitgevoerd, waardoor er dus maar één taak tegelijk uitgevoerd kan worden. Als een JavaScript functie een seconde kost om uitgevoerd te worden, worden alle processen voor de weergave tijdens die seconde tegengehouden. De pagina kan dan niet reageren op input van de gebruiker, het DOM niet bijwerken, geen animaties tonen, ga zo maar door. In oudere browsers worden zelfs GIFjes geblokkeerd.
First Input Delay scores verbeteren
Een client-side JavaScript audit kan problemen boven tafel brengen, maar meestal komt het neer op het verwijderen van overbodige code en ervoor zorgen dat taken snel uitgevoerd worden.
De volgende tips helpen je richting een betere FID score:
- Genereer en cache zoveel mogelijk statische HTML content op de server. Probeer zo min mogelijk client-side JavaScript frameworks te gebruiken om dezelfde HTML voor iedereen te tonen.
- Zorg ervoor dat de browser bestanden effectief kan cachen. Stel de juiste Expires, Last-Modified, en ETag hashes in bij de HTTP header, zodat bestanden niet onnodig nogmaals opgevraagd worden.
- Gebruik progressieve technieken voor verbetering, zodat de interface in HTML en CSS bruikbaar is voordat JavaScript uitgevoerd wordt.
- Verwijder ongebruikte JavaScript en CSS bestanden.
- Minimaliseer je JavaScript en CSS bestanden.
- Voorkom excessief gebruik van zware CSS eigenschappen, zoals box-shadow en filter.
- Gebruik asynchrone, uitgestelde of ES module JavaScript om het uitvoeren van scripts uit te stellen.
- Minimaliseer externe JavaScript verzoeken voor analytics, social media widget, forums en dergelijke. Deze kunnen al snel optellen tot meerdere megabytes aan JavaScript.
- Lazy-load JavaScript componenten op aanvraag, zoals chat-widgets, videoplayers, etc.
- Stel het laden van minder belangrijke scripts uit, zoals analytics, advertenties en social media tools.
- Deel langlopende JavaScript taken op in een aantal kleinere taakjes die uitgevoerd worden na een korte requestIdleCallback, setTimeout, of requestAnimationFrame
- Overweeg of je langlopende JavaScript processen kan uitvoeren in een web worker, die een achtergrond-thread gebruikt.
Cumulative Layout Shift (CLS)
CLS meet de visuele stabiliteit van de pagina. Dat gaat dus over onverwachte bewegingen of verspringingen in de pagina, met name tijdens de eerste keer laden.
CLS berekent een score voor het aantal elementen dat zonder interactie of waarschuwing toch beweegt. Je hebt dit vast wel eens gezien bij het lezen van een artikel op een mobiel apparaat: de tekst verspringt opeens, en je bent de draad van het verhaal kwijt. In de meest irritante gevallen zorgt het er zelfs voor dat je op een verkeerde link klikt.
CLS problemen vallen vooral op wanneer een grote afbeelding of advertentie boven de huidige positie op de pagina laadt, en die opeens honderden pixels in de hoogte inneemt.
Cumulative Layout Shift scores worden berekend door de volgende gegevens met elkaar te vermenigvuldigen:
- De impact verhouding: Dit is het totale gebied van alle onstabiele elementen in de viewport, oftewel de verspringende onderdelen. Als deze elementen 60% van de viewport beslaan, is de impactverhouding 0.6. Overigens worden de elementen die de verspringing veroorzaakten, zoals een afbeelding of advertentie, gezien als stabiel, aangezien ze niet meer bewogen nadat ze weergegeven zijn.
- De afstandsverhouding: Dit is de grootste afstand die een onstabiel element in de viewport bewogen heeft. Als de grootste verspringing van een element de beweging is van 0,100 naar 0,800, dan is deze dus 700 verticale pixels opgeschoven. Als de viewport in totaal 1000 pixels hoog is, zal de afstandsverhouding 700 px/1000 px =0.7 zijn. De berekening van de Cumulative Layout Shift score is dan 0.6 x 0.7 = 0.42.
Google heeft aanpassingen gedaan vanwege de volgende situaties:
- Verschuiving in layouts worden gegroepeerd in “sessions” die vijf seconden duren, maar na één seconde sluiten als er geen verschuivingen meer zijn. Als er twee of meer verschuivingen zijn binnen een seconde, dan worden die scores erbij opgeteld.
- Layout verschuivingen worden niet meegenomen 500 ms nadat een gebruiker ergens mee gewerkt heeft, bijvoorbeeld ergens op geklikt. In sommige gevallen activeert dat DOM updates (zoals het openen van een menu, tonen van een foutmelding, een dialoogvenster openen).
- Single-page applications die langer open blijven en meerdere DOM updates maken ondervinden hier geen nadelige effecten van.
Pagina’s met een CLS score onder de 0.1 worden gezien als goed (groen). Pagina’s die boven de 0.25 zitten worden gezien als slecht (rood):
Cumulative Layout Shift analysetools
CLS metrics kunnen berekend worden in het DevTools Lighthouse panel, in PageSpeed Insights, en de web.dev Measure tools:
De Web Vitals extensie voor Google Chrome toont ook de CLS metric:
Net als bij LCP en FID kan het Chrome User Experience Report de mogelijkheid bieden om de echte gebruiksstatistieken te bekijken, inclusief de CLS voor verschillende landen, verbindingen, en apparaten, voor een specifieke URL.
De web-vitals JavaScript library kan ook de CLS data voor echte gebruikers op je website berekenen, net als voor LCP en FID. Je kan ook weer het onderstaande script toevoegen aan je HTML <head> om de CLS metrics naar een callback functie te sturen:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getCLS } from 'https://unpkg.com/web-vitals?module';
getCLS(console.log);
</script>
<!-- rest of page -->
Oorzaken van een lage Cumulative Layout Shift score
Lage CLS scores worden meestal veroorzaakt door bestanden op de pagina die langzaam laden, of dynamische DOM elementen:
- Er is geen ruimte gereserveerd voor afbeeldingen, iframes, advertenties en dergelijke.
- Content wordt dynamisch toegevoegd aan het DOM, meestal na netwerkverzoeken voor bijvoorbeeld advertenties of social media widgets.
- Het laden van een webfont zorgt voor een zichtbare Flash of Invisible Text (FOIT) of Flash of Unstyled Text (FOUT).
Cumulative Layout Shift scores verbeteren
Een client-side audit kan ook hier problemen boven tafel brengen, maar meestal los je al een hoop op door ruimte te reserveren voor content voordat dit gedownload wordt. De tips voor het optimaliseren voor de server die we bij de Largest Contentful Paint noemden zullen ook hier helpen, maar er zijn nog extra verbeteringen mogelijk:
- Voeg width en height attributen toe aan
<img>en<iframe>tags in je HTML en gebruikt de nieuwe CSS aspect-ratio eigenschap om genoeg ruimte op de pagina te reserveren. - Stel de juiste afmetingen in voor containerelementen die tragere externe content bevatten, zoals advertenties en widgets.
- Zorg ervoor dat afbeeldingen en andere assets zo vroeg mogelijk opgevraagd worden en bovenaan de pagina getoond worden. Een preload kan ook hier uitkomst bieden.
- Minimaliseer het gebruik van webfonts, en kijk of je mogelijk algemeen beschikbare OS-fonts kan gebruiken.
- Laad webfonts en zet CSS font-display op optioneel of “swap”. Zorg ervoor dat je een reservelettertype van dezelfde grootte hebt om de verschuiving in de layout te minimaliseren.
- Voorkom het toevoegen van elementen aan de bovenkant van de pagina, tenzij dit reageert op een actie van de gebruiker, zoals een klik.
- Zorg ervoor dat reacties op input van gebruikers binnen 500 milliseconden van de activering voltooid zijn.
- Gebruik CSS transform en opacity voor efficiëntere animaties die geen herlading van de layout vereisen.
- Overweeg belangrijk inline CSS. Voeg belangrijke CSS die direct bij het laden zichtbaar is (zonder scrollen) toe in een
<link>block bovenaan de pagina, en laadt de andere stylesheets asynchroon. - Indien nodig kan je containment gebruiken, een nieuwe CSS feature waarmee je geïsoleerde subtrees van een pagina kan identificeren. De browser kan de verwerking optimaliseren door specifieke DOM contentblocks weer te geven, of juist niet.
Samenvatting
Developers hebben niet altijd zin om maar naar de pijpen van Google te dansen. Het bedrijf heeft heel veel macht, en kleine updates in de zoekmachine kunnen veel impact hebben op de winstgevendheid en efficiëntie van organisaties die afhankelijk zijn van hun online activiteiten.
Met dat in het achterhoofd probeert Core Web Vitals meer te gaan voor de “wortel” dan de “stok”. Goed geoptimaliseerde, en prettig te gebruiken websites die zich verre houden van duistere praktijken, krijgen zo een betere positie dan overvolle websites boordevol pop-ups met een slechte mobiele user interface.
Core Web Vitals biedt een meetbare manier om de user experience (UX) te bepalen, waardoor je beter kan focussen op de belangrijkste aspecten om te verbeteren. Deze veranderingen leveren je misschien niet direct meer omzet op, maar je gebruikers zullen er wel blij mee zijn, en loyaler worden.
Heb jij nog andere tips voor het verbeteren van Core Web Vitals? Deel ze in de reacties hieronder!
Laat een reactie achter