CLS

CLS (Cumulative Layout Shift) är ett mått på hur mycket innehållet på en sida hoppar och flyttar sig medan den laddar. Du ska trycka på en knapp, en annons laddar in ovanför, och plötsligt klickar du på fel sak. Den lilla irritationen är precis vad Cumulative Layout Shift försöker fånga i en enda siffra.

Av redaktionen på seoninja.se.

CLS är ett av tre Core Web Vitals, de mätvärden Google använder för att bedöma teknisk sidupplevelse. Till skillnad från laddningstid handlar CLS inte om hur snabbt något syns, utan om hur stabilt det ligger kvar. En sida kan ladda blixtsnabbt och ändå kännas skakig när text, bilder och knappar rör på sig efter att läsningen har börjat.

Vad CLS mäter

CLS står för Cumulative Layout Shift, på svenska ungefär ackumulerad layoutförskjutning. Måttet summerar alla oväntade hopp som sker medan sidan laddar och medan den används, och väger samman dem till ett enda tal. Ju högre värde, desto mer rör sig innehållet i sidans DOM medan besökaren tittar på det.

Poängen är att fånga upplevelsen ur besökarens perspektiv. En liten förskjutning som ingen märker spelar mindre roll. Ett stort hopp precis vid en klickning är däremot irriterande och leder lätt till felklick, så beräkningen väger in både hur stor del av skärmen som påverkas och hur långt innehållet flyttar sig.

Bara oväntade förflyttningar räknas. Fäller du själv ut mer innehåll är det förväntat, och Google lämnar ett fönster på 500 millisekunder efter varje interaktion där sådana förändringar inte straffas. Det är hoppen ingen bad om som mäts.

• CLS är kumulativt: många små hopp kan summera till ett högt tal.
• Endast oväntade förskjutningar räknas, inte de som en klickning utlöser.
• Måttet är enhetslöst; det är ett förhållandetal och inte sekunder.
• Både mobil och dator mäts, och resultaten kan skilja sig rejält åt.

Så räknas CLS ut

Värdet bygger på en enkel princip: varje enskild layoutförskjutning får en poäng som är produkten av två delar, impact fraction och distance fraction. Poängen läggs ihop inom ett så kallat sessionsfönster, en serie hopp med mindre än 1 sekund mellan sig och högst 5 sekunder totalt. Det tyngsta fönstret blir sidans CLS. Du behöver inte räkna för hand, men det hjälper att förstå de två delarna.

• Impact fraction: hur stor del av skärmen som ett hopp påverkar.
• Distance fraction: hur långt det instabila innehållet flyttar sig.

Impact fraction

Impact fraction, eller påverkansandel, beskriver hur stor del av det synliga fönstret som berörs av ett hopp. Flyttar sig ett block som täcker halva skärmen blir påverkansandelen stor; rör sig en liten ikon i hörnet blir den liten. Ju mer av ytan som skiftar, desto tyngre väger förskjutningen.

Distance fraction

Distance fraction, avståndsandel, mäter hur långt det instabila innehållet flyttade sig i förhållande till fönstrets höjd eller bredd. Ett element som glider ner tio pixlar ger ett litet avstånd, medan ett som knuffas ner en halv skärm ger ett stort. Formeln multiplicerar de två andelarna, så ett stort block som flyttar sig långt ger den allra högsta poängen.

Ett enda fult hopp kan förstöra ett annars perfekt CLS-värde. Därför lönar det sig att jaga de enskilda syndarna, inte bara stirra på totalsiffran.

CLS-värden som räknas som bra

Google har satt tydliga gränser för vad som är godkänt. Gränserna bygger på hur riktiga besökare upplever sidan och mäts på den 75:e percentilen, alltså den upplevelse som minst tre av fyra användare får eller bättre.

Siffrorna ser små ut, men skillnaden märks. En sida på 0,05 känns lugn och pålitlig, medan en på 0,3 kan få besökaren att tappa tråden eller klicka fel. Mobilen är ofta känsligare eftersom skärmen är smal och bilderna tar upp mer av ytan.

• Sikta på under 0,1 på både mobil och dator.
• Testa din viktigaste sida först, till exempel startsidan eller en landningssida.
• Jämför fältdata och labbdata, eftersom de kan skilja sig åt.
• Kom ihåg att ett medelvärde kan dölja enstaka sidor med långt sämre värden.

CLS och de andra Core Web Vitals

CLS jobbar inte ensamt. Tillsammans med LCP och INP beskriver de tre kärnvärdena olika sidor av upplevelsen: laddning, respons och stabilitet. Att bara optimera ett av dem ger en halv bild.

