Så minskar du CLS: bilder, typsnitt och dynamiskt innehåll
För att minska Cumulative Layout Shift (CLS) behöver du hitta det som ändrar ett elements position efter att det först har visats och göra utrymmet förutsägbart. Vanliga orsaker är sent innehåll, bilder utan mått och typsnitt som ändrar radbrytningen. Att komprimera en bild reserverar inte dess plats.
Börja på sidan där förflyttningen sker. I den här guiden visar en liten demonstrationsbutik orsaken: ett leveransmeddelande dyker upp ovanför produkterna. Innehåll och fördröjning är desamma; bara det reserverade utrymmet ändras.
Vad CLS visar
CLS mäter oväntade visuella förflyttningar. Värdet saknar tidsenhet och tar hänsyn till hur mycket synligt innehåll som flyttar sig och hur långt. Googles gräns för ett bra värde är högst 0,1 vid den 75:e percentilen av sidbesöken. En enda lokal mätning visar inte att hela webbplatsen klarar Core Web Vitals.
Den nuvarande metriken använder det största sessionsfönstret av oväntade förskjutningar, i stället för att summera alla förskjutningar under ett obegränsat besök. Nylig användarinmatning kan också påverka vad som räknas. Reglerna beskrivs i Googles definition av CLS.
Ett laddningstest är användbart, men besökare kan möta förflyttningar senare: när de skrollar till inbäddat innehåll, navigerar till en annan vy eller får personligt innehåll. Ett lågt CLS i ett inledande Lighthouse-test bevisar inte att alla senare tillstånd är stabila.
Ett leveransmeddelande skjuter ner katalogen
FIELD / GOODS är en avsiktligt förenklad demonstrationsbutik, inte en kundwebbplats. Ett meddelande infogas 1 500 ms efter att dokumentet är redo. Den första versionen har en tom plats utan reserverad höjd. När meddelandet kommer flyttas produktrubriken och korten nedåt.
Lokal Chrome-bild från den 22 oktober 2026. Vid 1280 × 900 CSS-pixlar flyttas rubriken från 406 till 498 pixlar. Sidans observatör för Layout Instability API rapporterar CLS 0,0289.
Den andra versionen reserverar meddelandets höjd innan texten kommer. Produkterna börjar på sin slutliga plats. Båda bilderna visar samma slutliga innehåll; skillnaden är vad som hände medan det visades.
Samma webbläsare, visningsyta, innehåll och fördröjning. Rubriken ligger kvar vid 498 pixlar; observerat CLS för demonstrationen är 0,0000.
| Visningsyta | Utan reserverat utrymme | Med reserverat utrymme | Rubrikens rörelse |
|---|---|---|---|
| 1280 × 900 | 0,0289 | 0,0000 | 92 px → 0 px |
| 390 × 844 | 0,0451 | 0,0000 | 116 px → 0 px |
Detta är enskilda lokala observationer i Chrome 155, utan nätverksbegränsning, insamlade den 22 oktober 2026. De är inte Lighthouse-rapporter, percentiler för fältdata eller en prognos för en annan webbplats. Även den rörliga versionen ligger under 0,1 i det lilla experimentet: ett synligt hopp och sidans samlade klassificering är olika frågor.
Öppna demonstrationen utan reserverat utrymme och jämför med den reserverade versionen. Behåll samma visningsyta, ladda om och vänta utan att skrolla eller interagera. Observatören utesluter förskjutningar efter nylig inmatning och behåller det största sessionsfönstret. Resultatet kan ändras med visningsytan och webbläsarens beteende.
Hitta orsaken, inte bara elementet som flyttas
Öppna Chrome DevTools → Performance och spela in en omladdning. Återskapa det verkliga problemet: vänta på meddelandet, skrolla till videon eller navigera till den berörda vyn. Granska layoutförskjutningarna och de omgivande skärmbilderna. Dokumentationen för Performance-panelen beskriver inspelning och analys.
Det markerade produktkortet kan vara det som påverkas av en annan förändring. Titta ovanför det: kom ett meddelande, fick en bild höjd eller bröts en rubrik på en extra rad? Att ändra kortets marginal skulle bara dölja symtomet i just det tillståndet.
Upprepa med en smal visningsyta och en första laddning. Anteckna tillståndet för kakbannern, inloggningen och sidans adress. Om ett samtyckesverktyg är inblandat ska du återskapa dess vanliga beteende i stället för att stänga av det enbart under testet.
Gör utrymmet förutsägbart
Reservera plats för det sena blocket
I demonstrationen är den enda layoutändringen en minsta höjd på den befintliga platsen:
.notice-slot {
min-height: 92px;
}
@media (max-width: 600px) {
.notice-slot {
min-height: 116px;
}
}
Värdena gäller det här exemplet. Mät ditt innehåll vid verkliga bredder och på olika språk: översättningar och större textinställningar kan behöva mer plats. En laddningsplatshållare bör matcha det slutliga blockets geometri. Att ta bort reserverat utrymme senare kan också flytta sidan, så kontrollera det tillståndet med.
Ge bilder proportioner innan de laddas
Ange källbildens inneboende mått och låt CSS skala bilden proportionellt:
<img
src="/images/daypack.webp"
alt="Grön ryggsäck med en framficka"
width="800"
height="600"
style="width: 100%; height: auto;"
/>
I Next.js anger du lämpliga mått för Image, eller ger föräldern till en bild med fill en bestämd storlek eller ett bildförhållande. Håll responsiva sizes korrekta för bildleveransen. Det är närliggande men skilda uppgifter: att reservera geometrin och välja filen som laddas ner. Se Image-referensen.
Kontrollera bytet av typsnitt
Titta på rubriken medan webbtypsnittet laddas. Om reservtypsnittet ryms på två rader och det slutliga behöver tre kan allt nedanför flyttas. Anpassa reservtypsnittets mått och kontrollera den faktiska familjen, vikterna och språkuppsättningarna. font-display: swap låter text visas tidigare men garanterar inte stabil radbrytning.
För Next.js erbjuder next/font lokal leverans av typsnitt och alternativ för att justera reservtypsnitt. Kontrollera resultatet med en typsnittsbegäran utan cache och din riktiga text, särskilt på olika språk.
Ha startinnehållet med i den första renderingen
En katalog som börjar tom och fylls från en klienteffekt kan ändra hela sidans höjd. Om datan redan finns på servern kan du rendera de första produkterna där och skicka samma starttillstånd till den interaktiva komponenten. Om datan måste komma senare bör du reservera en realistisk laddningslayout.
En Client Component betyder inte automatiskt att serverrenderad HTML saknas. Next.js kan förrendera Client Components vid den första sidladdningen. Undersök när datan blir tillgänglig och om den första HTML-koden innehåller den. Guiden för Server och Client Components förklarar gränsen.
Kontrollera sidan besökarna faktiskt får
Upprepa samma scenario före och efter ändringen. Behåll adress, visningsyta, webbläsare och innehållstillstånd. Granska spåret tillsammans med siffran: bekräfta att rätt block har slutat skjuta undan innehåll och att meddelandet, bilderna och kontrollerna fortfarande fungerar.
Kontrollera den första laddningen och de senare interaktioner som orsakade rörelsen. Granska tillgängliga fältdata separat; de representerar verkliga besök över en insamlingsperiod och blir inte omedelbart ett nytt lokalt resultat efter en driftsättning.
Använd ett gratis hastighetstest i NEKTIQA för Lighthouse-diagnostik och prestandahistoriken för att följa jämförbara labbtester efter senare ändringar. Om ett resultat skiljer sig mellan verktyg kan du läsa PageSpeed Insights jämfört med Lighthouse. För bildleverans och inbäddade widgetar finns tre praktiska förbättringar av webbprestanda.
