Problemen met de Cumulative Layout Shift op je website? Of weet je niet zeker wat Cumulative Layout Shift betekent?
Cumulative Layout Shift, afgekort CLS, is een metric die deel uitmaakt van Google’s Core Web Vitals initiatief.
Kort gezegd meet het hoeveel van de content van een webpagina “onverwacht” verschuift. Een hoge CLS score kan duiden op een slechte gebruikerservaring en kan ook een rem zijn op de SEO van je site.
In dit artikel leer je alles wat je moet weten over Cumulative Layout Shift en hoe het WordPress sites (en het web in het algemeen) beïnvloedt.
Wat is Cumulative Layout Shift (CLS)? Uitleg over de betekenis van Cumulative Layout Shift
Cumulative Layout Shift is de maat voor hoeveel een pagina op je site onverwacht beweegt tijdens het bezoek van een gebruiker, zoals gemeten door de Layout Instability API, een gestandaardiseerde API voor het testen van de prestaties.
Cumulative Layout Shift (CLS) is een van de drie statistieken in Google’s Core Web Vitals initiatief, samen met Largest Contentful Paint (LCP) en First Input Delay (FID).
Om de betekenis van Cumulative Layout Shift te begrijpen, is het belangrijk om de layoutverschuiving in het algemeen te bespreken.
Een layoutverschuiving treedt op wanneer content op je site onverwacht “verplaatst” of “verschuift”.
Of, in technische termen, wanneer een element dat zichtbaar is in de viewport van startpositie verandert tussen twee frames.
Een veel voorkomend voorbeeld is dat je midden in het lezen van een blok tekst zit… maar dan verschijnt er plotseling een laat ladende advertentie die de tekst naar beneden duwt.
Hier is een ander voorbeeld van Google dat laat zien hoe dit gebeurt:
Je bent bijna zeker wel eens layoutverschuivingen tegengekomen bij het surfen op het web, zelfs als je ze niet bij die naam kent.
Een enkel bezoek kan meerdere afzonderlijke layoutverschuivingen hebben. Daarom probeert de Cumulative Layout Shift metric het hele plaatje te vangen door het totale aantal onverwachte layoutverschuivingen op een pagina te meten*.
*De exacte meting is iets technischer na enkele wijzigingen door Google, maar dit is nog steeds het basisidee. Als je geïnteresseerd bent in de details, lees je er hier meer over.
Waarom is Cumulative Layout Shift slecht?
De belangrijkste reden waarom Cumulative Layout Shift slecht is, is dat het een slechte gebruikerservaring op je site oplevert.
In het beste geval is het lichtelijk vervelend voor je bezoekers. In het ergste geval kan het bezoekers aanzetten tot acties die ze niet willen ondernemen.
Stel je bijvoorbeeld voor dat een gebruiker op “Cancel” wil klikken, maar per ongeluk op “Confirm” klikt omdat een verschuiving in de layout de positie van de knoppen verplaatste op het moment dat de persoon aan het klikken was.
Behalve dat het de ervaringen van je menselijke bezoekers beïnvloedt, kan een slechte Cumulative Layout Shift score ook een belemmering zijn voor de ranking van je site in zoekmachines.
Vanaf Google’s Page Experience update (die in augustus 2021 volledig uitgerold is) gebruikt Google Core Web Vitals als een van zijn SEO rankingfactoren. Omdat Cumulative Layout Shift deel uitmaakt van Core Web Vitals, betekent dat dat het de zoekprestaties van je site kan beïnvloeden.
In principe zal het oplossen van problemen met Cumulative Layout Shift op je site helpen om hem beter te maken voor zowel menselijke bezoekers als zoekmachines.
Dus – wat kan de oorzaak zijn van Cumulative Layout Shift? Dat behandelen we nu.
Wat veroorzaakt Cumulative Layout Shift?
Hier volgt een kort overzicht van de meest voorkomende oorzaken van layoutverschuiving:
- Het niet instellen van afmetingen voor afbeeldingen, iframes, video’s of andere embeds.
- Problemen met het laden van aangepaste lettertypen, waardoor tekst onzichtbaar kan zijn of van grootte kan veranderen bij het laden van aangepaste lettertypen.
- Het aanbieden van responsieve advertenties (bijv. AdSense) met verschillende afmetingen (en het niet reserveren van ruimte voor die advertenties).
- Het dynamisch injecteren van content met plugins (cookietoestemmingsberichten, leadgeneratieformulieren, enz.).
- Animaties gebruiken zonder de CSS Transform property.
Later in dit artikel gaan we dieper in op deze problemen en laten we je zien hoe je elk veel voorkomend probleem kunt oplossen.
Zo meet je Cumulative Layout Shift: beste testtools
Er is een aantal tools dat je kunt gebruiken om de Cumulative Layout Shift score van je site te testen.
Cumulative Layout Shift is onderdeel van de Lighthouse audit, dus elk snelheidstestprogramma dat Lighthouse gebruikt als onderdeel van zijn audit zal CLS gegevens bevatten – dit zijn PageSpeed Insights, GTmetrix, Chrome Developer Tools, en vele andere populaire testprogramma’s.
Hier zijn enkele van de top Cumulative Layout Shift testtools die erg nuttig zijn.
PageSpeed Insights
PageSpeed Insights is een van de nuttigste tools voor het beoordelen van de toestand van de layoutverschuiving van je site, omdat het je twee gegevensbronnen biedt:
- Veldgegevens – echte gebruikersgegevens uit het Chrome UX rapport (aangenomen dat je site genoeg verkeer heeft om in het rapport te worden opgenomen). Hiermee kun je de werkelijke Cumulative Layout Shift gegevens zien voor je echte menselijke bezoekers. Dit zijn ook de gegevens die Google gebruikt als rankingsignaal.
- Labgegevens – gesimuleerde testgegevens die worden verzameld door Lighthouse (dat is wat PageSpeed Insights gebruikt om zijn prestatieanalyserapporten te genereren).
Je kunt ook gegevens bekijken voor zowel desktop als mobiel door te wisselen tussen de tabbladen.
Let op – de labgegevens kunnen alleen layoutverschuivingen meten die optreden tijdens het laden van de pagina, dus je resultaten voor echte gebruikers kunnen iets hoger uitvallen als je layoutverschuivingen hebt die optreden na het laden van de pagina.
Chrome Developer Tool
Chrome Developer Tools biedt enkele nuttige resources voor zowel het meten van CLS als het debuggen van de individuele layoutverschuivingen die op je site optreden.
Ten eerste kun je een Lighthouse audit uitvoeren om de CLS score van je site te bekijken. Dit gaat als volgt:
- Open Chrome Developer Tools.
- Ga naar het tabblad Lighthouse.
- Configureer je test.
- Klik op de knop Analyze page load om de test uit te voeren.
Na even wachten zou je dan de gewone Lighthouse audit-interface moeten zien (die veel lijkt op PageSpeed Insights).
Chrome Developer Tools laat je echter ook dieper in CLS graven met zijn Rendering analyse. Hiermee kun je individuele verschuivingsgebieden in je site markeren, wat je helpt bij het debuggen.
Hier zie je hoe:
- Klik op het “drie puntjes” pictogram in de rechterbovenhoek van de Chrome Developer Tools interface.
- Selecteer More Tools → Rendering, wat onderaan een nieuwe interface zou moeten openen.
- Vink het vakje aan voor Layout Shift Regions.
Herlaad nu de pagina die je wilt testen en Chrome zou alle gebieden met layoutverschuivingen moeten markeren met een blauw vak. Deze markeringen verschijnen op de pagina zelf terwijl de content wordt geladen en verdwijnen als de verschuiving is voltooid.
Als de highlights te snel verschijnen om te kunnen volgen, kun je je site vertragen en kijken hoe hij frame voor frame wordt geladen via het tabblad Performance.
Google Search Console
Hoewel je met Google Search Console geen labtesten kunt uitvoeren om Cumulative Layout Shift te bepalen, kun je wel op een eenvoudige manier problemen met Cumulative Layout Shift op je site bekijken, zoals gemeten door het Chrome UX rapport.
Het voordeel van het gebruik van Google Search Console in plaats van andere tools is dat je snel problemen over je hele site kunt zien in plaats van pagina voor pagina te moeten testen.
Hier lees je hoe je potentiële problemen op je site kunt bekijken:
- Ga naar Google Search Console. Als je je site nog niet hebt geverifieerd, kun je onze handleiding volgen over hoe je Google Search Console kunt verifiëren.
- Open het rapport Core Web Vitals onder Experience.
- Klik op Open Report naast Mobile of Desktop, afhankelijk van wat je wilt analyseren.
Indien van toepassing markeert Google URL’s met problematische Cumulative Layout Shift scores.
Let op – je ziet hier alleen gegevens als je site genoeg maandelijks verkeer heeft om in het Chrome UX rapport te worden opgenomen.
Layout Shift GIF Generator
Zoals de naam al zegt, genereert Layout Shift GIF Generator een GIF van de layoutverschuivingen op je site, zodat je precies kunt zien welke content problemen veroorzaakt. Het geeft je ook je score, hoewel dat niet de hoofdzaak is van de tool.
Het enige wat je doet is de URL toevoegen die je wilt testen en kiezen tussen mobiel of desktop. Vervolgens genereert het een GIF van je site met groene highlights die de exacte elementen tonen die verschuiven.
Door te zien welke elementen verschuiven en bijdragen aan je Cumulative Layout Shift score, weet je precies waar je je op moet richten om de scores van je site te verbeteren.
Wat is een goede Cumulative Layout Shift score?
Volgens het Core Web Vitals initiatief van Google is een goede Cumulative Layout Shift score 0,1 of minder.
Als je Cumulative Layout Shift score tussen 0,1 en 0,25 ligt, definieert Google dat als “Needs Improvement”.
En als je Cumulative Layout Shift score hoger is dan 0,25, dan definieert Google dat als “Poor”.
Hier is een grafiek van Google’s Core Web Vitals website die deze scores visueel weergeeft:
Zo los je Cumulative Layout Shift in WordPress (of andere platforms) op
Nu je begrijpt wat er gebeurt met Cumulative Layout Shift, is het tijd om over te gaan op enkele bruikbare tips over hoe je Cumulative Layout Shift in WordPress kunt verhelpen.
Hoewel deze tips uit een van WordPress hoek komen, zijn ze allemaal universeel, en kun je ze ook toepassen op andere websitebuildingtools.
Geef altijd afmetingen op voor afbeeldingen
Een van de meest voorkomende oorzaken van layoutverschuiving zijn laat ladende afbeeldingen die content verplaatsen, vooral als je gebruik maakt van tactieken als lazy loading..
Om dit te voorkomen kun je de afmetingen van een afbeelding opgeven in de code wanneer je die insluit. Op die manier zal de browser van de bezoeker die ruimte reserveren, zelfs als de afbeelding nog niet geladen is, waardoor de afbeelding de content niet hoeft te verplaatsen.
Als je afbeeldingen insluit via de WordPress editor (ofwel de Gutenberg blokeditor of de klassieke TinyMCE editor), dan hoef je niet handmatig de afmetingen van de afbeelding op te geven, omdat WordPress dit automatisch voor je doet.
Hetzelfde geldt voor populaire paginabuilderplugins zoals Elementor, Divi, Beaver Builder, enzovoort.
Er kunnen echter problemen ontstaan als je handmatig afbeeldingen insluit met je eigen code, wat kan gebeuren als je content toevoegt aan een plugin, de templatebestanden van je childhema bewerkt, enzovoort.
De HTML code voor het insluiten van een basisafbeelding ziet er als volgt uit:
<img src="https://kinsta.com/example-image.jpg" alt="An example image">
Om de afmetingen te specificeren kun je height en width parameters toevoegen. Hier is een voorbeeld van hoe dat eruit zou kunnen zien voor een afbeelding van 600x300px:
<img src="https://kinsta.com/example-image.jpg" alt="An example image" width="600" height="300">
Veel WordPress performanceplugins bevatten ook features om dit te automatiseren, zoals de Add Missing Image Dimensions features in WP Rocket of Perfmatters.
Geef altijd afmetingen op voor video’s, iframes en andere insluitingen
Net als bij afbeeldingen moet je ook bij video’s, iframes en andere insluitingen de afmetingen opgeven.
De meeste insluitprogramma’s van websites geven automatisch afmetingen op voor de insluiting.
Als je bijvoorbeeld kijkt naar de insluitcode van YouTube, dan zie je dat die afmetingen bevat:
Hetzelfde geldt voor veel andere diensten.
Als je insluitcode echter niet de hoogte en breedte aangeeft, kun je deze afmetingen handmatig toevoegen aan de insluitcode.
Herstel en optimaliseer het laden van lettertypen
Problemen met het laden en optimaliseren van lettertypen kunnen een andere veel voorkomende bron van layoutverschuivingen zijn via twee potentiële problemen:
- Flash of invisible text (FOIT) – de pagina wordt aanvankelijk geladen zonder dat er enige tekstcontent verschijnt. Zodra het aangepaste lettertype wordt geladen, verschijnt de tekst plotseling (waardoor bestaande content kan verschuiven).
- Flash of unstyled text (FOUT) – de tekst wordt geladen met een systeemlettertype (zonder stijl). Zodra het aangepaste lettertype wordt geladen, verandert de tekst in dat aangepaste lettertype, waardoor content kan verschuiven omdat de tekstgrootte en spatiëring anders kunnen zijn.
Om deze problemen te voorkomen moet je de manier waarop je lettertypen op je site laadt optimaliseren (wat ook enkele voordelen kan hebben voor de prestaties van je site).
Lettertypen lokaal hosten en vooraf laden
Door lettertypen lokaal te hosten en vooraf te laden, vertel je de browsers van bezoekers om een hogere prioriteit te geven aan het laden van aangepaste lettertypebestanden.
Door lettertypebestanden vóór andere bronnen te laden, kun je ervoor zorgen dat de lettertypebestanden al geladen zijn als de browser je content begint te renderen, wat problemen met FOUT en FOIT kan voorkomen.
Om te leren hoe je lettertypen lokaal kunt hosten in WordPress, kun je onze complete handleiding voor het lokaal hosten van lettertypen in WordPress lezen.
Vanaf daar kun je het voorladen van lettertypen handmatig of met behulp van een plugin instellen. De meeste performanceplugins bevatten opties om lettertypen voor te laden, waaronder WP Rocket, Perfmatters, Autoptimize, en andere.
Als je Google Fonts gebruikt, kun je ook de gratis OMGF plugin gebruiken om de lettertypen lokaal te hosten en voor te laden.
Je kunt lettertypen ook handmatig preloaden door de code toe te voegen aan de <head> sectie van je site.
Hier is een voorbeeld van de code – zorg ervoor dat je de code vervangt door de werkelijke naam/locatie van het lettertypebestand dat je wilt voorladen:
<link rel="preload" href="https://kinsta.com/fonts/roboto.woff2" as="font/woff2" crossorigin>
Je kunt het direct toevoegen met een WordPress childthema of het injecteren met de wp_head hook en een plugin als Code Snippets.
Font-Display op Optional of Swapp zetten
Met de CSS Font-Display property kun je het rendergedrag van de lettertypen op je site regelen en FOIT vermijden.
In wezen kun je hiermee een fallback lettertype gebruiken in situaties waarin je eigen lettertype nog niet geladen is.
Er zijn twee hoofdopties die je kunt gebruiken om CLS aan te pakken:
- Swap – gebruikt een fallback lettertype terwijl het aangepaste lettertype wordt geladen en verandert het in je aangepaste lettertype zodra het lettertype is geladen.
- Optional – laat de browser bepalen of een aangepast lettertype al dan niet wordt gebruikt op basis van de verbindingssnelheid van een bezoeker.
Met Swap gaat de browser altijd over op het aangepaste lettertype zodra het geladen is.
Hoewel Swap FOIT volledig oplost, kan het leiden tot FOUT. Om dit te minimaliseren moet je ervoor zorgen dat het fallback lettertype dezelfde spatiëring gebruikt als het aangepaste lettertype (in ieder geval zoveel mogelijk). Op die manier zal dat, zelfs als de letterstijl verandert, niet leiden tot layoutverschuivingen omdat de spatiëring hetzelfde zal zijn.
Met Optional geeft de browser het aangepaste lettertype 100 ms om te laden. Maar als het aangepaste lettertype dan nog niet beschikbaar is, zal de browser het fallback lettertype aanhouden en het nooit veranderen in het aangepaste lettertype voor die pageview (hij zal het aangepaste lettertype gebruiken voor volgende pageviews, omdat het lettertypebestand dan waarschijnlijk al gedownload en gecached is).
Optional kan zowel FOIT als FOUT oplossen, maar het nadeel is dat de bezoeker voor zijn eerste pageview vastzit aan het fallback lettertype.
Als je vertrouwd bent met het werken met CSS, kun je de property Font-Display in het stylesheet van je childthema handmatig bewerken.
Als je je daar niet prettig bij voelt, kun je ook enkele plugins vinden die je kunnen helpen:
- Swap Google Fonts Display – schakelt eenvoudig Font-Display Swap in voor Google Fonts.
- Asset CleanUp – ondersteunt gratis Google Fonts en aangepaste lokale fonts met de Pro versie.
- Perfmatters – biedt een feature voor Google Fonts.
Als je Elementor gebruikt, bevat Elementor ook een ingebouwde optie om dit te doen. Ga naar Elementor → Settings → Advanced. Je kunt dan de Google Fonts Load dropdown gelijk zetten aan Swap of Optional, afhankelijk van je voorkeuren:
Te complex? Overweeg een systeemlettertype!
Als al dit gepraat over preloading en Font-Display een beetje verwarrend is, is een eenvoudige oplossing om gewoon een systeemlettertype te gebruiken in plaats van een custom font stack.
Hoewel dit je ontwerpmogelijkheden beperkt, lost het problemen met Cumulative Layout Shift fonts, FOIT en FOUT volledig op. Bovendien laadt je site dan veel sneller.
Als je hierin geïnteresseerd bent, bekijk dan Brian’s handleiding voor het gebruik van een systeemlettertype op WordPress.
Reserveer ruimte voor advertenties (als je displayadvertenties gebruikt)
Als je displayadvertenties gebruikt, is het belangrijk dat je in de code van je site ruimte reserveert voor die advertenties. Dit volgt hetzelfde idee als het reserveren van ruimte voor afbeeldingen, video’s en embeds.
Displayadvertenties verdienen echter een speciale vermelding omdat het heel gebruikelijk is dat displayadvertenties laat laden als je een of andere biedingstechnologie gebruikt. Dit komt omdat de biedingstechnologie tijd nodig heeft om te werken en uit te zoeken welke advertentie getoond moet worden.
Het kan ook een probleem zijn met AdSense auto-advertenties als je dynamische advertentieslots hebt, omdat AdSense, naast het biedingsprobleem, ook advertenties van verschillende grootte laadt (zodat je de grootte van de advertentie misschien niet van tevoren weet).
Als je een van de populaire displayadvertentienetwerken gebruikt, zoals Mediavine of AdThrive, dan zouden die al tools moeten bieden om layoutverschuivingen van je advertenties te voorkomen. Als je bijvoorbeeld het gebied Ad Settings van Mediavine opent, kun je een toggle inschakelen voor Optimize Ads for CLS:
Om AdSense te optimaliseren voor Cumulative Layout Shift is het iets lastiger.
Een gebruikelijke oplossing is het toevoegen van een <div> wrapper element rond elke advertentie eenheid die een minimale hoogte specificeert met behulp van de min-height CSS property. Je kunt ook mediaqueries gebruiken om de minimale hoogte te veranderen op basis van het apparaat van de gebruiker.
Google raadt aan om de min-hoogte gelijk te stellen aan de grootst mogelijke advertentiegrootte. Hoewel dit kan leiden tot ruimteverspilling als een kleinere advertentie wordt getoond, is het de beste optie om elke kans op een layoutverschuiving uit te sluiten.
Zorg er bij het instellen van dit wrapper element voor dat je een CSS ID gebruikt in plaats van een klasse, omdat AdSense vaak de CSS klasse van ouderobjecten verwijdert.
Zo zou de CSS eruit kunnen zien:
En dan hier hoe de AdSense embed er uit zou kunnen zien:
Op de frontend zie je nu dat je site ruimte reserveert voor die advertentie, zelfs als die leeg is:
Wees slim bij het dynamisch injecteren van content met plugins
Veel WordPress sites injecteren dynamisch content voor functies als cookietoestemmingen, gerelateerde content, e-mail opt-informulieren, enzovoort.
Hoewel dit prima te doen is, moet je oppassen dat je dit niet doet op een manier die layoutverschuivingen veroorzaakt.
Een goede webontwerp best practice is hier om nooit content te injecteren boven bestaande content, tenzij de gebruiker specifiek een interactie uitvoert (bijvoorbeeld door op een knop te klikken).
Als je bijvoorbeeld een mededeling over cookietoestemming toevoegt, wil je die niet bovenaan je pagina plaatsen, omdat dan de content naar beneden wordt gedrukt (tenzij je al ruimte hebt gereserveerd voor de banner met cookietoestemming).
In plaats daarvan moet je de mededeling onderaan de pagina plaatsen, zodat zichtbare content niet naar beneden wordt geschoven.
Om te zien of dynamische content het probleem veroorzaakt, kun je de visualisatiehulpmiddelen van hierboven gebruiken (bijv. Layout Shift GIF Generator).
Als je ziet dat content van een specifieke plugin layoutverschuivingen veroorzaakt, kun je overwegen de instellingen van die plugin aan te passen of over te schakelen op een andere plugin.
Sommige cookie-goedkeuringsplugins zijn bijvoorbeeld beter dan andere als het gaat om layoutverschuivingen, dus het is de moeite waard om te experimenteren met verschillende plugins als je problemen hebt.
Als je nog dieper wilt ingaan in het gedrag van de plugin, kun je een tool voor het monitoren van de prestaties van applicaties gebruiken. Als je host met Kinsta, is Kinsta’s APM tool gratis beschikbaar in je MyKinsta dashboard, of je kunt andere APM tools vinden.
Om je te helpen plugins te testen, kun je ook de testsites van Kinsta of de DevKinsta lokale ontwikkeltool gebruiken.
Gebruik waar mogelijk de CSS Transform property voor animaties
Als je animaties op je site gebruikt, kunnen deze een andere veel voorkomende boosdoener zijn voor layoutverschuivingen.
Om problemen te voorkomen met animaties die layoutverschuivingen veroorzaken, moet je voor animaties de CSS Transform functie gebruiken in plaats van andere tactieken:
- Gebruik in plaats van de properties height en width de property transform: scale()
- Als je elementen wilt verplaatsen, gebruik dan transform: translate() in plaats van top, bottom, right, of left
Dit is meer een technische tip, dus het is onwaarschijnlijk dat je dit hoeft te doen, tenzij je je eigen CSS toevoegt. Voor meer informatie kun je Google’s pagina over CLS en animaties/overgangen lezen.
Samenvatting
Als je website een hoge Cumulative Layout Shift score heeft, is het belangrijk om dit op te lossen, zowel om een betere ervaring te creëren voor je menselijke bezoekers als om de prestaties van je site in de zoekresultaten van Google te maximaliseren.
Twee van de meest voorkomende problemen zijn ontbrekende afmetingen voor afbeeldingen/insluitingen en problemen met het laden van lettertypen. Als je die oplost, zou je op weg moeten zijn naar een veel betere score.
Andere sites moeten misschien verder gaan en zich verdiepen in het laden van advertenties, dynamische content en animaties. Als je moeite hebt met het zelf uitvoeren van dit soort optimalisaties, kun je overwegen samen te werken met een WordPress bureau of freelancer.
Voor meer informatie over Core Web Vitals in het algemeen kun je de volledige Kinsta handleiding voor Core Web Vitals lezen.
En als je een WordPress host wilt die je kan helpen een goed presterende site te maken die het goed doet in Core Web Vitals, overweeg dan het gebruik van Kinsta’s managed WordPress hosting – we migreren je WordPress sites gratis!
Laat een reactie achter