Het web staat niet stil. De introductie van zogenaamde KPI's om de user experience in kaart te brengen, ook niet. Daarin is de metric CLS vrij nieuw, toch?
Qua metric wel, maar wie heeft ondertussen niet legio websites bezocht waar de website tijdens of na het laden nog versprong? Dit kan in het laad-stadium of natuurlijk bij interactie vervelend zijn of nadelig uitpakken.
Per ongeluk akkoord gaan met een cookie-verklaring is ons ongetwijfeld allemaal wel eens overkomen. Maar ook het onbedoeld klikken op een advertentie kan een gevolg zijn. Of abusievelijk een bestelling plaatsen.
Kortom, geen nieuw fenomeen, dat sinds kort door Google een eigen noemer heeft gekregen. De afkorting luidt CLS en staat voor Cumulative Layout Shift. Google zegt hierover het volgende:
(CLS) score is determined by calculating the sum of all unexpected layout shift scores from page load until the page's lifecycle state changes to hidden.
Cumulative Layout shift criteria
Waarom 500 milliseconden? Omdat dit gemiddeldweg het tijdsbestek is waarin een gebruiker een response verwacht van de website en browser, nadat de gebruiker een interactie is aangegaan. Alle layout wijzigingen na 500 milliseconden zal daardoor al snel door een gebruiker als onverwacht reponse worden gezien.
CLS score bepaling
De verschuivingsscore wordt bepaald op basis van hoeveel verschuiving er plaats vond. Wanneer er voor 50% verandering plaats vindt in het zichtbare gedeelte, is er sprake van een score van 0.5. In het voorbeeld is te zien dat data dat via bijvoorbeeld een AJAX request geladen wordt, geleidelijk in beeld komt. Dit zorgt voor verschuivingen indien resultaten op volgorde worden weergegeven. De uitdaging is hier correct op in te spelen, door ook de data dat via een AJAX request wordt opgehaald, bijvoorbeeld alfabetisch plaats te laten vinden. Zo wordt voorkomen dat men onverwacht en ongewild op andere knoppen klikt.
Alhoewel er gestreefd moet worden naar een CLS score van 0, geeft het artikel van Google aan dat een verschuiving binnen een website of applicatie soms bewust kan zijn.
Cumulative Layout Shift binnen websites
Op vrijdag 7 juni 2019 was ik als spreker aanwezig op het MageTitans event. Daar behandelde ik het performance aspect binnen websites en webshops, waar ook verspringingen in het laadproces aan de orde kwam. Daarbij tekende ik op dat je verschuivingen tijdens en na het laadproces tot een minimum zou moeten willen beperken. Ongeveer een week later werd dit als nieuwe metric naar buiten gecommuniceerd door Google.
Inmidels zijn al 5 miljoen websites binnen het Chrome User Experience Report (CrUX) voorzien van een CLS score.
CLS beperken
Dat kan door een achtergrondafbeelding in een placeholder met juiste dimensies te laden of geen content-elementen spontaan boven andere elementen te introduceren binnen het zichtbare gedeelte van de webpagina. Bijvoorbeeld, het juist lazy-loaden van hero afbeeldingen is dus de kunst.
Zijn er elementen die wegens toepassing van Critical CSS kunnen verschuiven nadat de website volledig geladen is? Overweeg dan om deze elementen te verbergen totdat de gehele stylesheet geladen is, bijvoorbeeld wanneer de elementen niet van primair belang is in de eerste seconden (zoals, datum bij een bericht of reviews bij een product, in plaats daarvan is de introductie of productnaam en -prijs belangrijker).
Daarnaast is het noodzaak om de main thread van de browser zo inactief mogelijk te houden. Op de main thread worden JavaScript taken afgewikkeld. Is er veelvuldig sprake van JavaScript taken, dan is het mogelijk dat hiermee de main thread van de browser geblokkeerd wordt en het andere taken ophoudt. Denk aan het invoegen van content of webshop taken uitvoeren naar aanleiding van een button-klik.
Over de main thread in combinatie met Estimated Input Latency schreef ik al eens eerder.
Aan de slag met CLS monitoring
Wanneer je reeds bekend bent met bijvoorbeeld IntersectionObserver zal het zelf monitoren eenvoudiger gaan. Via de PerformanceObserver API kun je voor eigen websites de verschuivingen monitoren en bijvoorbeeld doorsturen naar je Analytics omgeving. Wel is de Layout Instability API nog onderdeel van W3C's Web Platform Incubator Community Group (WICG). Men staat dus nog open voor feedback omtrent de API uitkomsten.
Wil je verspringen in layout voor je website of webshop beperken ten behoeve van een verbeterde user experience? Ik hoor het graag.
