Was ist ein CDN? Content Delivery Network einfach erklärt (2026)

Was ist ein CDN? CDN steht für Content Delivery Network, auf Deutsch etwa „Netzwerk zur Auslieferung von Inhalten”. Ein CDN ist ein weltweit verteiltes Netz aus Servern, die Kopien deiner Website-Dateien vorhalten und sie vom Standort aus ausliefern, der dem Besucher am nächsten liegt. Statt dass jede Anfrage aus Sydney, Chicago und Hamburg bis zu deinem einen Server in Nürnberg reisen muss, beantwortet ein Rechenzentrum in der Nähe die Frage aus seinem Zwischenspeicher.

Das klingt nach einem Werkzeug für Netflix und Amazon. Tatsächlich laufen heute große Teile des Webs über CDNs, auch viele kleine Blogs, oft ohne dass der Betreiber genau weiß, was dabei passiert. Genau deshalb wollten wir es für diesen Artikel nicht nur erklären, sondern messen.

Wir betreiben getmind.io auf einem einzelnen Server bei Hetzner in Nürnberg, ohne CDN davor. Am 3. Oktober 2026 haben wir dieselbe Seite von drei Standorten abgerufen (Nürnberg, Helsinki, Ashburn in Virginia) und sie mit drei großen CDNs verglichen. Drei Befunde vorweg:

1. Unser Artikel kommt in Nürnberg nach 43 ms an, in Helsinki nach 88 ms und in Virginia nach 355 ms bis zum ersten Byte (Median aus fünf Abrufen). Eine vergleichbare Datei aus dem Cloudflare-CDN kam in Virginia nach 47 ms.

2. In unseren Logs der letzten acht Tage sprechen nur 3 % der Browser-Besucher Deutsch als erste Sprache. 44 % Englisch, 17 % Chinesisch. Unser „deutscher” Server bedient also überwiegend Leute, die weit weg sitzen.

3. Beim Nachsehen haben wir zwei Dinge in unserer eigenen Konfiguration gefunden, die ein CDN entweder verschlimmert oder versteckt hätte. Dazu unten mehr, ehrlich.

Was ist ein CDN? Die Kurzfassung in fünf Sätzen

1. Deine Website liegt auf einem Ursprungsserver (englisch Origin), irgendwo an einem festen Ort.
2. Ein CDN stellt viele Server an vielen Orten davor, sogenannte Edge-Server oder PoPs (Points of Presence).
3. Der Besucher landet automatisch beim nächstgelegenen Edge-Server, meist per DNS oder Anycast.
4. Hat der Edge-Server die Datei schon im Cache, liefert er sie sofort aus (Cache-Hit). Wenn nicht, holt er sie einmal beim Ursprung ab und merkt sie sich (Cache-Miss).
5. Dadurch werden Seiten schneller, der Ursprungsserver wird entlastet, und Angriffe treffen zuerst das große Netz statt deinen kleinen Server.

Das ist im Kern alles. Der Rest dieses Artikels erklärt, warum das funktioniert, wo die Grenzen sind und wann es sich für dich lohnt.

Video: ADACOR erklärt das Prinzip in zwei Minuten. Das Video ist älter, das Grundprinzip hat sich aber nicht geändert.

Wofür braucht man ein CDN überhaupt? Das Problem heißt Entfernung

Das Internet ist schnell, aber nicht schneller als Licht. In Glasfaser bewegt sich ein Signal mit etwa zwei Dritteln der Lichtgeschwindigkeit, also rund 200.000 Kilometer pro Sekunde. Von Nürnberg nach Virginia sind es grob 7.000 Kilometer Luftlinie, die Kabel laufen aber nicht gerade. Hin und zurück kommen in der Praxis um die 100 Millisekunden zusammen.

Das haben wir nachgemessen. Ein einfacher ping auf unseren Server:

100 Millisekunden klingen harmlos. Das Problem: Beim Aufbau einer HTTPS-Verbindung reicht eine Rundreise nicht. Erst kommt der TCP-Handshake (eine Rundreise), dann der TLS-Handshake (bei TLS 1.3 eine weitere), dann die eigentliche Anfrage (noch eine). Jede Rundreise kostet die volle Strecke.

