CDN — Content Delivery Network og SEO
Et CDN sætter kopier af dit indhold på servere globalt tæt på brugerne. Det reducerer TTFB, forbedrer LCP og aflaster din origin-server.
Et CDN — Content Delivery Network — er et globalt netværk af servere der gemmer kopier af dit indhold tæt på brugerne. Når en bruger i Tokyo besøger dit site der hostes i Frankfurt, henter de i stedet indholdet fra en edge-server i Singapore eller Tokyo. Resultatet er markant lavere TTFB og hurtigere sideindlæsning.
Hvad et CDN faktisk gør
Et CDN fungerer ved at placere edge-servere på strategiske steder globalt. Disse edge-servere cacher statiske ressourcer — billeder, CSS, JavaScript, videoer og i mange tilfælde hele HTML-sider. Når en bruger laver en request, router CDN’en forespørgslen til den nærmeste edge-server. Har edge-serveren indholdet i sin cache, serveres det direkte. Har den det ikke, hentes det fra din origin-server, caches og serveres.
For SEO er den direkte gevinst reduceret TTFB: distance er en fysisk realitet, og jo kortere netværksafstand, jo lavere latency. TTFB er en direkte komponent i LCP — forbedrer du TTFB, forbedrer du LCP.
Statisk vs. dynamisk indhold
Et CDN virker bedst på statisk indhold med lange cache-levetider. Billeder, skrifttyper, CSS og JavaScript er ideelle CDN-ressourcer — de ændrer sig sjældent og kan caches aggressivt.
Dynamisk indhold — sider der genereres per request fra en database — er sværere. Standardopsætningen er at CDN’en fungerer som proxy og henter indholdet fra origin ved hvert request. Du får stadig reduceret latency for forbindelsen selv, men ikke cache-gevinsten.
Nyere CDN-løsninger som Cloudflare Workers og Vercel Edge Functions lader dig køre kode direkte på edge-servere. Det løser problemet med dynamisk indhold ved at flytte logikken ud til edge — men det kræver arkitektoniske valg tidligt i projektet.
Caching og cache-invalidering
CDN-caching styres primært af HTTP cache-headers fra din origin: Cache-Control, ETag og Expires bestemmer hvor lang tid en ressource gemmes på edge-serverne. Jo længere cache-levetid, jo sjældnere skal edge-serveren kontakte din origin.
Problemet opstår når indhold ændrer sig. Hvis du opdaterer et billede eller et stylesheet, skal du tømme (invalidere) cachen på alle edge-servere — ellers serverer CDN’en det gamle indhold. De fleste CDN-udbydere tilbyder API-baseret cache-invalidering og path-baserede regler. Astro og lignende build-frameworks løser det anderledes: nye builds genererer nye filnavne med content hash, så gammelt cachet indhold aldrig kolliderer med nyt.
CDN og HTTPS
CDN’en håndterer SSL-terminering ved edge: den krypterede forbindelse fra brugerens browser afsluttes ved CDN-serveren. Forbindelsen videre til din origin kan enten gå over HTTP (origin pull over HTTP) eller HTTPS (origin pull over HTTPS). Det sidste er den sikre opsætning og bør altid bruges.
De fleste CDN-udbydere — Cloudflare, Fastly, AWS CloudFront — udsteder og forny SSL-certifikater automatisk via Let’s Encrypt. Det er en af de funktioner der gør moderne CDN-opsætning væsentligt enklere end for fem år siden.
Hvornår et CDN ikke er svaret
Et CDN er ikke en løsning på en langsom origin-server. Har din server et TTFB på 3 sekunder fordi databaseforespørgsler er ukomplette, gør et CDN det hurtigere at levere en langsom side — men det løser ikke den underliggende flaskehals.
Start med hosting og server-konfiguration. Tilføj CDN som et distributionslag ovenpå en server der allerede er hurtig. → Denne artikel er en del af Server og HTTP-responser — Statuskoder, redirects og caching.
Andre artikler i samme emne
- Backend — Server-side kode og SEO
- Caching — Browser-caching og server-caching til SEO
- HTTP headers — Request og response headers til SEO
- HTTP-statuskoder — 200, 301, 404, 500 og SEO
- HTTPS og SSL/TLS — Sikker forbindelse som SEO-signal
- Komprimering — Gzip, Brotli og hurtigere sideindlæsning
- Minificering — Reducer CSS, JavaScript og HTML-filstørrelser
- Redirect chains — Kæder af omdirigeringer og SEO
- Redirects — 301, 302 og hvornår du bruger hvad
- Sikkerhedsheaders — HSTS, CSP og SEO-konsekvenser
- Soft 404 — Sider der returnerer 200 men opfører sig som 404
Ofte stillede spørgsmål
- Forbedrer et CDN altid SEO?
- Et CDN forbedrer TTFB og LCP for brugere der er geografisk langt fra din origin-server — og det gavner Core Web Vitals. For sites der primært har lokale brugere tæt på origin-serveren er gevinsten minimal. CDN giver størst SEO-effekt på internationale sites eller sites med serne der sidder i én by.
- Hvad er forskellen på CDN og hosting?
- Din hosting (origin-server) er det sted der faktisk genererer og gemmer dit indhold. CDN er et distribueret netværk der cacher og leverer dit indhold fra servere tæt på slutbrugeren. CDN erstatter ikke hosting — det sætter sig imellem brugeren og din origin-server og håndterer de fleste requests.
- Hvad sker der med HTTPS og SSL på et CDN?
- CDN'en håndterer SSL-terminering — det vil sige at den krypterede forbindelse afsluttes ved CDN-edge-serveren, ikke ved din origin. Det betyder at du skal have et SSL-certifikat konfigureret både hos CDN'en og eventuelt mellem CDN og origin (origin-pull over HTTPS). De fleste CDN-udbydere automatiserer dette.
- Hvad er cache-invalidering og hvornår er det nødvendigt?
- Cache-invalidering er processen at tømme og forny cachet indhold på CDN-edge-serverne. Det er nødvendigt når du opdaterer indhold — et billede, et stylesheet, en side — der allerede er cachet. Uden invalidering vil CDN'en servere gammel version. De fleste CDN-udbydere tilbyder API-baseret invalidering. Moderne build-frameworks som Astro løser problemet med content-hashing i filnavne, så cache-konflikt aldrig opstår.
- Påvirker et CDN Googlebots crawling?
- Et CDN påvirker normalt ikke Googlebots crawling — Googlebot modtager det samme indhold som andre brugere. Men ukorrekt CDN-konfiguration kan skabe problemer: sider der serveres forskelligt til Googlebot og brugere (cloaking), eller edge-servere der returnerer forkerte HTTP-statuskoder til Googlebots IP-range. Tjek altid at CDN-konfigurationen ikke blokerer Googlebots IP-adresser.
Placering i ordbogen
- Backend — Server-side kode og SEO
- Caching — Browser-caching og server-caching til SEO
- HTTP headers — Request og response headers til SEO
- HTTP-statuskoder — 200, 301, 404, 500 og SEO
- HTTPS og SSL/TLS — Sikker forbindelse som SEO-signal
- Komprimering — Gzip, Brotli og hurtigere sideindlæsning
- Minificering — Reducer CSS, JavaScript og HTML-filstørrelser
- Redirect chains — Kæder af omdirigeringer og SEO
- Redirects — 301, 302 og hvornår du bruger hvad
- Sikkerhedsheaders — HSTS, CSP og SEO-konsekvenser
- Soft 404 — Sider der returnerer 200 men opfører sig som 404