LCP och CLS

LCP, Largest Contentful Paint, mäter hur snabbt det största synliga elementet laddar, ofta en hjältebild eller en rubrik. LCP och CLS krockar ibland: laddas en stor bild sent för att förbättra hastigheten, men utan reserverad plats, förbättras LCP samtidigt som CLS förstörs. De behöver därför lösas i par, inte var för sig.

Från FID till INP

Tidigare ingick FID, First Input Delay, som mätte just den input delay som uppstod vid det första klicket. I mars 2024 ersattes FID av INP, Interaction to Next Paint, som mäter responsen genom hela besöket. Andra mått som FCP, First Contentful Paint, och TBT, Total Blocking Time, dyker upp i verktygen, men de tre kärnvärdena är LCP, INP och CLS.

• LCP: laddning, hur snabbt huvudinnehållet syns.
• INP: respons, hur snabbt sidan svarar på klick och tryck (ersatte FID).
• FCP och TBT: stödmått som hjälper vid felsökning men inte räknas som kärnvärden.
• CLS: stabilitet, hur lite innehållet hoppar.

Vanliga orsaker till layoutförskjutning

Nästan all CLS går att spåra till att något laddar in och tar plats efter att sidan redan börjat visas. Webbläsaren visste inte att utrymmet behövdes, så den knuffar undan det som redan finns. Här är de vanligaste orsakerna, i grov ordning efter hur ofta de ställer till det.

Bilder och video utan mått

Saknar en bild angiven bredd och höjd vet webbläsaren inte hur mycket plats den behöver. Texten under läggs ut som om bilden inte fanns, och när den väl laddar knuffas allt neråt. Detsamma gäller video, kartor och andra element vars höjd bestäms sent.

• Ange width och height på img-taggar, eller använd CSS med rätt aspect-ratio.
• Reservera plats även för lazy-loadade bilder längre ner på sidan.
• Ge inbäddade kartor och videospelare en fast höjd i CSS.

Annonser, inbäddningar och iframes

Annonser är en klassisk källa till CLS eftersom de laddas via externa skript och dyker upp med varierande storlek. Detsamma gäller inbäddat innehåll från sociala medier, kommentarsfält och widgets. De skjuts in i flödet och trycker ner allt annat, ibland flera gånger under samma sidladdning.

• Reservera en fast yta för varje annonsplats, även när den står tom.
• Undvik att placera annonser mitt i löptext där de knuffar stycken.
• Ladda tunga integrationer i efterhand, men bara i utrymme som redan avsatts.

Varför hoppar sidan när typsnittet laddar?

Webbtypsnitt är en underskattad bov. När sidan laddar visas texten först med ett reservtypsnitt, och när det riktiga typsnittet är klart byts det ut. Har de två typsnitten olika bredd och höjd flyttar sig texten, och allt under den med.

FOIT, FOUT och @font-face

Det finns två beteenden att känna till. FOIT, Flash of Invisible Text, betyder att texten hålls osynlig tills typsnittet laddat, vilket kan ge ett sent hopp. FOUT, Flash of Unstyled Text, visar reservtypsnittet direkt och byter sedan, vilket ofta känns bättre. Beteendet styrs med font-display i din @font-face-regel.

• Använd font-display: swap eller optional för att undvika osynlig text.
• Förhämta huvudtypsnittet så att det laddar tidigt.
• Välj ett reservtypsnitt med liknande mått för att minska hoppet vid bytet.

Så mäter du CLS

Du behöver inga betalverktyg för att komma igång. Det finns gratis alternativ som täcker både snabb felsökning och långsiktig uppföljning. Skillnaden mellan dem handlar mest om var datan kommer ifrån.

Fältdata och labbdata

Labbdata samlas in i en kontrollerad miljö, där verktyget laddar sidan under fasta förhållanden. Det är perfekt för att felsöka en enskild sida och testa om en ändring hjälpte. Fältdata kommer i stället från riktiga Chrome-användare ute i världen och speglar vad dina faktiska besökare upplever, med alla olika enheter och uppkopplingar.

• Labbdata: kontrollerad miljö, bra för att felsöka och testa fixar direkt.
• Fältdata: riktiga användare i Chrome, bra för att bedöma sajten på riktigt.
• Fältdata kan släpa efter i veckor, medan labbdata visar läget just nu.
• För en rättvis bild bör båda vägas mot varandra.

Verktyg du kan använda