So sieht das in Zahlen aus. Wir haben unseren DNS-Artikel je fünfmal mit curl abgerufen und die einzelnen Phasen protokolliert (Median):

Man sieht die Rundreisen fast mit bloßem Auge: In Ashburn kostet jede Stufe rund 100 ms mehr. Bevor der Besucher in Virginia überhaupt ein einziges Byte Text sieht, ist eine Drittelsekunde vergangen. Und das ist nur das HTML. Danach folgen Bilder, Schriften, Skripte.

Ein CDN löst genau diesen Teil: Es verkürzt die Strecke. Der TLS-Handshake findet mit einem Server in derselben Stadt statt, nicht mit einem auf einem anderen Kontinent.

CDN gegen eigenen Server: der direkte Vergleich

Um zu sehen, was ein CDN aus derselben Ausgangslage macht, haben wir zusätzlich eine bekannte, öffentlich gehostete Datei geladen: die jQuery-Bibliothek (87 KB), die bei drei großen CDNs liegt. Gemessen jeweils die Zeit bis zum ersten Byte, Median aus fünf Läufen:

Zwei Dinge fallen auf.

Erstens: In Ashburn ist das CDN rund achtmal schneller als unser Server. In Helsinki etwa doppelt so schnell. Das ist der Normalfall, für den CDNs gebaut wurden.

Zweitens: In Nürnberg ist unser eigener Server schneller als jedes CDN. Logisch, wir messen ja vom selben Rechner aus. Aber es gibt noch einen interessanteren Grund: Cloudflare hat unsere Anfrage aus Nürnberg in Paris beantwortet (colo=CDG in der Trace-Ausgabe), nicht in Frankfurt. Ein CDN liefert nicht automatisch vom geografisch nächsten Ort aus, sondern vom netzwerktechnisch nächsten, und welcher das ist, hängt vom Netz deines Providers ab. Von Helsinki aus antwortete Cloudflare aus Helsinki (colo=HEL, Ping 1,6 ms), von Ashburn aus aus Ashburn (colo=IAD, Ping 0,9 ms).

Die ehrliche Zusammenfassung: Ein CDN macht eine Website nicht für alle schneller. Es macht sie für die Fernen schneller und für die Nahen ungefähr gleich. Wer nur Besucher aus derselben Region hat wie sein Server, gewinnt beim Tempo wenig.

Wie funktioniert ein CDN? Schritt für Schritt

Nehmen wir an, du rufst https://beispiel.de/bild.webp auf, und die Seite liegt hinter einem CDN.

1. DNS-Abfrage. Dein Rechner fragt, welche IP-Adresse zu beispiel.de gehört. Statt der Adresse des Ursprungsservers kommt eine Adresse des CDN zurück. (Wie diese Namensauflösung genau abläuft, steht in unserem Artikel Was ist DNS?.)
2. Weg zum nächsten Edge. Dein Paket geht an diese Adresse und landet beim nächstgelegenen Rechenzentrum des CDN. Wie das „nächstgelegen” zustande kommt, erklären wir gleich unter Anycast.
3. TLS beim Edge. Die verschlüsselte Verbindung wird mit dem Edge-Server aufgebaut, nicht mit dem Ursprung. Deshalb braucht das CDN ein gültiges Zertifikat für deine Domain.
4. Cache-Prüfung. Der Edge-Server schaut nach, ob er bild.webp schon hat und ob die Kopie noch gültig ist.
5. Hit oder Miss. Bei einem Hit kommt die Datei sofort zurück. Bei einem Miss fragt der Edge den Ursprungsserver (oft über eine schnelle, dauerhaft offene Verbindung), speichert die Antwort und gibt sie weiter.
6. Der nächste Besucher in derselben Region bekommt die Datei direkt aus dem Cache. Der Ursprungsserver merkt davon nichts.

Technisch ist ein CDN damit ein großer, verteilter Reverse Proxy mit Cache. Er steht vor deinem Server, nimmt Anfragen entgegen und beantwortet so viele wie möglich selbst. Den Unterschied zwischen Reverse Proxy, Load Balancer und CDN haben wir ausführlich in Was ist ein Reverse Proxy? auseinandergenommen.

Woran du erkennst, ob eine Seite über ein CDN läuft

Die meisten CDNs verraten sich in den HTTP-Antwortköpfen. Mit curl -sI URL siehst du sie. Bei unseren Testdateien sah das so aus:

