Hvad er en CDN? (Content Delivery Network)

Hvad er et CDN - forklaret helt simpelt

Når en bruger besøger din hjemmeside, skal browseren hente en masse filer: HTML, billeder, skrifttyper, CSS, JavaScript, måske video og større PDF-filer. Hvis din server står i ét datacenter, skal alle besøg rundt i verden derhen efter filerne. Jo længere der fysisk er mellem bruger og server, jo højere bliver latensen.

Et CDN lægger sig ind imellem:

• Din egen server, ofte kaldet origin (oprindelsesserver).
• Et netværk af edge-servere, placeret i datacentre rundt i verden.

Når en bruger beder om en ressource, bliver trafikken sendt til den nærmeste edge-server. Hvis filen allerede ligger der (cache-hit), leveres den direkte. Hvis ikke (cache-miss), henter edge-serveren filen fra din origin, gemmer en kopi og leverer den til brugeren. Næste bruger i samme region får filen meget hurtigere.

For den almindelige website-ejer betyder det: mindre ventetid, hurtigere sideindlæsning og færre tunge spidsbelastninger på din egen server.

Origin, edge og POPs

For at forstå CDN i praksis er der tre begreber, der går igen:

• Origin-server
  Din “rigtige” server, hvor WordPress, PHP, database og filer bor. Det er her din applikation kører, og hvor nye sider genereres.
• Edge-server
  En server i CDN-netværket, placeret tæt på brugerne. Den fungerer som et spejl, der gemmer kopier af de mest brugte filer.
• POP (Point of Presence)
  Et fysisk knudepunkt eller datacenter i et bestemt geografisk område. Hvert POP har typisk flere edge-servere.

Set udefra går trafikken sådan her:

1. Bruger skriver dit domæne i browseren.
2. DNS (Domain Name System) sender brugeren til CDN’et i stedet for direkte til din origin.
3. CDN’et finder nærmeste POP.
4. Edge-serveren i POP’et leverer filerne, hvis de findes i cache. Ellers hentes de fra origin og gemmes til næste gang.

DNS og routing - hvordan brugeren ender på CDN’et

Et CDN er tæt koblet til DNS, som bestemmer, hvilken IP-adresse dit domæne peger på.

Typisk sker der én af to ting:

1. Dit domæne peger direkte på CDN’ets IP-adresser
   CDN’et står som front og fungerer som reverse proxy (en server, der modtager alle forespørgsler og sender dem videre til din origin, hvis det er nødvendigt).
2. Kun bestemte underdomæner går via CDN
   For eksempel cdn.ditdomæne.dk eller static.ditdomæne.dk, som bruges til billeder, scripts og CSS. HTML leveres stadig direkte fra din server, mens statiske assets hentes via CDN.

Brugeren behøver ikke vide, hvor filerne fysisk ligger. CDN’et håndterer routing og caching, og du styrer reglerne via et kontrolpanel.

Cache-hit, cache-miss og TTL

Kernen i et CDN er caching (mellemlagring):

• Cache-hit
  Forespørgslen rammer en fil, der allerede ligger i edge-cachen. Svartiden er meget lav, fordi der ikke skal spørges din origin.
• Cache-miss
  Forespørgslen rammer en fil, som CDN’et ikke har endnu, eller som er udløbet. CDN’et henter filen fra origin, gemmer en kopi og svarer brugeren.
• TTL (Time To Live)
  Hvor længe en fil må ligge i cache, før CDN’et skal tjekke origin igen. TTL kan styres i CDN-panelet eller via HTTP-headere som Cache-Control.

Typisk sætter man lange TTL’er på ting, der sjældent ændrer sig (billeder, versionerede CSS- og JS-filer), og kortere eller ingen caching på HTML og dynamisk indhold.

Hvad bruger man CDN til i praksis?

CDN bliver ofte solgt som “hurtigere hjemmeside”, men det bruges til flere ting:

• Statiske filer
  Billeder, skrifttyper, CSS, JavaScript, PDF, ZIP-filer og andre assets, der ikke ændrer sig for hver bruger.
• HTML og fuld side-cache
  Mange moderne CDN’er kan cache hele HTML-sider og fungere som global full page cache. Det giver stor hastighedsgevinst, men kræver omtanke omkring login, kurv, personalisering og cookies.
