CDN Konfiguration klingt nach einer schnellen Lösung, doch fehlerhafte Regeln, SSL-Handshake-Overhead und schwache Origin-Ressourcen können die Ladezeit unbemerkt verlängern. Ich zeige, wie kleine Konfigurationsdetails große Bremsen erzeugen und wie Sie diese Fallen messbar und dauerhaft entschärfen.
Zentrale Punkte
- Cache-Regeln bestimmen, ob Edge-Server Inhalte liefern oder ständig den Origin belasten.
- SSL/TLS und Protokollwahl erhöhen Roundtrips, wenn Handshakes und Reuse nicht passen.
- Origin-Ressourcen und I/O begrenzen den Durchsatz trotz globaler Edges.
- DNS/Routing erzeugen Latenz, wenn Anycast und Peering ungünstig greifen.
- TTL/Purging steuern Frische, Konsistenz und Lastspitzen nach Änderungen.
Warum CDNs bremsen können
Ich sehe oft, dass eine Edge vor allem dann wirkt, wenn sie möglichst viele Objekte aus einem sauberen Cache liefert und nur selten den Ursprung befragt. Fehlt eine klare Trennung zwischen statischen und dynamischen Assets, dann generiert das CDN zahllose Bypasses zum Origin und verwässert den Vorteil. Jede zusätzliche DNS-Auflösung, jeder neue TCP-Handshake und jeder verpasste Keep-Alive kostet Millisekunden. Läuft der Datenpfad über weit entfernte PoPs, sammelt sich Latenz über mehrere Hops. Diese Summen merkt der Nutzer als Zähigkeit beim Start-Rendern und beim Time to First Byte.
Versteckte Stolpersteine in Cache und Routing
Falsche Cache-Control-Header, Cookie-Setzungen für eigentlich statische Dateien oder Query-Strings ohne Relevanz zwingen Edges zum Origin-Fetch. Ich prüfe zuerst, ob Cookies, Authorization-Header oder wechselnde Query-Parameter für CSS/JS/Images wirklich nötig sind. Stimmen die Vary-Regeln, steigt die Cache-Hit-Rate spürbar. Wer tiefer einsteigen will, schaut sich knappe Beispiele zu HTTP-Cache-Header an. Ebenso wichtig: Routing-Policies, die Anfragen unglücklich zu überlasteten PoPs lenken und damit Sekundenbruchteile an Latenz addieren.
SSL/TLS: Handshakes und Protokolle richtig nutzen
Ein zusätzlicher TLS-Handshake kostet zwei Roundtrips und vervielfacht die spürbare Verzögerung. Liegt die einfache RTT zwischen Client und Edge bei 95 ms, dann addiert ein frischer Handshake bereits knapp 200 ms, bevor das erste Byte fließt. Ich setze auf TLS 1.3, Session-Resumption und 0-RTT, damit Wiederbesucher keine teuren Neubauten starten. HTTP/2 bündelt Streams auf einer Verbindung, HTTP/3/QUIC reduziert Head-of-Line-Blocking bei wackeligen Netzen; das bringt gerade auf Mobilfunkstrecken sichtbarere Stabilität im Durchsatz ohne das verbotene Wort zu nutzen. Wichtig bleibt Connection-Reuse zwischen Edge und Origin, sonst frisst der Backend-Handshake den kompletten Gewinn auf.
Origin-Server als Nadelöhr
Ein schwacher Origin limitiert jeden CDN-Vorteil, weil Misses und Revalidierungen dort anstehen. Reicht die CPU nicht, stauen sich PHP- oder Node-Prozesse, und Timeouts häufen sich. Fehlen RAM und IOPS, dann bremst die Datenbank und jede Cache-Warme Phase endet in einer spürbaren Warteschlange. Ich prüfe Metriken wie CPU-Steal, iowait und offene Verbindungen, bevor ich am CDN drehe. Erst wenn der Ursprung performant antwortet, holt das CDN die großen Gewinne aus der Kante.
Netzwerk, Latenz und DNS-Design
Ich messe die RTT zwischen Nutzer, Edge und Origin getrennt, sonst jage ich Phantomursachen. Zusätzlich beobachte ich DNS-Resolution-Zeiten und Connection-Reuse-Quoten. Ungünstiges Peering zwischen CDN-Backbone und dem Rechenzentrum des Origins verteuert jeden Miss. Anycast hilft oft, lenkt in Einzelfällen aber zu einem überfüllten PoP; warum das passiert, zeigt eine Analyse zu Anycast-DNS. Ich teste deshalb aus Zielregionen mit realen Traces, bevor ich mir eine globale Verteilung schönrechne.
Cache-Purging und TTL-Strategien, die tragen
Ohne saubere TTL-Logik liefern Edges zu alte Inhalte oder bombardieren den Ursprung mit unnötigen Revalidierungen. Ich setze s-maxage für Proxies, age-Header für Messbarkeit und ETags nur dort, wo If-None-Match wirklich Sinn ergibt. Purges feuere ich gezielt per Tag oder Pfad, niemals als Full-Purge während Hauptverkehrszeiten. Diff-basierte Purges nach Deployments schonen Ressourcen und verhindern Kälteschocks im Cache. Die folgende Tabelle gibt eine schnelle Richtschnur für Startwerte:
| Inhaltstyp | Empfohlene TTL | Purge-Trigger | Risiko bei zu hoher/zu niedriger TTL | CDN-Regel-Hinweis |
|---|---|---|---|---|
| CSS/JS versioniert (z. B. app.v123.js) | 7–30 Tage | Neue Version | Zu hoch: kaum Risiko; zu niedrig: häufige Misses | Cache-Key ohne Cookies, Query-Ignore |
| Bilder/Fonts unverändert | 30–365 Tage | Asset-Tausch | Zu hoch: veraltetes Asset; zu niedrig: Origin-Last | Immutable setzen, Gzip/Brotli prüfen |
| HTML statisch (Marketing-Seiten) | 15–120 Minuten | Content-Update | Zu hoch: alte Inhalte; zu niedrig: Revalidierungen | s-maxage, Stale-While-Revalidate |
| HTML dynamisch (Shop, Login) | 0–1 Minute | User-Event | Zu hoch: falsche Personalisierung; zu niedrig: Misses | BYPASS per Cookie/Authorization |
| APIs (GET) | 30–300 Sekunden | Datenänderung | Zu hoch: veraltete Daten; zu niedrig: Thundering Herd | Stale-If-Error, Negative Caching |
Statisch vs. dynamisch – der überraschende Effekt
Webserver liefern statische Dateien extrem schnell, oft um Größenordnungen flotter als dynamische Seiten. Wenn ein Plugin jedoch Cookies für Bilder oder CSS setzt, markiert das CDN diese Assets als privat und umgeht den Cache. Dann ziehen Edge und Browser immer wieder zum Ursprung – mit entsprechend langen Ketten. Ich prüfe deshalb Cookie-Fahnen für alle statischen Routen und separiere statische Domains, damit keine Session-Cookies mitschwingen. So bleibt die Hit-Rate hoch und der Ursprung hat Luft für echte Logik.
Warmlaufen und Prefetch klug einsetzen
Kalte Caches töten Performance nach Releases, weil alle Hits zu Misses werden und der Origin glüht. Ich lasse wichtige Pfade gezielt vorwärmen, priorisiere Startseiten, Bestseller und kritische API-Endpunkte. Prefetch und Preload-Header bereiten Folge-Assets vor und reduzieren die Startphase merklich. Wer das methodisch aufsetzt, findet in kompakten How-tos zum CDN-Warmup nützliche Impulse. Kombiniert mit Stale-While-Revalidate bleiben Kanten lieferfähig, selbst wenn der Ursprung kurz stottert.
Konfigurations-Checkliste Schritt für Schritt
Ich starte mit dem Cache-Key: keine Cookies, keine unnötigen Query-Parameter für statische Objekte. Danach verifiziere ich Cache-Control, s-maxage, Stale-While-Revalidate und Stale-If-Error direkt im Header. Drittens prüfe ich Cookie-Policy und Authorization für dynamische Pfade, damit Personalisierung korrekt bleibt. Viertens messe ich aus Zielregionen Latenz, DNS-Zeiten und TLS-Handshakes getrennt für Client→Edge und Edge→Origin. Fünftens kontrolliere ich Purge-Automation nach Deployments, damit frische Inhalte schnell an allen Edges liegen.
Typische Anti-Patterns und wie ich sie vermeide
Ich verzichte auf globale Full-Purges zu Stoßzeiten, weil dann alle Nutzer einen Miss treffen. Ich hinterlege keine sehr niedrigen TTLs für Bilder, nur um „auf Nummer sicher“ zu gehen. Ich erzeuge keine übertriebenen Vary-Regeln, die die Objektvielfalt im Cache explodieren lassen. Ich lasse Cookies nicht auf statischen Domains mitlaufen, selbst wenn es „bequem“ erscheint. Und ich setze kein aggressives Revalidate auf HTML, wenn Stale-While-Revalidate den gleichen Frische-Eindruck mit weit weniger Last erreicht.
Architektur-Entscheidungen: Multi-CDN, Regionales Peering
Ein Multi-CDN mit Latenz-gesteuertem Routing verteilt Anfragen dorthin, wo die Strecke gerade am schnellsten ist. Ich nutze Origin-Shield oder Tiered Caching, damit der Ursprung bei Miss-Stürmen geschützt bleibt. Regionales Peering mit großen ISPs senkt RTT und Packet Loss oft stärker als jeder Code-Tweak. Negative Caching für 404/410 begrenzt wiederholte Misses, die nur Fehler zurückbringen. Mit sauberen Health-Checks klappt Failover ohne sichtbare Aussetzer für Nutzer.
Edge-Funktionen: Workers, ESI und fragmentiertes Caching
Viele CDNs bieten Edge-Compute: kleine Funktionen, die Header umschreiben, Routen entscheiden oder HTML dynamisch zusammensetzen. Ich nutze das, um Personalisierung an der Kante zu kapseln und den Großteil des HTMLs weiter cachebar zu halten (Fragment-/ESI-Ansatz). Fallen: kalte Starts langsamer Funktionen, zu großzügige CPU/Time-Limits und Zustände, die nicht reproduzierbar sind. Ich halte Funktionen deterministisch, messe ihre p95-Laufzeit und logge explizit, ob sie einen Cache-Hit ermöglichen oder verhindern.
Bilder, Formate und Kompression sauber steuern
Brotli für Text (HTML, CSS, JS) bringt messbar bessere Kompression als Gzip, darf aber nicht doppelt greifen. Ich deaktiviere Origin-Kompression, wenn die Edge bereits sauber komprimiert und achte auf Content-Length/Transfer-Encoding. Bei Bildern lohnt WebP/AVIF-Variantierung – aber nur mit kontrollierter Vary-Strategie. Ich normalisiere Accept-Header, um keine Cache-Explosion zu erzeugen, und halte Versionierung über Dateinamen, nicht über Query-Strings.
Cache-Key-Normalisierung und Parameter-Whitelists
Unnötige Query-Parameter wie UTM/Campaign erzeugen faktenarme Varianten. Ich whiteliste nur wenige Parameter, die Rendering oder Daten wirklich ändern, und ignoriere alles andere im Cache-Key. Für statische Assets entferne ich Cookies konsequent aus dem Key. Zusätzlich glätte ich Header, die selten relevant sind (z. B. Accept-Language), und reduziere so die Objektvielfalt, ohne Funktion zu verlieren. Das hebt die Hit-Rate oft zweistellig.
Authentifizierung, Signaturen und private Inhalte
Personalisierte Bereiche brauchen Schutz, müssen aber nicht komplett uncachebar sein. Ich trenne private User-Daten (BYPASS) von öffentlichen Fragmenten (cachebar) und verwende signierte URLs oder Cookies für downloadbare Objekte mit kurzer TTL. Sicherheitsmerker wie Authorization/Cookie dürfen nicht versehentlich am Edge gecacht werden; ich prüfe daher explizit, welche Header den Cache-Key beeinflussen. Für APIs setze ich „public, s-maxage“ nur bei GET und nur, wenn Antworten wirklich idempotent sind.
Priorisierung, Early Hints und Preconnect
HTTP/2-Priorisierung wirkt nur, wenn die Edge nicht blind umsortiert. Ich definiere Prioritäten für Krit-Pfade (CSS vor Bildern) und nutze 103 Early Hints, um Preload-Links vor dem eigentlichen HTML zu schicken. Preconnect hilft bei Domains, die sicher folgen; übermäßiges dns-prefetch dagegen erzeugt Leerlaufarbeit. Ich messe, ob diese Hinweise wirklich die Download-Reihenfolge ändern – wenn nicht, korrigiere ich die Prioritäten oder spare überflüssige Hints ein.
Timeouts, Retries und Schutz des Origins
Zu aggressive Retries bei Misses multiplizieren Origin-Last und verlängern TTFB, wenn viele Worker zeitgleich auf dieselbe Ressource warten. Ich setze kurze Timeouts, exponentielles Backoff und kollabiere Revalidierungen („request collapsing“), damit nur ein Fetch den Ursprung erreicht. Ein Circuit Breaker, der bei Fehlerquoten auf stale-if-error umschaltet, erhält die Auslieferung, statt Nutzer mit 5xx zu treffen. Wichtig: Keep-Alive und Connection-Pools zwischen Edge und Origin stabil halten, sonst frisst Neuaufbau jeden Vorteil.
WAF, Bot-Traffic und Rate Limits
WAF-Regeln prüfen oft jeden Request synchron und können die Latenz merklich heben. Ich lasse statische Pfade an der WAF vorbeilaufen, wo es sicher ist, und stelle Regeln auf „log-only“, bevor ich sie scharf schalte. Für fehlerfreundliche Bots oder Scraper begrenze ich Rate-Limits an der Kante und nutze Negative Caching für bekannte 404er-Routen. So bleibt die Edge flink, der Ursprung geschützt und legitimer Traffic unbehelligt.
Metriken, Logs und Tracing, die wirklich helfen
Ohne obere Perzentile blind zu sein, ist der größte Fehler. Ich tracke p95/p99 TTFB, Edge-Hit-Rate, Reuse-Quoten, TLS-Handshake-Zeiten und Origin-Fetch-Dauer getrennt. Response-Header mit Cache-Status (HIT/MISS/STALE/BYPASS), Age und Serving-PoP landen in Logs und korrelieren mit Trace-IDs aus der Anwendung. So sehe ich, ob ein Outlier aus Routing, TLS, CPU-Wait oder WAF stammt. Zusätzlich sample ich RUM-Daten per Region und Gerät, um Mobilflanken gesondert zu erkennen.
Rollout, Tests und Versionierung der Regeln
CDN-Regeln sind Produktion. Ich versiegele Änderungen hinter Feature-Flags, rolle sie per Region/Prozent aus und vergleiche Metriken gegen eine Kontrollgruppe. Jede Regel erhält eine Version, ein Ticket und messbare Ziele (z. B. +8 % Hit-Rate, -40 ms p95 TTFB). Rollbacks sind vorbereitet und automatisiert. Synthetic-Tests prüfen vorab, ob Cache-Header, Cookies und Vary wie geplant greifen, bevor echter Traffic die Änderung trifft.
Streaming und Range-Requests richtig bedienen
Video, große Downloads und PDFs profitieren von Range-Requests und 206-Responses. Ich stelle sicher, dass die Edge Teilbereiche cachen darf, Segmente konsistent benannt sind und die Origin-Server Byte-Ranges effizient liefern. Prefetch von Folgesegmenten glättet Bitratenwechsel, Stale-If-Error hält Streams bei kurzzeitigem Origin-Ausfall am Laufen. Wichtig: keine ungedrosselten Parallel-Range-Requests, sonst wird die Bandbreite zur Engstelle.
Kurz zusammengefasst: Ihre nächsten Schritte
Starten Sie mit einer ehrlichen Messung aus Nutzerregionen und trennen Sie Client→Edge von Edge→Origin. Heben Sie die Cache-Hit-Rate mit sauberen Headern, Cookie-Diät und passenden TTLs. Entlasten Sie den Ursprung mit Vorwärmen, Stale-Strategien und einem sparsamen Purge-Plan. Optimieren Sie TLS, HTTP/2/3 und Connection-Reuse, damit Handshakes nicht die Stoppuhr dominieren. Prüfen Sie Peering, Anycast-Zuordnung und PoP-Auslastung, bevor Sie an Code oder Hardware drehen, und sichern Sie Erfolge mit dauerhaftem Monitoring.