# cdnjs.cloudflare.com
server: cloudflare
cf-cache-status: BYPASS
cf-ray: a44a14505c58d5c0-CDG

# cdn.jsdelivr.net
x-served-by: cache-fra-etou8220050-FRA
x-cache: HIT
age: 271804

# getmind.io
server: Caddy
cache-control: no-cache

• cf-ray endet bei Cloudflare mit dem Flughafen-Code des Rechenzentrums (CDG = Paris, HEL = Helsinki, IAD = Washington).
• x-cache: HIT heißt: kam aus dem Cache. age: 271804 heißt: diese Kopie liegt seit gut drei Tagen dort.
• Bei code.jquery.com aus den USA stand x-cache: HIT, HIT mit zwei Rechenzentren (LGA und IAD). Das ist ein gestufter Cache: Ein regionaler Knoten fragt erst einen größeren Knoten, bevor er zum Ursprung geht.
• Bei uns: server: Caddy, sonst nichts. Kein CDN davor.

Anycast: wie eine IP-Adresse an 300 Orten gleichzeitig wohnt

Hier wird es spannend, und hier liegt der Teil, den die meisten Erklärungen auslassen. Wir haben die Adresse von cdnjs.cloudflare.com von unseren drei Standorten aus abgefragt:

Nürnberg:  104.17.24.14  104.17.25.14
Helsinki:  104.17.25.14  104.17.24.14
Ashburn:   104.17.24.14  104.17.25.14

Überall dieselbe IP-Adresse. Und trotzdem antworteten drei verschiedene Rechenzentren, mit Ping-Zeiten von 14 ms, 1,6 ms und 0,9 ms. Wie kann eine Adresse an drei Orten gleichzeitig sein?

Das ist Anycast. Normalerweise gehört eine IP-Adresse zu genau einem Ort (das nennt man Unicast). Bei Anycast kündigen viele Rechenzentren im Internet-Routing (über BGP) dieselbe Adresse an. Jeder Router auf dem Weg schickt das Paket dann einfach zum Ziel, das aus seiner Sicht am kürzesten erreichbar ist. Der Besucher landet so automatisch beim nächsten Standort, ohne dass irgendjemand eine Entscheidung treffen muss.

Bei jsDelivr sahen wir übrigens etwas anderes: unterschiedliche Adressen je Standort. In Nürnberg und Helsinki kamen Adressen aus dem Netz von Fastly (151.101.x.x), in Ashburn Adressen von Cloudflare (104.17.x.x). jsDelivr ist ein Multi-CDN: Ein Nameserver entscheidet je nach Herkunft der Anfrage, welcher von mehreren CDN-Anbietern dich bedient. Das ist die zweite Methode, DNS-basiertes Routing, und sie lässt sich mit Anycast kombinieren. Die Header aus Nürnberg zeigten das sogar doppelt: server: cloudflare und ein Fastly-Knoten in x-served-by.

Anycast hat einen schönen Nebeneffekt für die Sicherheit: Ein Angriff mit Millionen Paketen verteilt sich automatisch auf alle Standorte, weil jeder Angreifer beim jeweils nächsten Rechenzentrum landet. Kein einzelner Server muss die ganze Last tragen.

Was ein CDN zwischenspeichert, und was nicht

Ein häufiges Missverständnis: „Mit CDN liegt meine ganze Website auf 300 Servern.” Meistens stimmt das nicht. Was ein CDN zwischenspeichert, bestimmen zwei Dinge: die Standardregeln des Anbieters und die Cache-Control-Header, die dein Server mitschickt.

Typischerweise gecacht (statische Inhalte):

• Bilder (WebP, AVIF, JPEG, PNG, SVG)
• CSS und JavaScript
• Schriften
• Videos und Downloads

Typischerweise nicht gecacht (dynamische Inhalte):

• HTML-Seiten (bei vielen Anbietern standardmäßig nicht, weil sie personalisiert sein könnten)
• Alles mit Cookies, Logins, Warenkörben
• API-Antworten
• POST-Anfragen

