Cumulative Layout Shift (CLS) – hva det måler, grenseverdier og hvordan du fikser layoutskift i Webflow, Next.js og Astro

Definisjon

Cumulative Layout Shift (CLS) er et mål på nettytelse som angir hvor mye innholdet på en side flytter seg uventet mens den laster. Det er ett av Googles tre Core Web Vitals; en verdi på 0,1 eller lavere regnes som bra.

Cumulative Layout Shift (CLS) er målet i Core Web Vitals som fanger opp visuell stabilitet: hvor mye synlig innhold som hopper rundt uten at brukeren har gjort noe. I motsetning til LCP og INP handler CLS ikke om tid, men om hvor mye og hvor langt elementer flytter seg. Et klassisk eksempel er knappen som flytter seg en centimeter akkurat idet du skal klikke, fordi et bilde eller et cookie-banner ble lastet inn over den. Det irriterer brukeren, kan senke konverteringen og påvirker hvordan Google vurderer opplevelsen på siden.

Hva er CLS, og hvordan beregnes poengsummen?

CLS er summen av poengene for alle uventede layoutskift innenfor sidens verste tidsvindu – et begrep som forklares lenger ned. Hvert enkelt skift får en poengsum etter formelen impact fraction × distance fraction, der begge faktorene er andeler av viewporten. Impact fraction er hvor stor del av det synlige vinduet som påvirkes av ustabile elementer – både der de var før skiftet, og der de havnet etter. Distance fraction er den lengste strekningen et ustabilt element flyttet seg, delt på viewportens største side (høyden på mobil).

Et regneeksempel med tenkte verdier: en tekstseksjon som dekker 40 % av viewportens høyde, presses 10 % ned når et bilde lastes inn over den. Impact fraction blir 0,5 (40 % opprinnelig flate pluss 10 % ny flate) og distance fraction 0,1. Poengsummen for skiftet blir 0,5 × 0,1 = 0,05. Et skift av den størrelsen er altså akseptabelt alene, men to slike etter hverandre havner på grensen. Formelen og definisjonene finnes hos web.dev.

Viktig å vite: skift som skjer innen 500 millisekunder etter en brukerinteraksjon (klikk, trykk eller tastetrykk), regnes ikke. At en sammenleggbar seksjon utvides når noen klikker på den, er forventet og påvirker ikke CLS. Scrolling regnes derimot ikke som interaksjon – innhold som hopper mens brukeren scroller, teller fullt ut.

Hvilke CLS-verdier er gode og dårlige?

Google regner en CLS-verdi på 0,1 eller lavere som bra, 0,1–0,25 som «trenger forbedring» og over 0,25 som dårlig. Terskelen vurderes på den 75. persentilen av sidelastingene – tre av fire besøk må altså klare 0,1 for at siden skal regnes som godkjent. Mobil og desktop vurderes hver for seg. Mobilen er nesten alltid den vanskelige delen, fordi smalere skjermer gjør at det samme elementet presser innhold lenger ned i forhold til viewporten. Grenseverdiene er dokumentert hos web.dev.

Feltdata (faktiske besøk) finner du i Core Web Vitals-rapporten i GSC og i PageSpeed Insights. Labdata fra Lighthouse fanger bare opp skift under den første lastingen, så en side kan se ren ut i laben, men likevel få dårlig CLS i felt på grunn av innhold som lastes sent eller flytter seg når brukeren scroller.

Hva er et session window, og hvorfor betyr det noe?

Et session window er en gruppe layoutskift som ligger tett i tid: skift som skjer innen 1 sekund etter forrige skift, grupperes i samme vindu, og et vindu kan maksimalt være 5 sekunder langt. CLS-poengsummen for siden er poengsummen for vinduet med høyest sum – ikke summen av alle skift i løpet av hele besøket. Modellen ble innført i 2021 for at sider som er åpne lenge (for eksempel single page-apper), ikke skulle straffes for det. Bakgrunnen er beskrevet hos web.dev.

