CLS (Cumulative Layout Shift) är det Core Web Vitals-mått som fångar visuell stabilitet: hur mycket synligt innehåll hoppar runt utan att användaren gjort något. Till skillnad från LCP och INP handlar CLS inte om tid, utan om hur mycket och hur långt element flyttar sig. Ett klassiskt exempel är knappen som flyttas en centimeter precis när du ska klicka, för att en bild eller en cookie-banner laddades in ovanför. Det irriterar användaren, kan sänka konverteringen och påverkar hur Google bedömer sidans upplevelse.
CLS är summan av poängen för alla oväntade layoutskift inom sidans värsta tidsfönster – ett begrepp som förklaras längre ner. Varje enskilt skift får en poäng enligt formeln impact fraction × distance fraction, där båda faktorerna är andelar av viewporten. Impact fraction är hur stor del av det synliga fönstret som påverkas av instabila element – både där de var före skiftet och där de hamnade efter. Distance fraction är den längsta sträckan ett instabilt element flyttade sig, delat med viewportens största sida (höjden på mobil).
Ett räkneexempel med tänkta värden: en textsektion som täcker 40 % av viewportens höjd trycks ner 10 % när en bild laddas in ovanför. Impact fraction blir 0,5 (40 % ursprunglig yta plus 10 % ny yta) och distance fraction 0,1. Poängen för skiftet blir 0,5 × 0,1 = 0,05. Ett skift av den storleken är alltså acceptabelt på egen hand, men två sådana i följd landar på gränsen. Formeln och definitionerna finns hos web.dev.
Viktigt att veta: skift som sker inom 500 millisekunder efter en användarinteraktion (klick, tryck eller tangenttryckning) räknas inte. Att en utfällbar sektion expanderar när någon klickar på den är förväntat och påverkar inte CLS. Scroll räknas dock inte som interaktion – innehåll som hoppar medan användaren scrollar räknas fullt ut.
Google räknar ett CLS-värde på 0,1 eller lägre som bra, 0,1–0,25 som "behöver förbättras" och över 0,25 som dåligt. Tröskeln bedöms på den 75:e percentilen av sidladdningarna – tre av fyra besök måste alltså klara 0,1 för att sidan ska räknas som godkänd. Mobil och desktop bedöms separat. Mobilen är nästan alltid den svåra delen eftersom smalare skärmar gör att samma element trycker ner innehåll längre i förhållande till viewporten. Tröskelvärdena är dokumenterade hos web.dev.
Fältdata (verkliga besök) hittar du i Core Web Vitals-rapporten i GSC och i PageSpeed Insights. Labbdata från Lighthouse fångar bara skift under den initiala laddningen, så en sida kan se ren ut i labbet men ändå få dåligt CLS i fält på grund av innehåll som laddas sent eller flyttar sig vid scroll.
Ett session window är en grupp av layoutskift som ligger nära varandra i tid: skift som sker inom 1 sekund efter föregående skift grupperas i samma fönster, och ett fönster kan som mest vara 5 sekunder långt. CLS-poängen för sidan är poängen för det fönster som har högst summa – inte summan av alla skift under hela besöket. Modellen infördes 2021 för att långlivade sidor (till exempel single page-appar) inte skulle straffas för att de är öppna länge. Bakgrunden beskrivs hos web.dev.
Konsekvensen för dig som felsöker: ett enda stort skift kan ge samma poäng som tio små tätt intill varandra. Sprids skiften ut med mer än en sekund emellan hamnar de i olika fönster och bara det värsta räknas. Det betyder att du ska leta efter den värsta klungan av skift, inte bara det största enskilda elementet.
De flesta CLS-problem beror på att webbläsaren inte vet hur mycket plats något kommer att ta innan det laddats. De vanligaste orsakerna är:
width och height (eller aspect-ratio i CSS) reserveras ingen yta, och allt under trycks ner när filen kommer.font-display, preload och size-adjust på fallbacken.top, height eller margin tvingar fram en ny layoutberäkning, medan transform flyttar elementet utan att påverka omgivningen.Rekommenderade åtgärder per orsak finns i Googles guide Optimize CLS. En genomgång av CLS ingår i regel i en bredare Teknisk SEO-översyn, tillsammans med LCP och INP.
Orsakerna är desamma oavsett plattform, men var fixen görs skiljer sig. I Webflow är det främst tre saker att kontrollera. För det första: Interactions som flyttar layout. Använd Move och Scale (som renderas som transform) i stället för Size eller Hide/Show på element som har innehåll under sig, eftersom det senare ändrar dokumentflödet. För det andra: accordions, tabs och sliders behöver en reserverad höjd eller en fast min-height, annars hoppar innehållet under när komponenten initieras. För det tredje: fontladdning – undvik att lägga in webbfonter enbart via extern custom code som laddas sent, kontrollera font-display och håll antalet fontvikter nere. Kontrollera även att bilder får ett fast bildförhållande i sina wrappers, särskilt i CMS-drivna listor där bilderna varierar i storlek.
I Next.js sätter komponenten next/image automatiskt width och height (eller kräver fill med en dimensionerad förälder), vilket i praktiken tar bort bild-CLS så länge du inte kringgår komponenten med en vanlig <img>. Den vanligaste fällan är i stället platshållarvyer, så kallade skeletons, i loading.tsx: om platshållaren är lägre än det innehåll som ersätter den uppstår ett skift precis när datan kommer. Bygg platshållaren med samma höjd och samma antal rader som det verkliga innehållet. Se Next.js dokumentation.
I Astro gör astro:assets samma jobb: <Image>-komponenten läser bildens dimensioner vid byggtid och skriver ut width och height för lokala bilder, medan bilder från externa källor kräver att du anger dem själv. Eftersom Astro levererar statisk HTML som standard är risken för sena, klientrenderade skift låg – den återkommer främst i så kallade islands – interaktiva öar som hämtar data efter laddning. Dokumentation hos Astro.
Oavsett plattform: lägg cookie-bannern som ett overlay (position: fixed) så att den inte skjuter in sig i dokumentflödet. Mät sedan om i fält efter varje ändring – labbet ser inte allt. Fler prestandapunkter att gå igenom finns i Checklista för hemsida 2026, och om sidan presterar tekniskt men ändå inte syns är Hemsida rankar inte? 10 orsaker en bra nästa läsning. CLS är i grunden lika mycket en UX-fråga som en SEO-fråga: en sida där inget hoppar känns snabbare och mer pålitlig, även om den laddar lika fort som förut.
Nej. Skift som sker inom 500 millisekunder efter ett klick, ett tryck eller en tangenttryckning flaggas som förväntade och räknas inte in i CLS. En meny som fälls ut eller en sektion som expanderar när användaren klickar är alltså ofarlig. Observera att scroll inte räknas som interaktion – innehåll som hoppar medan användaren scrollar påverkar poängen fullt ut.
Ja, om bannern skjuter in sig i dokumentflödet och trycker ner innehållet under. Lägg bannern som ett overlay med position: fixed så att den ligger ovanpå sidan i stället för att flytta den. Samma sak gäller notiser och kampanjbanners som laddas via en CMP eller ett tagghanteringssystem efter första renderingen.
I GSC hittar du CLS under Core Web Vitals-rapporten, uppdelat på mobil och desktop, med grupper av sidor som klarar eller inte klarar tröskeln 0,1. Datan kommer från CrUX (Chrome User Experience Report), det vill säga verkliga Chrome-besök, och redovisas på den 75:e percentilen. För en enskild sida ger PageSpeed Insights både fältdata från CrUX och labbdata från Lighthouse. Vill du hitta exakt vilket element som skiftar använder du Performance-panelen i Chrome DevTools.
Ofta löser bilddimensioner den största delen, men sällan allt. Webbfonter, cookie-banners, dynamiskt innehåll och animationer som ändrar layout står för resten, och på mobil ger även små skift stor effekt eftersom viewporten är liten. Fixa bilderna först, mät om i fält och gå sedan vidare till nästa orsak i det värsta tidsfönstret.