Cloudflare zum Beispiel cacht HTML im Standard nicht. Das sieht man auch oben: cf-cache-status: BYPASS. Bei der jQuery-Datei auf cdnjs ist das egal, bei einer Website heißt es aber: Ohne zusätzliche Regeln geht jede Seitenanfrage weiterhin bis zu deinem Server. Nur Bilder und Skripte kommen aus der Nähe.

Cache-Control: die Anweisung, die du selbst gibst

So sehen die Regeln aus, die unser Caddy-Webserver für getmind.io verschickt:

HTML-Seiten:      cache-control: no-cache
Bilder (.webp):   cache-control: public, max-age=86400, stale-while-revalidate=604800
Build-Dateien:    cache-control: public, max-age=31536000, immutable

Übersetzt:

• no-cache heißt nicht „nie speichern”, sondern „vor jeder Nutzung beim Server nachfragen, ob es noch aktuell ist”. Ideal für HTML, das sich bei uns täglich ändert.
• max-age=86400 heißt: einen Tag lang ohne Nachfrage benutzen. stale-while-revalidate=604800: danach noch bis zu sieben Tage die alte Kopie ausliefern, während im Hintergrund eine neue geholt wird.
• immutable mit einem Jahr: Diese Datei ändert sich nie. Funktioniert, weil der Dateiname einen Hash enthält. Neue Version, neuer Name.

Ein CDN liest diese Header und hält sich daran. Das ist der wichtigste Satz für jeden, der ein CDN einrichtet: Das CDN ist nur so gut wie die Cache-Header deines Servers. Falsche Header werden durch ein CDN nicht repariert, sondern weltweit verteilt.

Was wir in unserer eigenen Konfiguration gefunden haben

Wir wollten wissen, was passieren würde, wenn wir morgen ein CDN vor getmind.io schalten. Also haben wir uns die Antworten und die Logs genauer angesehen. Zwei Funde.

Fund 1: Eine 404-Seite mit Jahres-Garantie