Konsekvensen for deg som feilsøker: ett enkelt stort skift kan gi samme poengsum som ti små tett etter hverandre. Spres skiftene ut med mer enn ett sekund imellom, havner de i ulike vinduer, og bare det verste teller. Det betyr at du skal lete etter den verste klyngen av skift, ikke bare det største enkeltelementet.

Hva er de vanligste årsakene til layoutskift?

De fleste CLS-problemer skyldes at nettleseren ikke vet hvor mye plass noe kommer til å ta før det er lastet. De vanligste årsakene er:

• Bilder, videoer og iframes uten dimensjoner. Mangler width og height (eller aspect-ratio i CSS), reserveres det ingen plass, og alt under presses ned når filen kommer.
• Nettfonter. Når en reservefont byttes ut med den riktige, endres linjehøyde og tekstbredde. Effekten forkortes med font-display, preload og size-adjust på reservefonten.
• Dynamisk innhold uten reservert plass. Cookie-bannere fra en CMP, varsler, kampanjebannere og sene annonseflater som skyves inn over eksisterende innhold.
• Animasjoner som endrer layouten. Å animere top, height eller margin tvinger fram en ny layoutberegning, mens transform flytter elementet uten å påvirke omgivelsene.
• Innhold som lastes via JavaScript. Klientrenderte komponenter, innbygginger og widgeter som fyller på siden etter første rendering.

Anbefalte tiltak per årsak finnes i Googles guide Optimize CLS. En gjennomgang av CLS inngår som regel i en bredere teknisk SEO-gjennomgang, sammen med LCP og INP.

Hvordan fikser du CLS i Webflow, Next.js og Astro?

Årsakene er de samme uansett plattform, men hvor løsningen gjøres, er forskjellig. I Webflow er det først og fremst tre ting å kontrollere. For det første: Interactions som flytter layouten. Bruk Move og Scale (som rendres som transform) i stedet for Size eller Hide/Show på elementer som har innhold under seg, fordi det siste endrer dokumentflyten. For det andre: accordions, tabs og sliders trenger en reservert høyde eller en fast min-height, ellers hopper innholdet under når komponenten initialiseres. For det tredje: fontlasting – unngå å legge inn nettfonter bare via ekstern custom code som lastes sent, kontroller font-display og hold antallet fontvekter nede. Kontroller også at bilder får et fast bildeformat i wrapperne sine, særlig i CMS-drevne lister der bildene varierer i størrelse.

I Next.js setter komponenten next/image automatisk width og height (eller krever fill med en forelder som har dimensjoner), noe som i praksis fjerner bilde-CLS så lenge du ikke omgår komponenten med en vanlig <img>. Den vanligste fellen er i stedet plassholdervisninger, såkalte skeletons, i loading.tsx: er plassholderen lavere enn innholdet som erstatter den, oppstår et skift akkurat når dataene kommer. Bygg plassholderen med samme høyde og samme antall linjer som det faktiske innholdet. Se dokumentasjonen til Next.js.

I Astro gjør astro:assets den samme jobben: <Image>-komponenten leser bildets dimensjoner ved byggetid og skriver ut width og height for lokale bilder, mens bilder fra eksterne kilder krever at du oppgir dem selv. Fordi Astro leverer statisk HTML som standard, er risikoen for sene, klientrenderte skift lav – den dukker først og fremst opp igjen i såkalte islands, interaktive øyer som henter data etter lasting. Dokumentasjon hos Astro.

Uansett plattform: legg cookie-banneret som et overlegg (position: fixed), slik at det ikke skyver seg inn i dokumentflyten. Mål deretter på nytt i felt etter hver endring – laben ser ikke alt. Flere ytelsespunkter å gå gjennom finnes i Sjekkliste for nettside 2026, og hvis siden presterer teknisk, men likevel ikke er synlig, er Synlighet på nett: 10 grunner til at nettsiden ikke rangerer god lesning videre. CLS er i bunn og grunn like mye et UX-spørsmål som et SEO-spørsmål: en side der ingenting hopper, føles raskere og mer pålitelig, selv om den laster like fort som før.