Kort fortalt: Et CDN (Content Delivery Network) er et netværk af servere (edge-noder) der leverer indhold tættere på brugeren og ofte kan cache indhold, så færre requests rammer din origin-server.
Hvad gør et CDN?
- Serverer statiske filer fra nærmeste edge-node
- Kan cache HTML/JSON afhængigt af setup
Typiske forbedringer
- Edge caching af HTML for bedste TTFB
- Versionerede assets + lang cache
I praksis kan et CDN hjælpe på to måder:
- Geografi/latency: Brugeren rammer en edge-node tæt på, i stedet for din origin langt væk.
- Caching: Edge kan servere content direkte uden at spørge origin (cache hit).
Hvilken indflydelse har et CDN?
De typiske effekter du ser på performance:
- Lavere TTFB (især hvis HTML caches ved edge)
- Mere stabil levering (mindre varians pga. origin-load)
- Hurtigere assets (billeder/CSS/JS tæt på brugeren)
Et CDN er ikke “magisk”. Hvis din flaskehals er tung JavaScript (INP) eller render-blocking CSS, løser et CDN ikke det alene. Men det kan give et bedre fundament ved at gøre netværksdelen hurtigere og mere stabil.
Hvornår blev CDNs udbredt?
CDNs har eksisteret i mange år, men er blevet standard i takt med:
- global trafik og mobile brugere
- flere og større assets (billeder, JS bundles)
- krav til stabil performance (Core Web Vitals)
- udbredelse af edge caching og sikkerhedstiltag (WAF/DDoS)
HTML vs assets: den vigtigste skel
Assets (CSS/JS/billeder/fonts)
Assets er den mest oplagte CDN-case, fordi:
- de kan versioneres (hash i filnavn)
- de ændrer sig sjældnere
- de kan caches meget længe
Typisk caching:
Cache-Control: public, max-age=31536000, immutable(for versionerede assets)
HTML (sider)
HTML caching ved edge kan give den største TTFB-forbedring på content-sites, men kræver mere omtanke:
- personalisering (cookies/login) kan gøre caching forkert
- lister (blog-index/emner) ændrer sig oftere
- du skal have en purge-/revalidation-strategi
På et videnssite er HTML ofte ens for alle, så edge caching er typisk realistisk.
Typiske fejl (som gør CDN mindre effektivt)
- HTML kan ikke caches pga. cookies på alle requests
- assets er ikke versionerede, så du tør ikke cache længe
- for mange variation headers (
Vary) der splitter cachen unødigt - ingen purge (så du ender med at cache for kort for at være sikker)
Sådan tester du om CDN’et virker
Praktisk metode:
- Åbn DevTools → Network og kig på response headers
- Kig efter CDN-indikatorer som
age,cf-cache-status,x-cache,x-served-by(varierer efter CDN) - Sammenlign kold vs varm cache:
- kold: første request (cache miss)
- varm: gentag request (cache hit)
Hvis TTFB ikke falder på gentagelse, er HTML typisk ikke cached (eller cachen bliver busted).
FAQ
Kan et CDN alene gøre et site “hurtigt”?
Det kan forbedre TTFB og asset-levering, især når HTML eller statiske assets kan serveres tæt på brugeren fra edge.
Men hvis flaskehalsen er render-blocking, tunge bundles/INP eller dårlig billedprioritering, skal du stadig optimere frontend og templates. CDN er et fundament – ikke en erstatning for oprydning.
Hjælper CDN også SEO?
Indirekte. Bedre performance og stabilitet kan forbedre brugeroplevelse og Core Web Vitals, og gøre crawl/rendering mere robust.
Men SEO afhænger stadig primært af relevans, indhold og intern struktur. CDN er en teknisk hjælp, ikke en ranking-genvej.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Brug Transfer-Encoding (chunked) til progressiv rendering: hurtigere første visning
Lær at finde ud af om din server eller reverse proxy buffer HTML-svar, og få streaming (chunked) til at flytte første visning og LCP i den rigtige retning.
Gør hero til LCP: sådan ændrer du struktur, CSS og prioritering
Hvis LCP bliver en tilfældig paragraf i stedet for hero, får du både dårligere tal og en måling der ikke matcher brugerens første indtryk. Her er en konkret metode til at få hero (H1/billede) til at blive LCP – uden at snyde.
Få edge cache-hit på HTML: undgå cookies, forkert Vary og dårlige cache keys
Mange sites har CDN, men får stadig høj TTFB fordi HTML ikke caches. Lær et praktisk workflow til at få cache-hit på offentlige sider uden at servere forkert indhold.
Range request i praksis: når 206 Partial Content ikke sker (og hvad det koster)
En 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)
Render 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
Reverse 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.