Unsere Regel „Build-Dateien ein Jahr lang immutable” hängt am Pfad /_astro/*. Wir haben eine Datei abgefragt, die es dort nicht gibt:

$ curl -sI https://getmind.io/_astro/gibtesnicht.css
HTTP/2 404
cache-control: public, max-age=31536000, immutable

Die Fehlerseite bekommt die Anweisung „ein Jahr lang unveränderlich”. Ohne CDN ist das fast harmlos, es betrifft nur den einen Browser, der die falsche Adresse aufgerufen hat. Mit CDN wäre es ein klassisches Problem: Fragt jemand eine Datei ab, bevor sie fertig hochgeladen ist (etwa während eines Deploys), speichert das CDN den 404 für ein Jahr an diesem Standort. Alle Besucher dort bekämen danach eine kaputte Seite, bis jemand manuell den Cache leert.

Die Regel dafür ist einfach: Lange Cache-Zeiten nur für Antworten mit Status 200. Viele CDNs cachen Fehler standardmäßig nur kurz, darauf verlassen sollte man sich aber nicht. Wir haben das noch nicht geändert und notieren es offen. Da im Moment kein CDN davorsteht, ist es kein akutes Risiko.

Fund 2: 64 % unseres Datenverkehrs sind Fehlerseiten für Bots

Wir haben die Zugriffslogs von getmind.io vom 25. September bis 3. Oktober 2026 ausgewertet, rund acht Tage, 42.116 Anfragen:

Fast zwei Drittel aller ausgelieferten Bytes sind Fehlerseiten. Wer fragt da so beharrlich nach Dingen, die es nicht gibt? Die Top-Pfade sprechen für sich: /.env (196-mal), /graphql (191), /.env.local (139), Pfade mit %2e%2e%2f (das ist ../, ein Versuch, aus dem Webverzeichnis auszubrechen), dazu hunderte Abfragen nach alten WordPress-Uploads und Seiten, die nie auf dieser Domain existiert haben. Das sind Scanner, die das ganze Internet nach versehentlich veröffentlichten Passwortdateien und Lücken absuchen.

Das Ärgerliche daran: Unsere 404-Seite wiegt 29,7 KB und wird unkomprimiert ausgeliefert, obwohl der Browser gzip anbietet. Komprimiert wären es 7,2 KB. Der Grund ist ein Detail in unserer Caddy-Konfiguration: Die Fehlerbehandlung (handle_errors) läuft an der Komprimierung vorbei. Grob überschlagen (wenn man annimmt, dass praktisch alle 404-Antworten diese Seite sind) wären komprimiert statt 744 MB nur etwa 180 MB geflossen. Rund 560 MB in acht Tagen gehen also für unkomprimierte Fehlerseiten an Bots drauf.

Was hat das mit CDNs zu tun? Ein CDN würde diese Last verstecken. Die Bots würden beim CDN abprallen, unser Server würde ruhiger, und wir hätten das Problem nie bemerkt. Das ist bequem, aber eben auch ein Nachteil: Ein CDN macht Symptome unsichtbar, die man eigentlich an der Wurzel beheben sollte. Auch das haben wir noch nicht angefasst, es steht auf der Liste.

Zum Vergleich: Laut unseren Logs sind von den echten Seitenaufrufen ohnehin 51 % Bots (Suchmaschinen, KI-Crawler, Skripte). Welche KI-Crawler genau, haben wir in der KI-Crawler-Logfile-Analyse aufgeschlüsselt.

Warum getmind.io (noch) kein CDN nutzt

Das klingt erst mal widersprüchlich: Wir zeigen, dass ein CDN in den USA achtmal schneller wäre, und nutzen keins. Die Gründe:

1. Die Domain liegt schon bei Cloudflare, nur ohne Proxy. Unsere Nameserver sind laura.ns.cloudflare.com und augustus.ns.cloudflare.com. Cloudflare macht für uns also schon das DNS. Der Eintrag für getmind.io zeigt aber direkt auf unsere Server-IP (im Cloudflare-Dashboard heißt das „DNS only”, die graue Wolke). Ein CDN wäre bei uns technisch ein Klick. Dass wir ihn nicht gemacht haben, war bisher keine bewusste Entscheidung, sondern Bequemlichkeit, und dieser Artikel ist der Anlass, sie bewusst zu treffen.

2. Unser Traffic ist klein. In acht Tagen haben wir 1,16 GB ausgeliefert, hochgerechnet etwa 4,4 GB im Monat. Das schafft jeder kleine Server, ohne sich anzustrengen.

3. Wir nutzen die Logs. Für unsere Auswertungen (wie oben) brauchen wir die echten Besucher-IPs und User-Agents in unseren eigenen Logs. Hinter einem CDN kommen die Anfragen von CDN-Adressen, die echte IP steht nur noch in einem Header (CF-Connecting-IP oder X-Forwarded-For). Das lässt sich lösen, ist aber Arbeit, und Tools wie fail2ban müssen dann ebenfalls umgestellt werden.

4. Datenschutz. Ein CDN sieht jeden Seitenaufruf, inklusive IP-Adresse. Bei einem US-Anbieter heißt das: Auftragsverarbeitung, Datenschutzerklärung anpassen, Drittlandtransfer prüfen. Für ein deutsches Unternehmen ist das lösbar, aber nicht null.

Was dafür spricht: Die 3 % deutschsprachigen Browser-Besucher in unseren Logs. Wenn 97 % unserer Leser woanders sitzen, ist „unser Server steht in Nürnberg, das reicht” ein schwaches Argument. Besonders für Besucher aus Asien (17 % mit chinesischer Spracheinstellung) dürfte der Abstand noch größer sein als die 340 ms aus Virginia, das haben wir allerdings nicht gemessen.

Unsere ehrliche Einschätzung: Für getmind.io ist ein CDN nett, aber nicht nötig. Zuerst würden wir die beiden Funde oben beheben, dann ein CDN nur für Bilder testen, und das Ergebnis messen.

Die Vorteile eines CDN im Überblick

• Schnellere Ladezeiten für ferne Besucher. Unser Messwert in den USA: 355 ms TTFB vom eigenen Server, rund 47 ms aus dem CDN.
• Entlastung des Ursprungsservers. Jeder Cache-Hit ist eine Anfrage, die dein Server nie sieht.
• Schutz vor DDoS-Angriffen. Das CDN-Netz ist um Größenordnungen größer als dein Server, und Anycast verteilt Angriffe auf alle Standorte.
• Verfügbarkeit. Manche CDNs liefern eine gecachte Version aus, wenn dein Server kurz ausfällt (bei Cloudflare heißt das „Always Online”, generisch stale-if-error).
• Geringere Bandbreitenkosten, falls dein Hoster Traffic abrechnet.
• Zusatzfunktionen: automatische Bildoptimierung, HTTP/3, Bot-Filter, Web Application Firewall, Edge-Funktionen.

Die Nachteile, über die selten jemand redet

• Ein zusätzlicher Ausfallpunkt. Wenn ein großes CDN ausfällt, fallen tausende Websites gleichzeitig aus, auch solche, deren eigene Server einwandfrei laufen. Das ist mehrfach passiert, bei verschiedenen Anbietern.
• Cache-Probleme. „Ich habe die Seite geändert, aber ich sehe die alte Version.” Das häufigste Support-Thema bei CDNs. Ursache sind fast immer zu lange Cache-Zeiten oder falsche Header (siehe Fund 1).
• Datenschutz (siehe oben).
• Die echte Besucher-IP fehlt in deinen Logs, wenn du sie nicht explizit aus dem Header übernimmst.
• Abhängigkeit. Je mehr Funktionen du beim CDN nutzt (Regeln, Workers, Firewall), desto schwerer wird ein Wechsel.
• Kaum Gewinn bei lokalem Publikum. Unser Messwert aus Nürnberg: Der eigene Server war schneller als alle drei CDNs.

Welche CDN-Anbieter gibt es?

Ein grober Überblick über bekannte Anbieter, ohne Anspruch auf Vollständigkeit. Preise ändern sich, daher stets beim Anbieter selbst nachsehen.

Zum Einordnen: Unsere hochgerechneten 4,4 GB pro Monat würden bei Bunny rund 4 Cent kosten. Es gilt dann der Mindestumsatz von 1 Dollar. Bandbreite ist für kleine Websites also kein Kostenfaktor mehr, eher die Zeit für die Einrichtung.

Wer seine Website auf Plattformen wie Vercel, Netlify oder Cloudflare Pages hostet, hat übrigens automatisch ein CDN dabei, das ist Teil des Produkts. Mehr dazu in unserem Artikel über Vercel-Alternativen.

Video: mso digital erklärt, wie ein CDN funktioniert und ob man überhaupt eins braucht. Die Agentur bewirbt am Ende eigene Dienstleistungen.

Brauche ich ein CDN? Eine ehrliche Checkliste

Ein CDN lohnt sich eher, wenn …

• deine Besucher über mehrere Kontinente verteilt sind (Logs prüfen, nicht raten: Accept-Language und IP-Herkunft geben gute Hinweise),
• du viele große Dateien auslieferst (Bilder, Videos, Downloads),
• dein Server schwach ist oder Traffic-Spitzen nicht verkraftet,
• du ein lohnendes Ziel für DDoS-Angriffe bist (Shops, Spiele, politische Themen),
• dein Hoster Traffic teuer abrechnet.

Ein CDN bringt eher wenig, wenn …

• dein Publikum in derselben Region wie dein Server sitzt (eine Bäckerei in Bielefeld mit Server in Nürnberg),
• deine Seiten fast nur dynamisch sind (eingeloggte Nutzer, personalisierte Inhalte), sodass kaum etwas gecacht werden kann,
• du die Logs mit echten IPs brauchst und keine Zeit für die Umstellung hast,
• Datenschutz-Auflagen einen weiteren Dienstleister schwierig machen.

Ein Mittelweg, den wir selbst als nächsten Schritt sehen: CDN nur für Bilder und statische Dateien über eine eigene Subdomain (z. B. static.beispiel.de). HTML kommt weiter direkt vom eigenen Server, die schweren Dateien aus der Nähe. Bei uns machen Bilder 44 % der erfolgreich ausgelieferten Bytes aus.

Ein CDN einrichten: der typische Ablauf

Die Details hängen vom Anbieter ab, das Muster ist aber fast immer gleich:

1. Cache-Header prüfen, bevor irgendwas umgestellt wird: curl -sI https://deine-domain.de/bild.webp. Haben Bilder, CSS und JS sinnvolle max-age-Werte? Bekommen Fehlerseiten keine langen Cache-Zeiten?
2. Konto beim Anbieter anlegen und deine Domain bzw. den Ursprungsserver eintragen.
3. DNS umstellen. Entweder du gibst dem CDN die Nameserver deiner Domain (bei Cloudflare üblich), oder du legst einen CNAME-Eintrag an, der auf das CDN zeigt (bei Bunny und vielen anderen üblich).
4. TLS-Zertifikat für deine Domain beim CDN einrichten. Die meisten erledigen das automatisch per Let’s Encrypt.
5. Echte Besucher-IP in deinem Webserver aus dem Header übernehmen (CF-Connecting-IP, X-Forwarded-For) und nur Anfragen von CDN-Adressen vertrauen. Sonst sehen deine Logs, deine Rate Limits und dein fail2ban nur noch das CDN.
6. Ursprung absichern. Idealerweise ist dein Server nur noch für das CDN erreichbar, sonst können Angreifer das CDN einfach umgehen, indem sie deine echte IP direkt ansprechen. Diese IP lässt sich übrigens oft über alte DNS-Einträge herausfinden.
7. Messen. Vorher und nachher von mehreren Standorten aus, mit curl -w, so wie oben. Nicht nur einmal, sondern mehrmals, und mit Blick auf Cache-Hits (x-cache, cf-cache-status).
8. Cache leeren lernen. Jedes CDN hat einen Weg, Dateien sofort aus dem Cache zu werfen („Purge”). Den solltest du kennen, bevor du ihn im Notfall brauchst.

So misst du selbst die Phasen einer Anfrage, wie wir es für diesen Artikel getan haben:

curl -s --compressed -o /dev/null \
  -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  https://deine-domain.de/

Was wir nicht gemessen haben

Damit niemand mehr aus den Zahlen liest, als drinsteht:

• Nur drei Standorte, alle in Rechenzentren mit sehr guter Anbindung. Ein Smartphone im Mobilfunknetz in Jakarta sieht ganz andere Zahlen.
• Asien, Südamerika, Afrika haben wir nicht gemessen, obwohl 17 % unserer Browser-Besucher Chinesisch als Sprache angeben.
• Die CDN-Vergleichswerte stammen von fremden, sehr populären Dateien (jQuery). Die sind in fast jedem Edge-Cache vorhanden. Eine selten abgerufene Datei auf deiner eigenen Website hätte öfter einen Cache-Miss und wäre entsprechend langsamer.
• Die Sprachverteilung basiert auf dem Accept-Language-Header von 3.961 Seitenaufrufen ohne erkennbaren Bot-User-Agent. 35 % schickten gar keine Sprache mit, das sind vermutlich ebenfalls Bots.
• Ladezeit ist nicht gleich Nutzererlebnis. Für Google zählen die Core Web Vitals (z. B. LCP), und die hängen auch an Bildgrößen, Schriften und JavaScript, nicht nur an der Netzwerkstrecke.

Häufige Fragen

Was ist ein CDN einfach erklärt?

Ein CDN (Content Delivery Network) ist ein Netz aus vielen Servern auf der ganzen Welt, die Kopien deiner Website-Dateien bereithalten. Besucher bekommen die Dateien vom nächstgelegenen Server statt vom weit entfernten Ursprungsserver. Dadurch lädt die Seite schneller, und dein eigener Server wird entlastet.

Wofür steht CDN?

CDN steht für Content Delivery Network, manchmal auch Content Distribution Network. Auf Deutsch heißt das so viel wie „Inhalte-Auslieferungsnetzwerk”.

Was macht ein CDN genau?

Es nimmt Anfragen an deine Website entgegen, beantwortet sie nach Möglichkeit aus seinem Zwischenspeicher (Cache) und fragt nur bei Bedarf deinen Server. Dazu kommen oft Zusatzfunktionen wie TLS-Verschlüsselung, Komprimierung, Bildoptimierung und Schutz vor Angriffen.

Ist Cloudflare ein CDN?

Ja. Cloudflare ist einer der bekanntesten CDN-Anbieter und bietet einen kostenlosen Plan an. Cloudflare ist aber mehr als ein CDN, es macht auch DNS, DDoS-Schutz, Firewall, Zero-Trust-Zugänge und Edge-Funktionen. Wichtig: Nutzt du Cloudflare nur als DNS-Anbieter (graue Wolke), läuft dein Traffic nicht über das CDN. So ist es aktuell bei getmind.io.

Brauche ich ein CDN für meine Website?

Nicht zwingend. Sitzen deine Besucher überwiegend in derselben Region wie dein Server, ist der Tempogewinn klein, bei uns in Nürnberg war der eigene Server sogar schneller. Sinnvoll wird ein CDN bei internationalem Publikum, vielen großen Dateien, schwachen Servern oder erhöhtem Angriffsrisiko.

Ist ein CDN kostenlos?

Es gibt kostenlose Angebote, allen voran den Free-Plan von Cloudflare. Bezahlte Anbieter wie Bunny.net rechnen nach Datenmenge ab, in Europa ab etwa einem Cent pro Gigabyte. Für kleine Websites sind die Kosten damit meist vernachlässigbar.

Macht ein CDN meine Website schneller?

Für weit entfernte Besucher meistens deutlich: In unserer Messung brauchte unser Server ohne CDN in den USA 355 ms bis zum ersten Byte, eine vergleichbare Datei aus dem Cloudflare-CDN rund 47 ms. Für Besucher in der Nähe deines Servers kaum, und bei einem Cache-Miss kann ein CDN sogar minimal langsamer sein, weil ein zusätzlicher Zwischenschritt dazukommt.

Ist ein CDN DSGVO-konform?

Kann es sein, aber nicht automatisch. Das CDN verarbeitet die IP-Adressen deiner Besucher, du brauchst also in der Regel einen Auftragsverarbeitungsvertrag und einen Hinweis in der Datenschutzerklärung. Bei Anbietern außerhalb der EU kommt die Frage des Drittlandtransfers dazu. Im Zweifel juristisch beraten lassen.

Was ist der Unterschied zwischen CDN und Hosting?

Das Hosting ist der Ort, an dem deine Website wirklich liegt und erzeugt wird (der Ursprungsserver). Ein CDN ersetzt das Hosting nicht, es steht davor und verteilt Kopien. Ohne Hosting kein CDN. Eine Ausnahme sind rein statische Seiten auf Plattformen, die beides in einem Produkt anbieten.

Was ist der Unterschied zwischen CDN und Reverse Proxy?

Ein CDN ist technisch ein weltweit verteilter Reverse Proxy mit Cache. Ein einzelner Reverse Proxy (wie Nginx oder Caddy) steht an einem Ort vor deiner Anwendung, ein CDN an hunderten Orten. Details im Artikel Was ist ein Reverse Proxy?.

Was bedeutet Cache-Hit und Cache-Miss?

Ein Cache-Hit heißt: Der Edge-Server hatte die angefragte Datei schon gespeichert und hat sie direkt ausgeliefert. Ein Cache-Miss heißt: Er hatte sie nicht und musste sie erst beim Ursprungsserver abholen. Je höher die Trefferquote (Hit Ratio), desto mehr bringt das CDN.

Wie prüfe ich, ob eine Website ein CDN nutzt?

Mit curl -sI https://domain.de die Antwortköpfe ansehen. Hinweise sind Header wie server: cloudflare, cf-ray, x-cache, x-served-by, via oder age. Alternativ die IP-Adresse der Domain nachschlagen und prüfen, welchem Netz sie gehört.

Fazit: Ein CDN verkürzt Wege, es repariert nichts

Ein CDN ist im Kern eine einfache Idee: Kopien deiner Dateien dorthin legen, wo deine Besucher sind. Die Messung zeigt, wie viel das bringen kann. In den USA kam unsere Seite ohne CDN nach 355 ms an, das CDN-Gegenstück nach 47 ms. Sie zeigt aber auch die andere Seite: In der Nähe des eigenen Servers bringt ein CDN nichts, und es versteckt Probleme, statt sie zu lösen.

Für uns heißt das konkret: Erst die eigenen Hausaufgaben (keine langen Cache-Zeiten für Fehlerseiten, komprimierte 404-Seiten), dann ein CDN für Bilder testen, und dann neu messen. Wenn du selbst überlegst, beginne genau so: Schau in deine Logs, woher deine Besucher kommen, prüfe deine Cache-Header, und miss vorher und nachher.

Wenn du tiefer in die Grundlagen willst: Wie der Weg vom Domainnamen zur IP-Adresse funktioniert, steht in Was ist DNS?, und wie du einen eigenen Server sauber aufsetzt, in Linux-Server einrichten.