Entscheiden Sie, was das CDN ausliefern soll
Beginnen Sie mit einer Inventarisierung. Trennen Sie versionierte Assets wie Bilder, Stylesheets, Skripte, Fonts und Downloads von HTML, APIs, Konto‑Seiten, Checkout und Administration. CDNs befüllen Caches häufig on‑demand: Die erste Anfrage kann das Origin erreichen, während spätere passende Anfragen am Edge bedient werden. Ein nahegelegener Edge und ein Cache‑Hit sind unterschiedliche Vorteile.
Notieren Sie Host, Applikation, Storage‑Bucket oder Load Balancer, der jeden Pfad liefert; er muss bei einem Cache‑Miss antworten.
Beginnen Sie mit Assets, die für alle Besucher identisch sind und sicher bis zum angegebenen Lebenszeitende verfügbar bleiben können.
Teilen Sie keine personalisierten Dashboards, sessions‑gebundene Seiten oder Kundendaten, außer ein qualifizierter Ingenieur hat Trennung entworfen und getestet.
Legende die Cache‑Policy am Verhalten des Inhalts aus
HTTP‑Antwortheader drücken das Cache‑Verhalten aus. Cache‑Control sagt, ob eine Antwort gespeichert werden darf und wie lange sie frisch bleibt; eine Time to Live (TTL) ist dieser Frischhaltezeitraum. Ein Browser ist ein privater Cache, während ein CDN üblicherweise geteilt ist. Verwenden Sie explizite Header. Der HTTP‑Standard erlaubt s‑maxage, um eine Shared‑Cache‑Lebensdauer separat von max‑age zu setzen.
Veröffentlichen Sie beim Ändern des Inhalts eine neue URL, etwa mit einem content‑hash im Dateinamen, und geben Sie der unveränderlichen Version eine lange, dokumentierte Lebensdauer.
Wählen Sie eine kurze Lebensdauer oder Validierungsverhalten basierend auf den Kosten veralteter Inhalte; verwenden Sie nicht dieselbe Asset‑Regel für Preise, Inventar oder Kontostand.
Verwenden Sie private für Antworten, die für eine einzelne Nutzerin/einen einzelnen Nutzer bestimmt sind. Ein Cookie allein macht eine Antwort nicht sicher für einen geteilten Cache.
Machen Sie Invalidierung zur Ausnahme, nicht zum Release‑Plan
Invalidierung, oder Purge, weist ein gemanagtes CDN an, ausgewählte gespeicherte Objekte vor Ablauf zu verwerfen. Nutzen Sie sie für Korrekturen, nicht für jedes Deployment. Bestätigen Sie, dass das Origin bereits die Ersatzantwort zurückgibt, bevor Sie purgen; sonst kann ein Refill die fehlerhafte Antwort bewahren. Browser‑Caches liegen außerhalb der Purge‑Kontrolle des CDN, daher bleibt URL‑Versionierung verlässlich für sich ändernde Dateien.
Bevorzugen Sie einen spezifischen Pfad, eine Release‑Gruppe oder vom Anbieter unterstützte Cache‑Tags gegenüber einem Site‑weiten Purge; breite Misses können plötzlich das Origin belasten.
Ein verteilter Purge erreicht möglicherweise nicht jeden Edge gleichzeitig. Prüfen Sie die Abschlusssemantik des Anbieters und testen Sie eine repräsentative URL.
Dokumentieren Sie die alte und neue URL, die Cache‑Regel, den Purge‑Umfang, das erwartete Ergebnis und den Rücksetzschritt.
Halten Sie das Origin hinter der Auslieferungsschicht
Direkter Origin‑Zugriff kann CDN‑Caching und Edge‑Kontrollen umgehen. Beschränken Sie ihn so, dass das CDN und nur die vorgesehenen Pfade darauf zugreifen können. Je nach Stack verwenden Sie Cloud‑Origin‑Access‑Kontrolle, Firewall‑Regeln mit dokumentierten CDN‑Egress‑Bereichen, Private Networking, signierte Origin‑Anfragen oder mutual TLS (mTLS), bei dem beide Seiten sich per Zertifikat authentifizieren.
Bestätigen Sie von einem autorisierten Testort, dass das Origin öffentliche Anfragen ablehnt, während der CDN‑Hostname funktioniert.
Scopeen Sie Health‑Checks, Deployment‑Tools und internen Zugriff nach Identität und Netzwerk statt einer breiten öffentlichen Regel.
Origin‑Authentifizierung unterscheidet sich je nach CDN und Origin. Nutzen Sie aktuelle Anbieter‑Anleitungen und eine Sicherheits‑Review.
Behandeln Sie TLS als zwei Verbindungen
HTTPS am Edge schützt die Besucher‑zu‑CDN‑Verbindung, aber auch die CDN‑zu‑Origin‑Verbindung benötigt Schutz. Fordern Sie Verschlüsselung auf beiden Beinen, validieren Sie das Origin‑Zertifikat für den CDN‑Modus und legen Sie Hostname‑ und Erneuerungszuständigkeiten fest. OWASP empfiehlt standardmäßig TLS 1.3 und erlaubt TLS 1.2 für Kompatibilität; TLS 1.0 und 1.1 sollten deaktiviert werden. Holen Sie qualifizierte Prüfung für regulierte Daten, Zahlungsflüsse oder ungewöhnliche Client‑Kompatibilität ein.
Listen Sie Edge‑ und Origin‑Zertifikat‑Verantwortliche, Erneuerungswege und Ausfallreaktionen auf.
Testen Sie HTTP‑zu‑HTTPS, canonical‑host und Deep‑Link‑Weiterleitungen auf Schleifen oder verlorene Pfade.
Verschlüsselung macht eine Antwort nicht automatisch sicher zum Cachen; setzen Sie Cache‑Regeln separat für authentifizierte, persönliche und zahlungsnahe Seiten.
Testen Sie den realen Auslieferungspfad, bevor Sie Traffic ändern
Beginnen Sie auf einem Staging‑Hostname oder einem engen Produktionspfad und testen Sie dann den CDN‑Hostname, nicht nur das Origin. Chrome DevTools Network zeigt Status, Domain, Timing, Größe und Header der Anfrage. Testen Sie ein Empty‑Cache‑Hard‑Reload, um einen Erstbesuch zu approximieren, und danach einen Wiederholungsbesuch, um Wiederverwendung zu prüfen. Vergleichen Sie erwartete Header und Inhalte, nicht nur eine optisch schnellere Seite. Wiederholen Sie Tests aus repräsentativen Regionen, wenn das Publikum geografisch verteilt ist.
Untersuchen Sie Cache‑Control und provider‑spezifische cache‑status Header. Bestätigen Sie, dass öffentliche Assets wiederverwendet werden und sensible Seiten nicht unerwartet geteilt werden.
Üben Sie einen Miss, die Korrektur veralteter Inhalte, Origin‑Fehler und das Zurückrollen eines Assets oder einer Route, bevor Sie breit ausrollen.
Speichern Sie getestete URLs, Header‑Erfassungen, Route‑Regel‑Version und Zeitmessungen vor und nach der Änderung mit dem Änderungsprotokoll.
Wählen Sie ein CDN nach Betriebsbedarf — und beweisen Sie es
Wählen Sie ein CDN nicht ausschließlich nach Point‑of‑Presence‑Anzahl oder generischer Geschwindigkeitsbehauptung. Performance variiert mit Geografie, Zeit, Traffic‑Verteilung, Routing und Cache‑Hit‑Rate. Vergleichen Sie Kandidaten auf repräsentativen Routen, Assets und Regionen. Fragen Sie, ob jeder Anbieter die benötigten Cache‑Kontrollen, zielgerichtete Invalidierung, Origin‑Beschränkung, Zertifikats‑Workflow, Logs, Zugriffsrollen, Preise, Support und Änderungsprozess unterstützt.
Verwenden Sie identische Cache‑Header, Origin‑Verhalten und Seiten für die Kandidaten; zeichnen Sie Erstbesuch‑ und Wiederholungsbesuch‑Ergebnisse separat auf.
Überprüfen Sie Anfragen-, Transfer-, Invalidierungs-, Logging‑ und Support‑Kosten sowie eine Cache‑Miss‑Surge. Preise und Kontrollen variieren nach Plan.
Fordern Sie exportierbare Konfiguration, Least‑Privilege, getestetes Rollback und klare Zuständigkeiten, bevor kritische Routen abgedeckt werden.