Hvis tekst hopper rundt, føles et site hurtigt “billigt” – og det kan direkte påvirke både læsbarhed og klik. Font-loading er en af de mest almindelige årsager til CLS på content-sites, fordi fonts påvirker tekstens bredde og højde.
I denne artikel får du en praktisk tilgang til at gøre fonts stabile, uden at du behøver et komplekst setup. Den supplerer guiden om CLS og layout og ordbog: CLS - her er fokus på typografi, ikke på billeder eller embeds.
Målet: Læsbar tekst fra første sekund, minimal synlig forskel når webfonten lander, og ingen målbare layout-skift der frustrerer brugeren eller skader Core Web Vitals.
Hvorfor kan fonts give CLS?
Når en webfont loader sent, kan teksten ændre bredde/højde og skubbe layout.
Typisk sker det sådan:
- Browseren viser teksten med en fallback-font.
- Webfonten bliver downloadet.
- Teksten bliver re-renderet med webfonten.
- Hvis webfontens “metrics” (x-height, ascent, descent, bredde) afviger, flytter layout sig.
Det er ikke altid et stort hop, men selv små skift kan give CLS – især hvis skiftet sker i en hero-tekst, en navigation eller en knap.
Hvad er FOIT og FOUT?
To klassiske mønstre:
- FOIT (Flash of Invisible Text): teksten er usynlig mens font loader
- FOUT (Flash of Unstyled Text): teksten vises med fallback og skifter senere
De fleste moderne strategier går efter at vise tekst tidligt, men med minimal ændring når webfonten lander.
Hvilken indflydelse har font-problemer?
Når fonts giver CLS, rammer det:
- læsbarhed (man mister linjen)
- interaktion (elementer flytter sig)
- oplevet kvalitet (sitet virker ustabilt)
Fonts kan også påvirke performance bredt, fordi mange store fontfiler øger netværk og CPU-arbejde.
Praktiske greb
- Brug
font-display: swap - Vælg en fallback-font med lignende metrics
- Begræns antal weights og varianter
Flere tiltag (hvis du vil længere)
- Preload kun fonts der bruges i første viewport
- Subsetting hvis fontfilerne er store
- Undgå unødvendige italics/weights
En praktisk opskrift (trin-for-trin)
Hvis du vil gøre det her systematisk og hurtigt, kan du følge denne proces.
Trin 1: Beslut hvor mange fonts du reelt har brug for
På de fleste content-sites er det nok med:
- 1 fontfamilie til brødtekst
- evt. samme familie til overskrifter
- 2 weights (fx 400 + 600)
Hvis du ender med 6 weights, italics og flere familier, får du ofte:
- mere netværk (flere fontfiler)
- mere risiko for skift (CLS)
- mere kompleksitet i CSS
Trin 2: Gør baseline stabil
Start med:
font-display: swap- en fallback-font der ligger tæt på din webfont
Målet er at FOUT bliver så “usynlig” som muligt.
Trin 3: Reservér stabilitet via fallback-metrics
Selv med en god fallback kan der være små forskelle. Det vigtigste er at reducere ændringen i:
- linjehøjde
- tekstbredde
- x-height
Hvis du ser hop, er det et tegn på at fallback og webfont ikke matcher godt nok.
I moderne CSS kan du arbejde mere målrettet med metric alignment mellem fallback og webfont - fx size-adjust, ascent-override, descent-override og line-gap-override på @font-face (understøttelse varierer mellem browsere; verificér i dine mål-browsere). Idéen er at få fallback’en til at fylde cirka samme bounding box som webfonten, så skiftet bliver næsten usynligt. Det er mere præcist end blot at vælge “en anden sans-serif”.
Trin 4: Preload kun hvis discovery er problemet
Hvis fonten først loader sent, og du kan se det i waterfall/performance trace, kan preload give mening.
Men preload kun:
- de få fontfiler der bruges i første viewport
Trin 5: Subsetting hvis filer er store
Hvis dine fontfiler er store, kan subsetting hjælpe. Til dansk er “latin” ofte nok (men vær opmærksom på specialtegn). Store filer betyder længere download og ofte senere “swap” - jo senere webfonten kommer ind, jo større risiko for synlig forskel. Se også ordbog: font-subsetting og font-display.
Trin 6: Undgå unødige font-familier og vægte
Hver ekstra weight eller italic er typisk en ekstra fil og et ekstra punkt hvor layout kan ændre sig. Mange designs kan klare sig med regular + semibold. Færre filer giver ofte både bedre performance og mere forudsigeligt layout.
Typiske scenarier (og hvad man gør)
Scenario A: Navigationen hopper når fonten loader
Typisk årsag:
- fallback-font er smallere/bredere
Løsning:
- vælg fallback tættere på webfont
- brug en mere stabil font-size/line-height
Scenario B: Hero-overskriften “skubber” resten ned
Typisk årsag:
- overskrift har stor størrelse, så små metric-forskelle giver stort layout-skift
Løsning:
- preload hero-font (hvis relevant)
- brug fallback med næsten samme metrics
Scenario C: CLS er lav i lab, men høj i felt
Typisk årsag:
- rigtige brugere har langsommere netværk/enheder
- fonten loader senere i virkeligheden
Løsning:
- test på mobilnetværk
- reducer fontantal/weights
- overvej at bruge system fonts hvis målet er maksimal stabilitet
Sådan tester du om fonts skaber CLS
- Brug DevTools Performance og kig efter “Layout Shifts”
- Simulér langsomt netværk, så font-loading bliver tydeligere
Preload: hvornår det hjælper - og hvornår det skader
Hjælper når én kritisk .woff2 bruges til hero-overskriften og I ellers ville vente på CSS-kæden - og I har målt at filen starter sent. Brug preload med korrekt crossorigin som matcher @font-face.
Skader hvis I preload’er mange snitte, forkerte filer, eller konkurrerer med LCP-billedet om samme tidlige båndbredde. Start med nul preload og tilføj kun med før/efter-waterfall.
Mini-checkliste
- Fallback-font matcher webfontens metrics så godt som muligt
-
font-displayvalgt bevidst (ordbog) - Font subsetting overvejet ved store filer
- CLS tjekket med throttling på mobil
Relateret
- Guide: Fix CLS og layout-stabilitet
- Blog: 5 grunde til at en side er langsom (afsnit om CSS og fonts)
- Ordbog: FOIT og FOUT
Relaterede blogindlæg
Cookie banner og Core Web Vitals: den oversete årsag til dårlig brugeroplevelse
2026-03-24Se hvordan cookie bannere og consent scripts kan påvirke load, layout og interaktion, og lær hvordan du undgår at de ødelægger brugeroplevelsen.
5 grunde til at din hjemmeside er langsom og hvad du gør ved det
2025-11-14Se de mest almindelige årsager til en langsom hjemmeside, hvordan du spotter dem, og hvilke ændringer der typisk giver mest effekt først.
Range request i praksis: når 206 Partial Content ikke sker (og hvad det koster)
2026-04-02En feltguide til at spotte når browseren forsøger at bruge Range request, men ender med at få hele filer retur (200 i stedet for 206). Lær at se det i DevTools og ret fejl i proxy/CDN/origin.
Hvordan du spotter render delay (uden at stirre på score)
2026-04-01Render delay er ofte grunden til at LCP bliver 1–2 sekunder for sent, selv når TTFB ser fin ud. Her er metoden til at finde årsagen hurtigt – og vælge den rigtige type fix.
Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis
2026-03-30Reverse proxy-laget kan være årsagen til høj TTFB, mystiske cache misses og 502/504-fejl. Lær hvad du skal kigge efter i headers og waterfall, og få et praktisk debug-flow.
Vary-header og caching: undgå forkert indhold og lav cache-hit-rate
2026-03-30Vary bestemmer hvornår caches skal gemme flere varianter af samme URL (fx gzip vs brotli eller dansk vs engelsk). Lær de typiske fejl, og hvordan du tester med headers og curl.
FAQ
Skal man altid bruge webfonts?
Nej. System fonts kan være meget hurtige og stabile. Men hvis typografien er en vigtig del af designet, kan webfonts stadig være et godt valg med korrekt opsætning.
Hvad er det vigtigste, hvis jeg kun gør én ting?
Vælg en fallback-font der matcher webfontens metrics bedst muligt. Det reducerer layout-skift mest effektivt i praksis.
Hjælper `font-display: optional`?
`optional` kan gøre oplevelsen mere stabil på langsomme forbindelser, fordi browseren kan vælge at blive på fallback-fonten. Til gengæld får nogle brugere aldrig webfonten. Det er et bevidst trade-off mellem stabilitet og brand-typografi.
Næste skridt i samme emne
Fortsæt fra forklaring til handling med guides, emner og ordbog.
