Hurtigere hjemmeside hjælp til en langsom hjemmeside

Undgå CLS fra fonts

Lær at undgå layout-hop (CLS) fra webfonts med font-display, fallback-strategi og korrekt preload. Guiden er til dig der vil have pæn typografi uden at ødelægge stabilitet.

Skrevet af Kim Tetzlaff

Trin-for-trin

  1. Bekræft at CLS faktisk kommer fra fonts (DevTools, Lighthouse og visuel test).

  2. Sæt en bevidst font-display-strategi og vælg stabile fallback-fonts med tilsvarende metrikker.

  3. Begræns font-filer (weights, subsets) og preload kun de kritiske varianter.

  4. Mål igen i lab og felt, og tjek at CLS falder uden at LCP/INP forværres.

Webfonts er et klassisk sted hvor et site kan føles “færdigt”, men stadig hopper. Brugeren ser først teksten i en fallback-font, og derefter skifter den til webfont – og så flytter linjeskift, knapper og kort sig.

Det er CLS i praksis.

Målet med guiden: At få flot typografi uden at give layout-hop, og uden at du “løser” CLS ved at gøre siden langsommere.

Hvis du vil forstå CLS generelt, start her: Fix CLS (layout stabilitet). Denne guide zoomer ind på fonts.

Før du går i gang

Du får mest ud af guiden hvis du har:

  • adgang til tema / CSS / build (eller mulighed for at tilføje egne CSS-regler)
  • mulighed for at se hvilke font-filer der faktisk loades (DevTools Network)
  • en side hvor problemet er tydeligt (typisk forside, landingsside eller blogindlæg)

Vigtigt: Mål på en rigtig URL, ikke en tilfældig testsidetype.

Trin 1: Bekræft at CLS kommer fra fonts (ikke billeder eller bannere)

Font-CLS ligner ofte “små hop”, men det kan nemt forveksles med:

Gør dette:

  1. Kør Lighthouse/PSI og se om der nævnes “layout shifts”.
  2. Åbn DevTools → Performance og optag en load.
  3. Se om de store shifts sker samtidig med at fonts hentes (Network) eller når @font-face aktiveres.

Hvis shifts topper når font-filer bliver færdige, er det et stærkt signal.

Trin 2: Vælg en font-display strategi (og forstå trade-off’et)

font-display styrer hvordan browseren viser tekst før webfont er klar.

De mest brugte strategier:

  • swap: vis fallback med det samme, skift når fonten er klar (hurtig tekst, risiko for hop)
  • optional: skift kun hvis fonten kommer hurtigt nok (mere stabilt på langsomme net)

Læs baggrund: font-display.

Tommelregel for content-sites:

  • Start med swap eller optional
  • og gør layout stabilt med gode fallbacks (næste trin)

Trin 3: Gør fallback-fonten “metrisk kompatibel”

Den mest oversete del er ikke preload – det er forskellen i bredde/højde mellem fallback og webfont.

Når fallback og webfont har forskellige metrikker, ændres:

  • linjebrud
  • højde på afsnit
  • placering af knapper og links

Praktisk:

  1. Vælg en fallback-stack der ligner din webfont (fx systemfont der matcher stil og bredde).
  2. Hold font-size, line-height og letter-spacing stabile i CSS (undgå at ændre dem sent).
  3. Hvis du arbejder mere avanceret: overvej size-adjust i @font-face (når det giver mening).

Målet er at swap bliver et “farveskift” mere end et layoutskift.

Trin 4: Skær font-filer ned (så swap sker hurtigt – eller slet ikke behøves)

Font-filer bliver ofte tunge fordi man loader:

  • for mange weights (300/400/500/600/700…)
  • både normal + italic uden at bruge italic
  • alt for mange glyphs (hele Unicode-set)

Gør dette:

  • behold kun de weights du faktisk bruger
  • overvej font subsetting (men gør det bevidst)
  • cache fonts korrekt (lang cache på versionerede fontfiler)

Trin 5: Preload kun de kritiske fonts (og kun hvis du har et konkret problem)

Preload hjælper når en kritisk font opdages sent og dermed skifter sent.

Men:

  • preload af for mange fonts skubber andre kritiske downloads (kan skade LCP)
  • preload af en font du ikke bruger above the fold er spild

Hvis du preloader:

  • preload kun 1–2 kritiske fontfiler til første viewport
  • verificér i waterfall at font-download starter tidligere

Se også: guide: brug fetchpriority og preload rigtigt og ordbog: preload.

Trin 6: Mål igen og tjek for bivirkninger

Efter ændringer:

  • test samme URL igen (3–5 runs)
  • se om CLS falder
  • tjek samtidig at du ikke har gjort LCP værre (fx ved at preload konkurrerer)

Hvis du kan, sammenlign feltdata over tid (CrUX/Search Console). Læs om lab vs felt: Lighthouse vs CrUX.

Typiske fejl (som giver “fixes” der ikke virker)

  • Du sætter font-display: swap, men har ingen fallback-strategi → CLS flytter sig bare.
  • Du preloader alt → LCP bliver dårligere, men CLS er kun marginalt bedre.
  • Du loader fonts via tredjepart eller scripts der kører sent → swap kommer sent og giver større hop.
  • Du ændrer line-height eller font-size med JS/CSS efter load → selv uden webfonts kan det hoppe.

Opsamling

Font-CLS løses sjældent med ét trick. Den praktiske rækkefølge er:

  1. bekræft årsagen
  2. vælg font-display
  3. stabilisér fallbacks
  4. reducer font-vægt
  5. preload kun hvis nødvendigt

Relateret på sitet

Relaterede guides

FAQ

Hjælper font-display: swap altid?

Det hjælper ofte på oplevet load, men kan give layout-hop hvis fallback og webfont fylder forskelligt. Målet er ikke bare swap - det er stabil typografi med kontrolleret fallback.

Skal jeg preload alle fonts?

Nej. Preload kun de fonts der er kritiske for første viewport. For mange preloads kan stjæle båndbredde og gøre LCP værre.

Kan jeg få CLS fra fonts selv uden webfonts?

Sjældnere, men ja: fx hvis CSS skifter font-family sent (tema/plugin), eller hvis du loader en font via JS og skifter klasser efter render.

Eksterne kilder

Reference til font-display og generelle performance-principper for font loading.

Næste skridt efter guiden

Brug emnesider, ordbog og blog til at validere og uddybe næste ændring.

Om forfatteren

Kim Tetzlaff

Kim skriver og vedligeholder indhold på hurtigere-hjemmeside.dk med fokus på målelig performance, Core Web Vitals og teknisk SEO. Målet er at gøre optimering konkret: hvad der faktisk flytter tal i feltdata, og hvordan du finder den korteste vej fra symptom til fix.

Kim Tetzlaff