Sådan forbedrer I CLS: indholdet må ikke hoppe

CLS, Cumulative Layout Shift, er et mål for, hvor meget indholdet på siden flytter sig, uden at den besøgende har bedt om det. Teksten, der hopper ned, da billedet kom. Knappen, der rykker sig, lige idet man skal trykke. Google regner et CLS på højst 0,1 for godt. Over 0,25 er dårligt.

Det er det af de tre Core Web Vitals, der er nemmest at se med det blotte øje, og det, der oftest kan rettes med en enkelt linje. Her er, hvordan I finder jeres tal, hvad der typisk får en WordPress-side til at hoppe, og hvad I gør ved det.

Hvad CLS dækker, og hvad det ikke dækker

Hver gang et synligt element flytter sig fra ét billede til det næste, uden at den besøgende lige har trykket på noget, regner browseren et tal ud: hvor stor en del af skærmen blev påvirket, ganget med hvor langt det flyttede sig. Et ryk, der skubber hele teksten en halv skærm ned, giver et højt tal. En lille bjælke, der vokser 10 pixel, giver et lille. Ryk, der kommer med under et sekunds mellemrum, lægges sammen i et vindue på højst fem sekunder. CLS er det vindue i besøget, der giver det højeste tal.

Tallet, Google bruger, kommer fra rigtige besøg: den 75. percentil over 28 dage, opgjort for mobil og desktop hver for sig. Det tælles ikke kun under indlæsning. Et element, der skubber indholdet, når den besøgende har læst i et minut, tæller med. Grænserne står hos web.dev.

CLS tæller ikke ryk, den besøgende selv har udløst. Åbner man en menu, og indholdet flytter sig inden for et halvt sekund, er det forventet og tæller ikke. Det gælder klik, tryk og tastetryk, men ikke scroll. Et ryk, der sker, mens man scroller, tæller altså med. CLS tæller heller ikke, om noget bevæger sig med en animation, så længe elementet ikke skubber andet indhold. Det er de uventede ryk, der tæller.

Find jeres tal

Start i Search Console under Core Web Vitals. Rapporten viser, hvilke grupper af sider der fejler på CLS på mobil og desktop. Det er feltdata fra rigtige besøg. Se på begge enheder. CLS er det af de tre mål, hvor desktop klarer sig dårligst: I HTTP Archives Web Almanac 2025 havde 81 % af websites et godt CLS på mobil, men kun 72 % på desktop.

Åbn derefter én side fra gruppen i PageSpeed Insights, fx gennem vores hastighedstest. Under laboratorietesten finder I indsigten “Layout shift culprits”, som afløste den gamle diagnose “Avoid large layout shifts”, da Lighthouse 13 kom i oktober 2025. Den viser de konkrete elementer, der flyttede sig, og hvor meget hvert af dem bidrog. Det er listen, I skal arbejde ud fra.

Laboratorietesten ser kun indlæsningen. Et ryk, der sker, når man scroller, eller når cookiebanneret kommer efter tre sekunder, fanger den ikke altid. Åbn derfor også siden på en telefon med en langsom forbindelse, og se, hvad der sker, mens den loader, og de første sekunder efter. Det er oftest nok til at finde synderen.

Det, der typisk er galt på en WordPress-side

Billeder uden højde

Den mest almindelige årsag. HTTP Archive fandt i Web Almanac 2025, at den typiske side har to billeder uden angivet størrelse. Et billede uden width og height fylder nul, til det er hentet, og så skubber det alt under sig ned. WordPress sætter selv de to attributter på billeder, der indsættes gennem mediebiblioteket, men billeder fra temaer, page builders og sliders mangler dem ofte. Kontrollér hero-billedet og de billeder, der står øverst. Med width og height kan browseren regne pladsen ud, før billedet er der. Billedet skalerer stadig med skærmen. Det samme gælder video og indlejrede kort og videoer i en iframe: giv dem en fast højde eller et aspect-ratio.

Bannere og bjælker, der kommer senere