• Video og streaming
  Video og lyd i høj kvalitet, hvor en enkelt origin ellers ville blive overbelastet.
• APIs og dynamisk indhold
  Nogle CDN’er kan optimere eller delvist cache API-responser og bruge edge-funktioner til at tilpasse indhold tættere på brugeren.

I en klassisk WordPress-opsætning er det normalt at starte med at lægge billeder, CSS og JavaScript på CDN’et. Derefter kan man overveje HTML-cache via CDN, når resten af opsætningen er under kontrol.

CDN og hastighedsoptimering

En stor del af den oplevede hastighed handler om latens - hvor lang tid det tager for de første bytes at rejse fra server til browser (TTFB, Time To First Byte). Hvis origin-serveren står i én del af verden, og brugeren sidder langt væk, stiger latensen markant.

Et CDN hjælper især på:

• Global rækkevidde
  Brugere i Europa rammer et POP i Europa, brugere i USA rammer et POP i USA osv.
• Stabile svartider
  Spidsbelastninger fordeles på CDN’et i stedet for kun at presse din origin.
• Core Web Vitals
  Mindre latens og hurtigere levering af statiske filer kan forbedre især LCP (Largest Contentful Paint) og delvist INP (Interaction to Next Paint), fordi CPU og båndbredde frigives.

CDN erstatter ikke god kode, ordentlig hosting og korrekt caching på server og i browser. Det forstærker det setup, du har i forvejen. Har du en langsom, tung WordPress-installation, løser CDN ikke alle problemer, men det kan være det ekstra lag, der løfter en global målgruppe ned i grønne Core Web Vitals.

CDN og SEO

Søgemaskiner bruger hastighed og brugeroplevelse som en del af deres vurdering. Et CDN kan indirekte hjælpe SEO:

• Hurtigere indlæsning
  Hurtigere sider giver bedre brugeroplevelse, lavere bounce rate og bedre forudsætninger for konverteringer.
• Forbedrede Core Web Vitals
  LCP og andre hastighedsrelaterede metrics kan blive bedre, når statiske assets hentes fra et CDN i stedet for en overbelastet origin.
• Stabilitet under spidsbelastning
  Bliver et blogindlæg delt voldsomt, kan CDN’et levere de cachede sider, mens din origin slipper for at kæmpe alene.

SEO-mæssigt er det vigtigste, at HTML-indholdet er tilgængeligt, konsistent og hurtigt. CDN’et ligger som et ekstra lag foran og ændrer normalt ikke, hvad Google ser, så længe konfigurationen er fornuftig og ikke blokerer crawling.

CDN kontra caching på server og i browser

CDN og caching er forskellige lag, der arbejder sammen:

• Browser-cache
  Filer, som browseren gemmer lokalt. Styres med HTTP-headere som Cache-Control og Expires.
• Server-cache / HTML-cache
  For eksempel en WordPress cache-plugin, der gemmer færdigrenderet HTML, så PHP og database ikke skal køre hver gang.
• CDN-cache
  Kopier af filer på edge-serverne, tæt på brugerne, som aflaster origin.

En god opsætning sammenspiller alle tre lag:

• HTML-caching på serveren, så origin er hurtig.
• CDN, der spejler de hurtige HTML-sider og statiske assets globalt.
• Gode browser-cache-regler, så gentagne besøg bliver endnu hurtigere.

Har man ikke styr på hierarkiet, kan fejlfinding blive svær, fordi der kan ligge forskellige versioner af samme side forskellige steder.

Fordele ved at bruge CDN

De typiske fordele ved et velfungerende CDN er:

• Markant hurtigere levering til internationale brugere
  En bruger i USA skal ikke længere hele vejen til en server i f.eks. Danmark eller Tyskland.
• Aflastning af origin
  CDN’et tager størstedelen af statiske forespørgsler, så din server kan fokusere på dynamik og database.
• Bedre skalerbarhed
  Når du pludselig får 10 gange så meget trafik, kan CDN’et ofte absorbere meget af presset.
• Forbedret sikkerhed
  Mange CDN’er indeholder DDoS-beskyttelse, WAF (Web Application Firewall), botfiltre og mulighed for at terminere TLS (krypteret trafik) på edge-niveau.
