Kumulativ layoutförskjutning (CLS)

Kumulativ layoutförskjutning mäter visuell instabilitet genom att kvantifiera hur mycket synligt innehåll rör sig oväntat under en sidas livstid. Det är en av Googles Core Web Vitals, och till skillnad från laddnings- och responsivitetsmått är det en enhetslös poäng snarare än en varaktighet, beräknad utifrån andelen av visningsporten som påverkas av en förskjutning och avståndet innehållet flyttas. Googles publicerade tröskelvärde behandlar 0.1 eller mindre som bra vid den sjuttiofemte percentilen av verkliga användarupplevelser.

Beteendet den fångar upp är bekant för alla som har försökt klicka på en länk bara för att få en annons laddad ovanför och knuffa sidan nedåt, eller börjat läsa ett stycke som hoppade när ett webbteckensnitt byttes in. Utöver irritationen är den praktiska konsekvensen felklick: innehåll som flyttas mellan det ögonblick en användare bestämmer sig för att trycka och det ögonblick de gör det resulterar i fel åtgärd, vilket på ett handels- eller bankgränssnitt kan innebära ett felaktigt köp, en felaktig borttagning eller en oavsiktlig navigering.

Orsakerna är väl dokumenterade och oftast enkla att förebygga. Bilder och videor utan explicita dimensioner orsakar omflöde när de laddas, eftersom webbläsaren inte kan reservera rätt utrymme i förväg. Annonser, inbäddningar och iframes som infogas i flödet utan en reserverad behållare trycker ner innehållet. Webbteckensnitt som byts från en reservation med olika mätvärden omflöder texten. Innehåll som injiceras dynamiskt ovanför befintligt innehåll, såsom banners, aviseringar och samtyckesmeddelanden, flyttar allt nedanför. Animeringar som ändrar layoutegenskaper snarare än att transformera och opacitet utlöser omflöde för varje bildruta.

Motsvarande korrigeringar är bland de billigaste tillgängliga inom prestandaarbete. Att ställa in bredd- och höjdattribut eller ett bildförhållande på media reserverar utrymme före inläsning. Att allokera fasta behållare för annonser och inbäddningar förhindrar att infogning förskjuter innehåll. Att matcha reservteckensnittsmått med webbteckensnittet och använda lämpliga teckensnittsinläsningsstrategier minskar omflödet vid byte. Att infoga dynamiskt innehåll nedanför vikningen eller i överlägg snarare än ovanför befintligt innehåll undviker den mest störande kategorin. Att animera endast transformering och opacitet håller rörelse borta från layoutbanan.

Mätning kräver fokus på sessionen snarare än enbart på sidinläsning. Mätvärdet ackumuleras över sidans livslängd, inklusive förändringar som sker under scrollning och interaktion, vilket innebär att en sida som får bra resultat vid initial inläsning fortfarande kan få dåligt resultat totalt sett på grund av att innehåll som laddas långsamt anländer utan reserverat utrymme. Förändringar som sker inom ett kort fönster efter en användarinteraktion exkluderas, med motiveringen att innehåll som rör sig som svar på en avsiktlig handling är förväntat snarare än störande.

Samtyckesmeddelanden och reklambanners förtjänar särskild uppmärksamhet eftersom de infogas sent, vanligtvis hanteras utanför den huvudsakliga utvecklingsprocessen och ofta förskjuter innehåll. En banner som visas högst upp i dokumentet efter rendering trycker ner allting exakt i det ögonblick en besökare börjar läsa eller sträcker sig efter en länk. Att presentera element som överlägg som inte ingår i layouten, eller att reservera utrymme för dem innan de renderas, löser problemet utan att ta bort dem. Eftersom dessa komponenter ofta konfigureras av marknadsförings- eller juridiska team via tredjepartsverktyg kräver lösningen vanligtvis en kommunikation mellan funktioner snarare än enbart en kodändring.

Eftersom orsakerna vanligtvis finns i mallar, annonsintegrationer och tredjepartsinbäddningar snarare än i en enda komponent, tenderar åtgärden att kräva samordning mellan de team som ansvarar för varje komponent. I praktiken är detta standard. webbprestanda arbete, och det är ett av de områden där kopplingen till kommersiella resultat är mest direkt, eftersom layoutinstabilitet på en produkt- eller kassasida leder till felaktiga tryckningar och övergivna kunder som en UX revision kommer att dyka upp som användbarhetsfel utan att nödvändigtvis den underliggande tekniska orsaken identifieras.