Kæmper du med problemer med Cumulative Layout Shift på dit websted? Eller er du ikke sikker på, hvad Cumulative Layout Shift overhovedet betyder?
Cumulative Layout Shift, eller CLS, er en måleenhed, der er en del af Googles Core Web Vitals-initiativ.
Kort fortalt måler det, hvor meget af en websides indhold der “uventet” skifter. En høj CLS-score kan indikere en dårlig brugeroplevelse og kan også være en hæmsko for dit websteds SEO.
I dette indlæg lærer du alt, hvad du behøver at vide om Cumulative Layout Shift, og hvordan det påvirker WordPress-websteder (og internettet generelt).
Hvad er Cumulative Layout Shift (CLS)? Forklaring af Cumulative Layout Shift-betydningen
Cumulative Layout Shift er et mål for, hvor meget en side på dit websted uventet flytter sig rundt i løbet af en brugers besøg, som målt af Layout Instability API, et standardiseret API til test af ydeevne.
Cumulative Layout Shift (CLS) er et af de tre målepunkter i Googles Core Web Vitals-initiativ sammen med Largest Contentful Paint (LCP) og First Input Delay (FID).
For at forstå betydningen af Cumulative Layout Shift er det vigtigt at diskutere layoutforskydning i almindelighed.
Et layoutskifte opstår, når indholdet på dit websted “flytter” eller “forskydes” uventet.
Eller i tekniske termer er det, når et element, der er synligt i visningsområdet, ændrer sin startposition mellem to frames.
Et almindeligt eksempel er, at du er i gang med at læse en tekstblok … men så dukker der pludselig en annonce op, der indlæses sent, og som skubber tekstindholdet nedad på siden.
Her er et andet eksempelbillede fra Google, der viser, hvordan dette kan ske:
Du er næsten helt sikkert stødt på layoutforskydninger, når du surfer rundt på nettet, selv om du ikke kender dem under det navn.
Et enkelt besøg kan have flere separate layoutskift-hændelser. Derfor har målingerne for kumulativt layoutskift til formål at indfange hele billedet ved at måle det samlede antal uventede layoutskift på en side*.
*Den nøjagtige måling er lidt mere teknisk efter nogle ændringer fra Googles side, men det er stadig den grundlæggende idé. Hvis du er interesseret i de små detaljer, kan du læs om det her.
Hvorfor er Cumulative Layout Shift dårligt?
Hovedårsagen til, at Cumulative Layout Shift er dårligt, er, at det skaber en dårlig brugeroplevelse på dit websted.
I bedste fald er det let irriterende for dine besøgende. I værste fald kan det få besøgende til at udføre handlinger, som de ikke ønsker at udføre.
Forestil dig for eksempel, at en bruger ønsker at klikke på “Annuller”, men ved et uheld klikker på “Bekræft”, fordi et layoutskifte har flyttet knappernes position lige mens personen klikker.
Ud over at påvirke dine menneskelige besøgendes oplevelse kan dårlige score for kumulativ layoutforskydning også være en hæmsko for dit websteds placering i søgemaskinerne.
Fra og med Googles opdatering af Page Experience (som blev rullet ud i august 2021) bruger Google Core Web Vitals som en af sine SEO-rangeringsfaktorer. Da Cumulative Layout Shift er en del af Core Web Vitals, betyder det, at det kan påvirke dit websteds søgepræstationer.
Hvis du løser eventuelle problemer med Cumulative Layout Shift på dit websted, vil det grundlæggende set gøre det bedre for både menneskelige besøgende og søgemaskiner.
Så – hvad kan være årsag til Cumulative Layout Shift? Lad os dække det næste…
Hvad er årsagen til Cumulative Layout Shift?
Her er en hurtig oversigt over de mest almindelige årsager til layoutforskydning:
- Du indstiller ikke dimensioner for billeder, iframes, videoer eller andre indlejringer.
- Problemer med indlæsning af brugerdefinerede skrifttyper, hvilket kan medføre, at tekst bliver usynlig eller ændrer størrelse, når brugerdefinerede skrifttyper indlæses.
- Servering af responsive annoncer (f.eks. AdSense) med forskellige størrelser (og ikke reservation af plads til disse annoncer).
- Dynamisk indsprøjtning af indhold med plugins (meddelelser om cookie samtykke, formularer til leadgenerering osv.).
- Brug af animationer uden CSS Transform-egenskaben.
Vi vil gå meget mere i dybden med disse problemer senere i dette indlæg, når vi viser dig, hvordan du løser hvert enkelt almindeligt problem.
Sådan måler du Cumulative Layout Shift: Bedste testværktøjer
Der findes en række værktøjer, som du kan bruge til at teste dit websteds Cumulative Layout Shift-score.
Cumulative Layout Shift er en del af Lighthouse-audit, så ethvert hastighedstestværktøj, der bruger Lighthouse som en del af sin audit, vil indeholde CLS-data – dette omfatter PageSpeed Insights, GTmetrix, Chrome Developer Tools og mange andre populære testværktøjer.
Her er nogle af de bedste værktøjer til test af Cumulative Layout Shift, der skiller sig ud for deres anvendelighed…
PageSpeed Insights
PageSpeed Insights er et af de mest nyttige værktøjer til at vurdere tilstanden af dit websteds layoutskifte, fordi det giver dig to datakilder:
- Feltdata – reelle brugerdata fra Chrome UX-rapporten (forudsat at dit websted har nok trafik til at blive inkluderet i rapporten). Dette giver dig mulighed for at se de faktiske data for Cumulative Layout Shift for dine rigtige menneskelige besøgende. Det er også de data, som Google bruger som et ranking-signal.
- Laboratoriedata – simulerede testdata, der indsamles af Lighthouse (som PageSpeed Insights bruger til at generere sine rapporter om ydelsesanalyser).
Du kan også se data for både desktop og mobil ved at skifte mellem fanerne.
Bemærk – laboratoriedataene kan kun måle layoutforskydninger, der opstår under indlæsningen af siden, så dine resultater for rigtige brugere kan være lidt højere, hvis du har layoutforskydninger, der opstår efter indlæsningen af siden.
Chrome-udviklerværktøjer
Chrome Developer Tools tilbyder nogle nyttige ressourcer til både måling af CLS og fejlfinding af de enkelte layoutforskydninger, der forekommer på dit websted.
For det første kan du køre en Lighthouse-audit for at se dit sites CLS-score. Sådan gør du:
- Åbn Chrome Developer Tools.
- Gå til fanen Lighthouse.
- Konfigurer din test.
- Klik på knappen Analyser sideindlæsning for at køre testen.
Efter en kort ventetid bør du se den almindelige Lighthouse-auditgrænseflade (som ligner PageSpeed Insights meget).
I Chrome Developer Tools kan du dog også grave dybere i CLS med dens Rendering-analyse. Dette giver dig mulighed for at fremhæve individuelle områder med layoutskift på dit websted, hvilket hjælper dig med at fejlfinde dem.
Sådan gør du:
- Klik på ikonet med de “tre prikker” i øverste højre hjørne af Chrome Developer Tools-grænsefladen.
- Vælg Flere værktøjer → Rendering, hvilket skulle åbne en ny grænseflade nederst.
- Markér afkrydsningsfeltet for Layout Shift Regions.
Genindlæs nu den side, du vil teste, og Chrome bør fremhæve alle områder med layoutforskydninger ved hjælp af en blå boks. Disse fremhævninger vises på den faktiske side, mens indholdet indlæses, og forsvinder, når skiftet er afsluttet.
Hvis fremhævelserne vises for hurtigt til, at du kan følge med, kan du sænke hastigheden på dit websted og se det blive indlæst ramme for ramme ved hjælp af fanen Ydeevne.
Google Search Console
Mens Google Search Console ikke giver dig mulighed for at køre laboratorietests for at bestemme Cumulative Layout Shift, giver den dig en nem måde at se problemer med Cumulative Layout Shift på dit websted, som målt ved hjælp af Chrome UX-rapporten.
Fordelen ved at bruge Google Search Console frem for andre værktøjer er, at du hurtigt kan se problemer på hele dit websted i stedet for at teste side for side.
Her kan du se, hvordan du får vist potentielle problemer på dit websted:
- Gå til Google Search Console. Hvis du ikke har verificeret dit websted endnu, kan du følge vores vejledning om, hvordan du verificerer Google Search Console.
- Åbn rapporten Core Web Vitals under Experience (oplevelse).
- Klik på Åbn rapport ud for Mobil eller Desktop, afhængigt af hvad du vil analysere.
Hvis det er relevant, vil Google fremhæve URL’er med problematiske scoringer for Cumulative Layout Shift.
Bemærk – du vil kun se data her, hvis dit websted har tilstrækkelig månedlig trafik til at blive inkluderet i Chrome UX-rapporten.
Layout Shift GIF-generator
Som navnet antyder, genererer Layout Shift GIF Generator en GIF af layoutforskydningerne på dit websted, så du kan se præcis, hvilket indhold der forårsager problemer. Det giver dig også din score, selv om det ikke er værktøjets hovedfokus.
Det eneste, du gør, er at tilføje den URL, du vil teste, og vælge mellem mobil eller desktop. Derefter vil det generere en GIF-fil af dit websted med grønne fremhævninger, der viser de nøjagtige elementer, der skifter.
Ved at se, hvilke elementer der skifter rundt og bidrager til din Cumulative Layout Shift-score, kan du vide præcis, hvor du skal fokusere, når det gælder om at forbedre dit websteds score.
Hvad er en god Cumulative Layout Shift?
Ifølge Googles Core Web Vitals-initiativ er en god score for Cumulative Layout Shift 0,1 eller mindre.
Hvis din score for Cumulative Layout Shift ligger mellem 0,1 og 0,25, definerer Google det som “behov for forbedring”.
Og hvis din Cumulative Layout Shift-score er over 0,25, definerer Google den som “dårlig”.
Her er en grafik fra Googles Core Web Vitals-websted, der viser disse scorer visuelt:
Sådan retter du Cumulative Layout Shift i WordPress (eller andre platforme)
Nu hvor du forstår, hvad der sker med Cumulative Layout Shift, er det tid til at gå over til nogle praktiske tips om, hvordan du kan rette Cumulative Layout Shift i WordPress.
Selvom disse tips kommer fra en WordPress-vinkel, er de alle universelle, og du kan anvende dem på andre værktøjer til websideopbygning.
Angiv altid dimensioner for billeder
En af de mest almindelige årsager til layoutforskydning er billeder med sen indlæsning, der flytter indholdet rundt, især hvis du bruger taktikker som lazy loading.
For at undgå dette kan du angive et billedes dimensioner i koden, når du indlejrer det. På den måde vil den besøgendes browser reservere denne plads, selv om billedet ikke er blevet indlæst endnu, hvilket betyder, at billedet ikke behøver at flytte indhold rundt.
Hvis du indlejrer billeder via WordPress-editoren (enten Gutenberg-blokeditoren eller den klassiske TinyMCE-editor), er der ingen grund til manuelt at angive billeddimensionerne, fordi WordPress gør det automatisk for dig.
Det samme gælder for populære side builder-plugins som Elementor, Divi, Beaver Builder osv.
Der kan dog opstå problemer, hvis du manuelt indlejrer billeder ved hjælp af din egen kode, hvilket kan ske, hvis du tilføjer indhold til et plugin, redigerer dit child theme’s skabelonfiler og så videre.
HTML-koden for en grundlæggende billedindlejring ser således ud:
<img src="https://kinsta.com/example-image.jpg" alt="An example image">
For at angive dimensionerne kan du tilføje højde– og breddeparametre. Her er et eksempel på, hvordan det kan se ud for et billede på 600x300px:
<img src="https://kinsta.com/example-image.jpg" alt="An example image" width="600" height="300">
Mange WordPress performance plugins indeholder også funktioner til at automatisere dette, som f.eks. funktionerne Tilføj manglende billeddimensioner i WP Rocket eller Perfmatters.
Angiv altid dimensioner for videoer, iframes og andre indlejringer
Ligesom med billeder skal du også angive dimensioner, når du tilføjer videoer, iframes eller andre indlejringer.
De fleste hjemmesiders indlejringsværktøjer bør automatisk angive dimensioner for indlejringen.
Hvis du f.eks. kigger på YouTube’s indlejringskode, kan du se, at den indeholder dimensioner:
Det samme gælder for mange andre tjenester.
Men hvis din indlejringskode ikke angiver højde og bredde, kan du manuelt tilføje disse dimensioner til indlejringskoden.
Fastsæt og optimering af indlæsning af skrifttyper
Problemer med indlæsning og optimering af skrifttyper kan være en anden almindelig kilde til layoutforskydninger via to potentielle problemer:
- Flash af usynlig tekst (FOIT) – siden indlæses i første omgang uden at der vises noget tekstindhold overhovedet. Når den brugerdefinerede skrifttype indlæses, vises teksten pludselig (hvilket kan medføre, at eksisterende indhold forskydes).
- Flash af ustilet tekst (FOUT) – tekstindholdet indlæses med en systemskrifttype (uden stil). Når den tilpassede skrifttype indlæses, ændres teksten til den tilpassede skrifttype, hvilket kan medføre, at indholdet forskydes, fordi tekststørrelsen og -afstanden kan være anderledes.
For at undgå disse problemer skal du optimere den måde, du indlæser skrifttyper på dit websted (hvilket også kan have nogle fordele for webstedets ydeevne).
Host skrifttyper lokalt og indlæs skrifttyper på forhånd
Ved at hoste skrifttyper lokalt og bruge preloading fortæller du de besøgendes browsere, at de skal prioritere indlæsning af brugerdefinerede skrifttypefiler højere.
Ved at indlæse skrifttypefiler før andre ressourcer kan du sikre, at skrifttypefilerne allerede er indlæst, når browseren begynder at gengive dit indhold, hvilket kan forhindre problemer med FOUT og FOIT.
Hvis du vil vide, hvordan du hoster skrifttyper lokalt i WordPress, kan du læse vores komplette guide til at hoste skrifttyper lokalt i WordPress.
Derfra kan du konfigurere forindlæsning af skrifttyper manuelt eller ved hjælp af et plugin. De fleste ydelsesplugins indeholder muligheder for at forhåndsindlæse skrifttyper, herunder WP Rocket, Perfmatters, Autoptimize og andre.
Hvis du bruger Google Fonts, kan du også bruge det gratis OMGF-plugin til at hoste skrifttyperne lokalt og forhåndsindlæse dem.
Du kan også manuelt forudindlæse skrifttyper ved at tilføje koden til <head>-afsnittet på dit websted.
Her er et eksempel på koden – sørg for at erstatte den med det faktiske navn/placering af den skrifttypefil, du ønsker at forudindlæse:
<link rel="preload" href="https://kinsta.com/fonts/roboto.woff2" as="font/woff2" crossorigin>
Du kan tilføje det direkte ved hjælp af et WordPress-child theme eller injicere det med wp_head hook og et plugin som Code Snippets.
Indstil Font-Display til Optional eller Swap
CSS Font-Display-egenskaben giver dig mulighed for at styre renderingsadfærden for skrifttyperne på dit websted og undgå FOIT.
I det væsentlige giver den dig mulighed for at bruge en fallback-skrifttype i situationer, hvor din brugerdefinerede skrifttype ikke er indlæst endnu.
Der er to hovedmuligheder, som du kan bruge til at løse CLS:
- Swap – bruger en fallback-skrifttype, mens den brugerdefinerede skrifttype indlæses, og ændrer den derefter til din brugerdefinerede skrifttype, når skrifttypen er indlæst.
- Valgfri – lader browseren bestemme, om den bruger en brugerdefineret skrifttype skal bruges eller ej, baseret på den besøgendes forbindelseshastighed.
Med Swap skifter browseren altid til den tilpassede skrifttype, når den er indlæst.
Swap løser FOIT fuldstændigt, men det kan føre til FOUT. For at minimere dette bør du sørge for, at fallback-skrifttypen bruger samme afstand som den brugerdefinerede skrifttype (i det mindste så meget som muligt). På den måde vil det ikke føre til layoutforskydninger, selv hvis skrifttypen ændres, fordi afstanden vil være den samme.
Med Optional giver browseren den tilpassede skrifttype 100 ms til at indlæse. Men hvis den tilpassede skrifttype ikke er tilgængelig på det tidspunkt, vil browseren bare holde sig til fallback-skrifttypen og aldrig ændre den til den tilpassede skrifttype for det pågældende sidevisit(den vil bruge den tilpassede skrifttype for efterfølgende sidevisit, da det er sandsynligt, at skrifttypefilen er blevet hentet og lagret i cache på det tidspunkt).
Selv om Optional kan løse både FOIT og FOUT, er ulempen, at den besøgende måske sidder fast med fallback-skrifttypen til deres første sidevisning.
Hvis du er fortrolig med at arbejde med CSS, kan du manuelt redigere Font-Display-egenskaben i dit child theme’s stylesheet.
Hvis du ikke føler dig fortrolig med at gøre det, kan du også finde nogle plugins, der kan hjælpe dig:
- Swap Google Fonts Display – aktiverer nemt skrifttype-visningsswap for Google Fonts.
- Asset CleanUp – understøtter Google Fonts gratis og brugerdefinerede lokale skrifttyper med Pro-versionen.
- Perfmatters – tilbyder en funktion til Google Fonts.
Hvis du bruger Elementor, indeholder Elementor også en indbygget indstilling til at gøre dette. Gå til Elementor → Indstillinger → Avanceret. Du kan derefter indstille rullemenuen Google Fonts Load lig med Swap eller Optional alt efter dine præferencer:
For kompleks? Overvej en System Font Stack!
Hvis al denne snak om preloading og Font-Display er en smule forvirrende, er en nem løsning at bruge en systemskriftstabel i stedet for en brugerdefineret skriftstabel.
Selv om dette begrænser dine designmuligheder, løser det fuldstændigt problemerne med Cumulative Layout Shift-skrifttyper, FOIT og FOUT. Desuden vil det også hjælpe dit websted med at indlæse meget hurtigere.
Hvis du er interesseret i dette, kan du tjekke Brians vejledning til brug af en systemskriftstamme på WordPress.
Reserver plads til annoncer (hvis du bruger Display Ads)
Hvis du bruger displayannoncer, er det vigtigt, at du reserverer plads til disse annoncer i koden på dit websted. Dette følger den samme idé som at reservere plads til billeder, videoer og indlejringer.
Displayannoncer fortjener dog en særlig omtale, fordi det er meget almindeligt at have displayannoncer, der indlæses sent, hvis du bruger nogen form for budteknologi. Det skyldes, at budteknologien skal bruge tid til at arbejde og finde ud af, hvilken annonce der skal vises.
Det kan også være et problem med automatiske AdSense-annoncer, hvis du har dynamiske annoncepladser, fordi AdSense ud over problemet med budgivning også indlæser annoncer i forskellige størrelser (så du kender måske ikke annoncens størrelse på forhånd).
Hvis du bruger et af de populære displayannonceringsnetværk som Mediavine eller AdThrive, bør de allerede tilbyde værktøjer, der hjælper dig med at undgå layoutforskydninger med dine annoncer. Hvis du f.eks. åbner Mediavines annonceindstillinger, kan du aktivere en toggle til at optimere annoncer til CLS:
For at optimere AdSense for Cumulative Layout Shift er det lidt mere tricky.
En almindelig løsning er at tilføje et <div>-wrapper-element omkring hver annonceenhed, der angiver en minimumshøjde ved hjælp af CSS-egenskaben min-height . Du kan også bruge media queries til at ændre minimumshøjden baseret på en brugers enhed.
Google anbefaler, at du indstiller min-højden svarende til den størst mulige annoncestørrelse. Selv om dette kan resultere i spildt plads, hvis der vises en mindre annonce, er det den bedste mulighed for at eliminere enhver risiko for, at der opstår et layoutskifte.
Når du opretter dette wrapper-element, skal du sørge for at bruge et CSS-id i stedet for en klasse, da AdSense ofte fjerner CSS-klassen fra overordnede objekter.
Sådan kan CSS’en se ud:
Og her er, hvordan AdSense-indlejringen kan se ud:
På frontend vil du nu se, at dit websted reserverer plads til annoncen, selv om den er tom:
Vær smart, når du dynamisk injicerer indhold med plugins
Mange WordPress-websteder vil dynamisk injicere indhold til funktioner som f.eks. meddelelser om cookie samtykke, relateret indhold, e-mail opt-in-formularer osv.
Selv om dette er fint at gøre, skal du være forsigtig med at undgå at gøre det på en måde, der forårsager layoutforskydninger.
En god bedste praksis for webdesign er her at aldrig at injicere indhold over eksisterende indhold, medmindre brugeren specifikt har foretaget en interaktion (f.eks. ved at klikke på en knap).
Hvis du f.eks. tilføjer en meddelelse om samtykke til cookies, skal du ikke placere den øverst på siden, fordi det ville få indholdet til at blive skubbet nedad(medmindre du allerede har reserveret plads til banneret om samtykke til cookies).
I stedet skal du vise meddelelsen nederst på siden, så du undgår at flytte synligt indhold nedad.
Hvis du vil se, om dynamisk indhold er årsag til problemet, kan du bruge visualiseringsværktøjerne fra ovenfor (f.eks. Layout Shift GIF Generator).
Hvis du kan se, at indhold fra et bestemt plugin udløser layoutforskydninger, kan du overveje at justere det pågældende plugins indstillinger eller skifte til et andet plugin.
For eksempel er nogle plugins til cookietilladelse bedre end andre, når det gælder layoutforskydninger, så det er værd at eksperimentere med forskellige plugins, hvis du har problemer.
Hvis du vil grave endnu dybere ned i plugin-adfærd, kan du bruge et værktøj til overvågning af applikationspræstationer. Hvis du er hosted hos Kinsta, er Kinstas APM-værktøj gratis tilgængeligt i dit MyKinsta-dashboard, eller du kan finde andre APM-værktøjer.
For at hjælpe dig med at teste plugins kan du også bruge Kinstas staging sites eller DevKinsta-værktøjet til lokal udvikling.
Brug CSS Transform-egenskaben til animationer, når det er muligt
Hvis du bruger animationer på dit websted, kan disse være en anden almindelig synder for layoutforskydninger.
For at undgå problemer med animationer, der forårsager layoutforskydninger, bør du bruge CSS Transform-funktionen til animationer i stedet for andre taktikker:
- I stedet for at bruge egenskaberne højde og bredde skal du bruge transform: scale()
- Hvis du vil flytte elementer rundt, skal du bruge transform: translate() i stedet for top, bund, højre eller venstre
Dette er mere et teknisk tip, så det er usandsynligt, at du har brug for at gøre dette, medmindre du tilføjer din egen CSS. Hvis du vil vide mere, kan du læse Googles side om CLS og animationer/transitions.
Opsummering
Hvis dit websted har en høj score for Cumulative Layout Shift, er det vigtigt at rette op på det, både for at skabe en bedre oplevelse for dine menneskelige besøgende og for at maksimere webstedets ydeevne i Googles søgeresultater.
To af de mest almindelige problemer er manglende dimensioner for billeder/embeds og problemer med indlæsning af skrifttyper. Hvis du retter disse, bør du være på vej til en meget bedre score.
Andre websteder skal måske gå længere og grave i indlæsning af annoncer, dynamisk indhold og animationer. Hvis du har svært ved at implementere disse typer optimeringer selv, kan du overveje at samarbejde med et WordPress-bureau eller en freelancer.
Hvis du vil vide mere om Core Web Vitals generelt, kan du læse hele Kinsta-guiden til Core Web Vitals.
Og hvis du vil have en WordPress-vært, der kan hjælpe dig med at skabe et højtydende websted, der klarer sig godt i Core Web Vitals, kan du overveje at bruge Kinstas administrerede WordPress-hosting – vi migrerer dine WordPress-websteder gratis!
Content & Marketing Editor at Kinsta, WordPress Web Developer, and Content Writer. Outside of all things WordPress, I enjoy the beach, golf, and movies. I also have tall people problems ;).
Skriv et svar