• Support for HTTP/2 og HTTP/3
  Moderne protokoller, der håndterer flere filer parallelt og ofte giver hurtigere indlæsning, især på mobile netværk.

Ulemper og faldgruber ved CDN

Et CDN er ikke automatisk en gevinst i alle scenarier. Typiske faldgruber:

• Komplekst setup
  Der kommer et ekstra lag ind mellem bruger og server. Fejl kan ligge i DNS, CDN-konfiguration eller origin, og det gør fejlfinding mere tidskrævende.
• Cache-invalidering
  Når du opdaterer indhold, skal du vide, hvor cache’en ligger. CDN-cache skal ofte ryddes aktivt, hvis HTML eller kritiske filer ændres.
• Overdreven caching af HTML
  Hvis HTML caches uden hensyn til login, kurv, personalisering eller geografi, kan brugerne få forkerte data.
• Begrænset gevinst på små, lokale sites
  Hvis stort set alle brugere sidder i samme land tæt på serveren, og siden i forvejen er veloptimeret, kan gevinsten være mindre end forventet.
• Data og lovgivning
  Logger, IP-adresser og trafik kan blive håndteret i andre lande. Det skal tænkes ind i compliance og privatlivspolitik.

Typer af CDN-løsninger

CDN-markedet kan groft deles i et par kategorier:

• Klassiske globale CDN’er
  Store netværk med POPs i det meste af verden, ofte med avancerede funktioner som WAF, load balancing og edge-funktioner.
• CDN indbygget i hosting
  Flere moderne hostingleverandører har integreret CDN direkte i deres platform. Det betyder færre systemer at holde styr på, men også mindre mulighed for dyb tuning.
• WordPress-fokuserede CDN’er
  Løsninger hvor integration med WordPress, WooCommerce og cache-plugins er i centrum, fx automatisk rewriting af statiske filer og smart purge ved opdatering.

For at gøre det mere konkret giver det mening at se på nogle af de mest brugte CDN-udbydere og hvad de hver især er stærke til.

Eksempler på populære CDN-udbydere

Nedenfor er en række CDN-udbydere, som ofte går igen i tests, analyser og anbefalinger. De dækker tilsammen alt fra små blogs til tunge enterprise-setups.

Cloudflare

Cloudflare er en af de mest udbredte CDN-løsninger, blandt andet fordi der findes en stærk gratis plan, og fordi platformen kombinerer CDN, DNS, WAF og DDoS-beskyttelse i ét system. Netværket har et meget stort antal lokationer globalt, og fokus er på performance, sikkerhed og edge-funktioner. Cloudflare er stærkt til højtrafik-sider, API’er og projekter, hvor man vil have et kraftigt sikkerheds- og routinglag uden ekstra kompleksitet på origin.

Akamai

Akamai er en af de ældste og største aktører på CDN-markedet og bruges af mange banker, medier og streamingtjenester. Netværket er ekstremt udbredt og har fokus på høj tilgængelighed, stabilitet og avancerede sikkerhedsfunktioner. Akamai vælges ofte i enterprise-sammenhæng, hvor kravene til compliance, SLA og finmaskede løsninger er høje, og hvor man accepterer, at prisen og kompleksiteten ligger i den tunge ende.

Amazon CloudFront

Amazon CloudFront er Amazons CDN-tjeneste og spiller tæt sammen med AWS-økosystemet. Styrken ligger i, at du kan bygge hele applikationen omkring AWS (fx S3, EC2, Lambda) og lade CloudFront stå for distributionen globalt. Det giver fleksibilitet til alt fra streaming og API’er til globale webapps. Læringskurven er lidt stejlere, men til gengæld får du detaljeret kontrol, integreret sikkerhed og mulighed for at bruge samme adgangsstyring som resten af AWS-stakken.

Fastly

Fastly har fokus på højtydende edge-netværk og meget fleksibel cache-logik. Tjenesten er populær hos udviklertunge teams, SaaS-løsninger og større mediehuse, der vil styre, hvordan indhold manipuleres og leveres helt ude ved kanten. Fastly er stærkt, når man vil bruge edge computing, realtids-konfiguration og skræddersyede regler. Det er typisk ikke den billigste eller mest plug-and-play-agtige løsning, men til gengæld får man meget præcis kontrol.

Bunny.net