• PageSpeed Insights: ger både fält- och labbdata för en enskild URL, gratis i webbläsaren.
• Lighthouse: inbyggt i Chrome och bra för snabba tester medan du utvecklar.
• Search Console: samlar Core Web Vitals-rapporten för hela sajten över tid.
• Chrome DevTools: visar exakt vilka element som hoppar och när.
• Web Vitals-tillägget: mäter värdena live medan du surfar på din egen sida.

Så här hittar du bovarna i Chrome DevTools:

1. Öppna Performance-panelen och spela in en sidladdning.
2. Leta efter markeringarna Layout Shift på tidslinjen.
3. Klicka på ett hopp för att se vilket element som flyttade sig.
4. Åtgärda elementet och spela in på nytt för att bekräfta.

Så läser du CLS i Search Console

Under rapporten för Core Web Vitals i Search Console grupperas sidorna i bra, behöver förbättras och dålig, uppdelat på mobil och dator. Rapporten bygger på fältdata och kan släpa efter några veckor, så ha tålamod efter en fix.

1. Öppna Core Web Vitals-rapporten och välj mobil eller dator.
2. Klicka in på en grupp för att se exempel på URL:er med samma problem.
3. Åtgärda ett representativt problem och validera gruppen på nytt.
4. Följ värdet över tid för att se att fältdatan verkligen förbättrats.

Så åtgärdar du CLS steg för steg

Den goda nyheten är att CLS ofta är det enklaste Core Web Vital att förbättra, eftersom orsakerna är konkreta och lösningarna tydliga. Jaga de största hoppen först, i den här prioriteringen:

• Störst påverkansyta först, alltså det som täcker mest av skärmen.
• Innehåll ovanför mitten, det besökaren ser innan hen scrollar.
• Element nära knappar och länkar, där ett felklick gör mest skada.

Följ sedan ordningen nedan och mät efter varje steg.

1. Kör din viktigaste sida genom PageSpeed Insights och notera CLS-värdet.
2. Öppna Chrome DevTools och spela in en laddning för att se vilka element som hoppar.
3. Sätt bredd och höjd på alla bilder och videor, eller reservera plats med CSS.
4. Ge varje annonsplats och inbäddning en fast yta, även när den står tom.
5. Ställ in font-display och förhämta huvudtypsnittet för att minska typsnittshoppet.
6. Flytta banners och notiser så att de tar plats som redan avsatts, inte knuffar innehåll.
7. Byt animationer som använder top eller left mot transform, som inte påverkar layouten.
8. Ladda om sidan och kontrollera i DevTools att hoppen är borta.
9. Mät igen i PageSpeed Insights och jämför med utgångsvärdet.
10. Följ upp i Search Console efter några veckor för att bekräfta att fältdatan förbättrats.

CLS i vanliga plattformar

Hur du åtgärdar CLS beror lite på vad sidan är byggd med. Principen är alltid densamma, reservera plats innan innehållet laddar, men var problemen sitter skiljer sig åt.

CLS i WordPress

I WordPress kommer hoppen ofta från teman och plugins snarare än från text du skrivit själv. Bildgallerier, popup-rutor för cookies och nyhetsbrev samt tunga sidbyggare injicerar gärna innehåll sent.

• Välj ett tema som anger bilddimensioner automatiskt.
• Var sparsam med plugins som lägger in banners och popups.
• Testa cookie-rutan, den ligger ofta överst och trycker ner allt under.
• Rensa bland gamla integrationer som laddar tunga skript.

Ett tips som ofta glöms bort: när en besökare trycker på bakåtknappen kan Chrome återställa sidan direkt från sin back/forward-cache i stället för att bygga om den. Då dyker sidan upp stabil och snabb, utan de hopp en helt ny laddning kan ge. Undvik gammal kod som blockerar den cachen, till exempel vissa unload-hanterare, så blir återbesöken lugnare.

CLS i SPA:er och JavaScript-tunga sajter

I en SPA, en single page application, byggs stora delar av sidan med JavaScript efter att den första koden laddat. Det gör det extra lätt att skapa hopp, eftersom innehåll ofta injiceras i flera omgångar via API:er. Reservera skelett eller platshållare med rätt storlek medan datan hämtas, och undvik att flytta redan visat innehåll när det nya kommer in.

• Visa en platshållare i rätt storlek medan innehåll laddas.
• Lägg nytt innehåll under det befintliga, inte ovanför.
• Undvik att räkna om layouten varje gång ett API svarar.

Och en sista sak värd att minnas: CLS är en signal bland många i Googles bedömning av sidupplevelse, inte en magisk rankingknapp. Men en stabil sida håller kvar besökarna, minskar felklicken och gör hela upplevelsen bättre, och det är värt att fixa oavsett exakt vad det gör för just placeringen.