CDN nach Zielgruppe und Cache-Strategie einsetzen

Cookbook: Ziel und Ergebnis

Ein CDN wird eingesetzt, wenn geografische Latenz, Assetvolumen, Traffic-Spitzen oder Edge-Caching den zusätzlichen DNS-, Cache- und Betriebsaufwand rechtfertigen.

Rezept: Schritt für Schritt

1. Nutzerregionen, aktuelle TTFB je Region, Assetvolumen und Ursprungslast aus echten Daten erfassen.
2. Zuerst statische Assets mit versionierten URLs, korrektem TLS/CORS und Purge anbinden.
3. Cache-Hit-Rate, Fehler und echte Client-IP/Firewall prüfen. Erst danach HTML-Edge-Cache mit explizitem Bypass für Login, Vorschau, Suche, Shop und private Cookies.
4. Canonical, Sitemap, robots, Bild-URLs, Consent und Datenschutz nach Umstellung prüfen.

Rechenweg oder Entscheidungsregel

Netto-Latenzgewinn ≈ Ursprungslatenz − Edge-Latenz − zusätzliche Verarbeitung\nOrigin-Offload = Edge-Hits / Gesamtanfragen × 100

Eine regionale Zielgruppe 20 ms vom Ursprung gewinnt eventuell wenig; weltweite Besucher mit 180 ms Netzweg können deutlich profitieren.

Praxisbeispiel

80 % der Nutzer in Deutschland, Ursprung Frankfurt: Median-TTFB 180 ms – CDN-Gewinn klein. 45 % Nordamerika/Asien mit 900-ms-Miss und große Downloads: Asset-CDN plus Edge-Hits senkt Netzweg und Ursprungslast. HTML wird erst nach Cookie-Test aktiviert.

Prüfen, ob es funktioniert

• Cache-Hit und Age sind aus Zielregionen nachvollziehbar.
• Purge nach Veröffentlichung funktioniert innerhalb definierter Zeit.
• Keine privaten/personalisierten Inhalte am Edge; Origin-Ausfall verhält sich geplant.

Rollback

DNS/Proxy auf den dokumentierten Ursprung zurückführen, Edge-HTML-Cache deaktivieren und vollständig purgen. Zertifikate und Origin-Firewall erst nach erfolgreicher Rückkehr ändern.

Wann es lohnt

Globale Zielgruppen, große statische Assets, Traffic-Spitzen und Edge-Page-Caching sind gute Gründe. Für eine kleine regionale Website mit schnellem nahegelegenem Hosting kann der Unterschied gering sein.

Stufen

1. Zuerst statische Assets mit langen, versionierten Cache-Headern verteilen.
2. Purge und Origin-Fallback testen.
3. Erst dann HTML am Edge cachen; Cookies, Login, Vorschau, Suche, Shop und Query-Parameter explizit behandeln.

Abhängigkeiten

CDN und WordPress-Page-Cache dürfen nicht gegeneinander purgen. TLS, echte Client-IP, Firewall, Bild-URLs und Canonicals müssen korrekt bleiben. Query-Parameter wie UTM können unnötige Varianten erzeugen, falls die Cache-Key-Strategie sie nicht ignoriert.

Erfolgskontrolle

Aus relevanten Regionen Cache-Hit, TTFB und Ursprungslast vergleichen. Inhalte nach Bearbeitung, Passwortschutz und Consent testen.

Quellen und Prüfstand

• WordPress: Performance-Optimierung und CDN
• Google: Core Web Vitals für Entscheider

Inhalt fachlich geprüft am 17. August 2026. Konkrete Werte sind Ausgangspunkte, keine Universaldosierung.