Bunny.net har gjort sig bemærket ved at levere høj hastighed til en meget konkurrencedygtig pris. Modellen er simpel, og deres kontrolpanel er let at gå til, især for WordPress- og WooCommerce-sites. Bunny.net er særligt interessant, når man vil have et globalt CDN med fokus på pris/ydelse, billedoptimering og video-distribution, uden at skulle ind i tunge enterprise- eller cloud-økosystemer.

KeyCDN

KeyCDN er en slank og prisvenlig CDN-tjeneste, der især henvender sig til blogs, mindre webshops og projekter, som vil i gang uden store forudbetalinger. Betalingsmodellen er pay-as-you-go med relativt lave priser pr. GB og et fornuftigt globalt netværk. KeyCDN er kendt i WordPress-miljøet for at være let at integrere og for ikke at drukne brugeren i funktioner, man ikke har brug for i mindre setups.

CDN77

CDN77 er særligt stærk på video og live-streaming, hvor løsningen tilbyder lav latenstid, optimeret mediedistribution og god stabilitet under høje trafikspidser. Ud over video bruges CDN77 også til klassiske webprojekter, men det er især streaming, gaming og medietunge setups, hvor den for alvor skiller sig ud. Det er et godt match, når man har store datamængder, komplekse mediekrav og et behov for global tilstedeværelse.

Cloudflare vs andre CDN’er

Cloudflare fylder meget i CDN-snakken, men det er ikke nødvendigvis den eneste eller bedste løsning i alle scenarier.

Cloudflare vs Akamai

Akamai sidder på en stor del af den globale CDN-trafik og er ofte det naturlige valg for meget store, regulerede virksomheder og streamingtjenester. Cloudflare har til gengæld vundet meget terræn hos webudviklere og vækstvirksomheder med en mere udviklervenlig platform, en stærk gratis plan og et tæt peering-netværk. Groft sagt vinder Akamai på enterprise-historik og udbredelse, mens Cloudflare vinder på tilgængelighed, features og samlet platform.

Cloudflare vs Amazon CloudFront

CloudFront giver størst mening, når du i forvejen bygger tungt på AWS og vil have et CDN, der integrerer direkte med S3, EC2, Lambda og resten af stakken. Cloudflare er mere neutral og kan stå foran næsten hvilken som helst origin. For mange klassiske websites er Cloudflare hurtigere at komme i gang med, mens CloudFront giver dyb integration og kontrol i AWS-baserede setups.

Cloudflare vs Fastly

Fastly henvender sig til teams, der vil skræddersy cache-logikken ned i mindste detalje og bruge edge computing intensivt. Cloudflare tilbyder også edge-funktioner, men med flere færdige byggesten og et kontrolpanel, hvor man kan komme langt uden at skrive alt fra bunden. Til klassiske webprojekter, WordPress og blandede webapps er Cloudflare ofte hurtigere at få i gang, mens Fastly vælges, når man har meget specifikke krav og et dedikeret udviklingsteam.

Cloudflare vs Bunny.net, KeyCDN og CDN77

Bunny.net, KeyCDN og CDN77 fokuserer hårdt på pris/ydelse og en enkel prismodel, som er let at gennemskue - især for mindre og mellemstore projekter. Cloudflare har en stærk gratis plan, men de betalte produkter kan hurtigt blive komplekse at overskue, hvis man tager meget med. Har du et mindre eller mellemstort site med fokus på enkelhed og pris, er Bunny.net eller KeyCDN ofte rigtig gode bud. Har du brug for en samlet platform med DNS, WAF, bot-beskyttelse, regler og edge-funktioner, giver Cloudflare typisk mere samlet værdi.

CDN og sikkerhed

Ud over hastighed er sikkerhed en central del af moderne CDN-tjenester. Mange tilbyder:

• DDoS-beskyttelse
  Filtrering og absorbering af trafikspidser fra ondsindede kilder, før de når din origin.
• WAF (Web Application Firewall)
  Regler, der kan blokere kendte angrebstyper og mistænkelig trafik på HTTP-niveau.
• Rate limiting
  Begrænsning af, hvor mange forespørgsler en bestemt IP eller klient må sende i sekundet.
• Bot management
  Skelnen mellem søgemaskine-bots, nyttige værktøjer og skadelige scraping-forsøg.

Når CDN’et står som reverse proxy, fungerer det som en mur foran din origin. Rigtigt konfigureret gør det det sværere at angribe din server direkte.

