Was ist ein CDN (Content Delivery Network)? So funktioniert es

Was ist ein CDN (Content Delivery Network)?

Ein Content Delivery Network (CDN) ist eine Gruppe von Servern an vielen Standorten, die Kopien Ihrer Inhalte speichern und jede Anfrage vom Standort beantworten, der dem Besucher am nächsten liegt. Das verkürzt den Weg der Daten, entlastet Ihren eigenen Server und hält beliebte Inhalte auch bei Lastspitzen verfügbar.

Ihr eigener Server bleibt die maßgebliche Quelle und heißt Ursprungsserver (Origin). Die CDN-Server davor heißen Edge-Server. MDN beschreibt das Prinzip genauso: Kopien der Daten, ausgeliefert von den Servern, die dem jeweiligen Nutzer am nächsten sind.

So funktioniert ein CDN

1. Der Browser fordert eine URL an Ihrer Domain, und DNS verweist ihn auf einen CDN-Edge-Server in der Nähe des Besuchers.
2. Der Edge-Server prüft seinen Cache. Bei einem Treffer (Hit) antwortet er sofort. Bei einem Fehlschlag (Miss) holt er die Datei vom Ursprungsserver oder aus einem übergeordneten Cache, speichert eine Kopie und antwortet dann.
3. Spätere Besucher in dieser Region bekommen die gespeicherte Kopie, bis sie abläuft (TTL) oder Sie sie löschen (Purge).

Der Anteil der Anfragen, die aus dem Cache kommen, ist die Cache-Trefferquote (Cache Hit Ratio). Sie zeigt, ob das CDN seine Aufgabe erfüllt. Dasselbe Prinzip gilt eine Ebene tiefer beim API-Caching.

Was gecacht wird und was nicht

Der Response-Header Cache-Control legt fest, was das CDN speichern darf und wie lange.

Vorsicht bei den Namen: no-cache heißt nicht "nicht speichern", sondern "vor der Wiederverwendung beim Ursprungsserver nachfragen". Das Speichern unterbindet no-store. Alle Direktiven stehen in der MDN-Referenz zu Cache-Control.

Warum ein CDN nutzen

• Geringere Latenz. Die Entfernung wirkt sich auf die Latenz aus, und ein naher Edge-Server ist für die meisten Nutzer näher als Ihr Ursprungsserver. Zuerst verbessert sich dabei die Time to First Byte.
• Weniger Last auf dem Ursprungsserver. Jede am Edge beantwortete Anfrage sehen Ihre eigenen Server nie. So kommen Sie bei gleichem Traffic mit kleinerer Infrastruktur aus.
• Lastspitzen. Gecachte Inhalte werden weiter ausgeliefert, während Ihr Ursprungsserver sonst Anfragen aufstauen würde.
• Ausfallsicherheit. Hat ein Edge-Standort Probleme, können Anfragen an einen anderen geleitet werden. Gecachte Kopien können weiter antworten, solange der Ursprungsserver langsam ist.
• Schutz und Extras. Viele Anbieter beenden TLS, komprimieren Antworten und filtern missbräuchlichen Traffic am Edge. Das hilft gegen Floods (siehe DDoS-Angriffe abwehren), ersetzt aber keine Rate Limits auf Ihrem eigenen Ursprungsserver.

Häufige CDN-Fehler

• Veraltete Dateien nach einem Deploy. Geben Sie statischen Dateien einen Hash im Namen, sodass ein neues Release eine neue URL bedeutet, und löschen Sie nur die wenigen URLs, deren Name gleich bleiben muss, etwa HTML. Mehr dazu in unserem Beitrag zu Cache-Invalidierung und Performance-Tests (auf Englisch).
• Personalisierte Antworten cachen. Fehlt private bei einer nutzerspezifischen Antwort, kann ein geteilter Cache sie an einen anderen Nutzer ausliefern. Genau davor warnt MDN.
• Ein zu spezifischer Cache-Schlüssel. Gehören Cookies oder zufällige Query-Parameter zum Schlüssel, speichert das CDN pro Variante eine Kopie, und die Trefferquote bricht ein. Entfernen Sie alles, was die Antwort nicht verändert.
• Cache Stampede. Läuft ein beliebtes Objekt ab, fragen viele Edge-Server gleichzeitig beim Ursprungsserver nach. stale-while-revalidate oder eine Origin-Shield-Ebene fängt das ab.
• Annehmen, ein CDN sei immer schneller. MDN weist darauf hin, dass ein Drittanbieter-Host eigene DNS-Abfragen und Verbindungen mitbringt. Sitzt Ihr Publikum direkt neben dem Ursprungsserver, ist der Gewinn eventuell klein. Messen Sie nach.
• Nie einen Cache-Miss testen. Nach einem Purge oder Deploy muss der Ursprungsserver eine Weile die volle Last tragen.