Et cookiebanner, en kampagnebjælke eller en “vi har lukket mellem jul og nytår”-besked, der indsættes øverst, efter at siden ser færdig ud, skubber hele siden ned. Det er ofte det største enkeltbidrag. Læg den slags oven på indholdet med position: fixed, så det ikke skubber noget, eller reservér pladsen fra starten. Det samme gælder annoncer og indlejret indhold, der kommer fra en anden server: giv beholderen en min-height, der svarer til det, der kommer. Lad pladsen stå, også hvis annoncen ikke kommer. web.dev påpeger, at en beholder, der klapper sammen, giver lige så stort et ryk.

Skriften skifter

Browseren viser teksten med en systemfont, til jeres egen webfont er hentet. Er de to fonte forskellige i bredde, bliver linjerne længere eller kortere, når den skifter, og alt under flytter sig. Host fonten selv, og preload den fil, der bruges øverst, så skiftet sker, før den besøgende når at se det. Med size-adjust i @font-face kan systemfonten justeres, så den fylder det samme som jeres. Er fonten ikke vigtig for det første skærmbillede, kan font-display: optional lade browseren springe skiftet over, når forbindelsen er langsom.

Sliders og indhold, der ændrer størrelse

En slider, der først viser alle billederne under hinanden og så folder sig sammen, når scriptet er kørt, giver et stort ryk. Det samme gør faner, harmonikaer og anmeldelsesbokse, der henter indholdet bagefter og vokser. Giv beholderen den højde, den ender med, fra starten. Kan I ikke, så vis en tom boks i samme størrelse, til indholdet er der. Og overvej, om slideren overhovedet skal være der. De fleste besøgende ser kun det første billede.

Animationer, der skubber

Et element, der animeres med top, left, height eller margin, skubber alt omkring sig for hvert billede. Brug transform i stedet. Det flytter elementet på skærmen uden at røre layoutet, og det tæller ikke som et ryk. Det gælder også for det, der glider ind fra siden, når man scroller.

Den klæbende header

En header, der bliver fixed, når man scroller, tager sin højde med sig. Indholdet under hopper op i det hul, den efterlader. Reservér pladsen med en beholder, der beholder headerens højde, eller lad headeren være sticky fra starten, så den aldrig forlader sin plads i layoutet.

Hvad I kan forvente

CLS er det af de tre mål, der oftest går fra dårligt til godt på én dag. De fleste sider, vi ser over 0,25, har ét eller to elementer, der giver næsten hele tallet, og de er typisk et billede uden højde eller en bjælke, der kommer for sent. Er de rettet, ligger siden som regel under 0,1.

Feltdata følger med over de næste 28 dage. Laboratorietesten viser med det samme, om de store ryk er væk. Hold øje med Search Console bagefter, så I fanger de ryk, testen ikke ser.

Tjekliste

1. Find de sidegrupper, der fejler på CLS, i Search Console. Se både mobil og desktop.
2. Kør én side fra hver gruppe gennem PageSpeed Insights, og notér elementerne under “Layout shift culprits”.
3. Giv alle billeder, videoer og iframes øverst på siden en width og height eller et aspect-ratio.
4. Læg bannere og bjælker oven på indholdet, eller reservér pladsen fra starten.
5. Preload den font, der bruges øverst, og justér systemfonten med size-adjust.
6. Giv sliders, faner og indlejret indhold den højde, de ender med.
7. Skift animationer, der bruger top, left eller height, til transform.
8. Åbn siden på en telefon med langsom forbindelse, og se efter ryk, testen ikke fangede.

CLS er det mål, besøgende mærker som irritation snarere end ventetid. Et forkert tryk, fordi knappen flyttede sig, koster mere tillid end et sekunds ekstra indlæsning. Det samme billede, der giver ryk, er ofte også det, der trækker LCP op, så ret det først. Hvor det hører til i den samlede gennemgang, står under teknisk SEO. Vil I vide, hvor jeres sider står, så start med hastighedstesten. Vil I have det gjort for jer, er det præcis det, vi laver under hastighedsoptimering.

Kilder

• web.dev, Cumulative Layout Shift (CLS), web.dev.
• web.dev, Optimize Cumulative Layout Shift, web.dev.
• Chrome for Developers, What’s new in Lighthouse 13, developer.chrome.com.
• HTTP Archive, Performance, Web Almanac 2025, almanac.httparchive.org.