CDN i WordPress og WooCommerce

I WordPress-verdenen er CDN næsten altid koblet til hastighedsoptimering og billedehåndtering.

Typiske komponenter:

• URL-rewriting
  WordPress genererer fx https://ditdomæne.dk/wp-content/uploads/2025/01/billede.jpg. Et plugin eller en funktion omskriver URL’en til https://cdn.ditdomæne.dk/wp-content/uploads/..., så billederne leveres fra CDN’et.
• Purge ved opdateringer
  Når du opdaterer et indlæg, et produkt eller et menupunkt, skal CDN-cache for relevante sider ryddes, så brugerne ikke ser gamle versioner.
• Samspil med cache-plugin
  Plugins, der står for HTML-cache og minificering, skal indstilles, så de ikke kæmper mod CDN’et, men spiller sammen.

Simpelt eksempel: omskrivning til CDN med PHP

I praksis bruger de fleste et plugin, men princippet kan illustreres med en enkel filter-funktion:

add_filter( 'wp_get_attachment_url', function( $url ) {
    $cdn_domain = 'https://cdn.ditdomæne.dk';

    $site_url = get_site_url();
    return str_replace( $site_url, $cdn_domain, $url );
});

Her udskiftes domænet i alle vedhæftede filers URL’er med CDN-domænet. I en rigtig løsning skal man tage højde for multisite, forskellige domæner og undtagelser, men funktionen viser grundideen.

Edge caching, HTML-cache og personalisering

Mange moderne CDN’er tilbyder edge caching af hele HTML-sider, så brugeren rammer en edge-server, der allerede har HTML’en liggende, og får svaret på få millisekunder.

Fordelen er enorm hastighed. Ulempen er, at man skal tænke nøje over:

• Login og cookies
  En cachet side til anonyme brugere bør ikke blandes med en side til loggede brugere.
• Kurv og checkout
  WooCommerce og andre shopsystemer kræver, at kurv og betaling håndteres forsigtigt, så man ikke viser andre brugeres data.
• Geografi og sprog
  Viser man forskelligt indhold baseret på land eller sprog, skal caching-strategien tage højde for det, fx med separate cache-nøgler.

Edge caching er ofte bedst egnet til:

• Artikler og blogindlæg.
• Landingssider.
• Kategori- og listevisninger uden tung personalisering.

Hvornår giver CDN mening - og hvornår ikke?

Scenarier, hvor CDN næsten altid giver mening:

• Du har besøgende fra flere verdensdele.
• Din side er tung på billeder, video og downloads.
• Din server er presset af spidsbelastninger eller kampagner.
• Du vil løfte både hastighed og sikkerhed i ét ekstra lag.

Scenarier, hvor gevinsten er mindre:

• Næsten alle brugere sidder i samme land tæt på datacentret.
• Siden er i forvejen meget let, og der er styr på HTML-cache, browser-cache og billedoptimering.
• Du har begrænset tekniske ressourcer til at sætte CDN rigtigt op og overvåge det.

For mange danske sites giver det ofte mest mening at starte med god hosting, en solid hastighedsoptimering (som i en hurtig-hjemmeside-checkliste) og fornuftig htaccess- og cache-struktur, og derefter lægge CDN ovenpå som ekstra lag.

Sådan tester du om CDN faktisk hjælper

I stedet for at antage at CDN gør alt hurtigere, er det bedre at måle før og efter.

Det giver mening at kigge på:

• TTFB og LCP
  Med værktøjer som PageSpeed Insights, WebPageTest, Lighthouse eller GTmetrix. Test gerne fra flere geografier.
• Før og efter TTL-justering
  Se hvordan længere eller kortere cache-tider på statiske filer påvirker performance.
• Origin-belastning
  Overvåg CPU, RAM og antal requests på din server. Med CDN bør mængden af statiske forespørgsler falde markant.
• Fejl og timeouts
  Brug logfiler og CDN-panelet til at se, om der opstår fejlkoder (fx 502/504), og om de stammer fra CDN eller origin.

Arbejder du systematisk med Core Web Vitals, vil du ofte kunne se et tydeligt hop i målingerne, når CDN’et er sat korrekt op og cachestrategien spiller.

FAQ om Content Delivery Network