CDN und Edge Computing

Ein CDN speichert und liefert Inhalte aus. Edge Computing führt Ihren Code an denselben Standorten aus, zum Beispiel um eine Anfrage umzuschreiben oder eine Antwort nah am Nutzer zu personalisieren. Viele Anbieter bieten beides, aber nur das Erste ist ein CDN im klassischen Sinn.

CDN testen und überwachen

• Response-Header lesen. Der Header Age zeigt, wie lange das Objekt in einem Proxy-Cache lag. Ein Wert von 0 bedeutet meist, dass es vom Ursprungsserver kam. Die meisten Anbieter setzen zusätzlich einen eigenen Cache-Status-Header. Das kostenlose Tool curl Online sendet dieselbe Anfrage aus sechs AWS-Regionen und zeigt Status, Header und Timing, sodass Sie Edge-Standorte vergleichen können.
• Geschwindigkeit nach Region beobachten. Das Page-Speed-Monitoring führt geplante Lighthouse-Audits aus 25 Cloud-Regionen aus und zeigt, ob das CDN überall hilft oder nur in der Nähe Ihres Ursprungsservers. Verfolgen Sie es zusammen mit den Core Web Vitals.
• Über den Cache hinaus testen. Ein Lasttest gegen eine gecachte URL misst vor allem das CDN. Testen Sie zusätzlich mit Cache-Busting-Anfragen, um zu sehen, was Ihr Ursprungsserver bei kaltem Cache tut. Unser Beitrag zu Edge-Standorten im Cloud-Testing (englisch) erklärt, warum der Teststandort zählt.

Häufige Fragen: CDN

Brauche ich ein CDN für eine kleine Website?

Wenn fast alle Besucher in einer Region nahe Ihrem Server sitzen, ist der Gewinn klein. Sind Ihre Besucher weltweit verteilt oder wollen Sie einen Puffer für Lastspitzen, lohnt sich ein CDN. Viele Anbieter haben einen kostenlosen oder günstigen Einstieg.

Kann ein CDN API-Antworten cachen?

Ja, mit Bedacht. Lesende GET-Antworten, die für alle Nutzer gleich sind, lassen sich gut cachen. Persönliche Daten wie GET /me müssen als private oder no-store markiert sein. Setzen Sie Cache-Control und Vary gezielt ein.

Wie leere ich den Cache nach einem Deploy?

Verwenden Sie versionierte oder gehashte Dateinamen für statische Dateien, dann bekommt jedes Release eine neue URL und nichts muss geleert werden. Für URLs mit gleichbleibendem Namen, etwa HTML-Seiten, rufen Sie nach dem Deploy die Purge-API Ihres Anbieters auf.

Woran erkenne ich, dass eine Antwort aus dem CDN-Cache kam?

Schauen Sie in die Response-Header. Ein Age-Header ungleich 0 bedeutet, dass das Objekt aus einem Proxy-Cache kam, und die meisten CDNs setzen einen eigenen Header, der Hit oder Miss anzeigt. Wiederholen Sie die Anfrage und vergleichen Sie.

Schützt ein CDN vor DDoS-Angriffen?

Es hilft, weil Floods am Edge abgefangen werden, bevor sie Ihren Ursprungsserver erreichen. Rate Limiting, eine Web Application Firewall und ein Plan für Angriffe auf Anwendungsebene gegen dynamische Endpunkte ersetzt es nicht.

Beeinflusst ein CDN die Suchmaschinenoptimierung?

Indirekt. Schnelleres Laden kann die Core Web Vitals verbessern, die Google für die Suche empfiehlt. Ein falsch konfigurierter Cache kann aber auch veraltete Titel und Meta-Tags ausliefern oder Crawler aussperren. Prüfen Sie, was das CDN an Googlebot zurückgibt.