Warum Caching schiefgehen kann

Ich habe einen CDN-Cache hinzugefügt – und es wurde langsamer. Hier ist die Rechnung, die ich hätte machen sollen.

Letzte Woche habe ich eine Optimierung durchgeführt, die wie ein Schnäppchen klang: Ich habe einen Content Delivery Network (CDN)-Cache vor meine statische Website geschaltet. Klarer Fall: schnellere Ladezeiten, glücklichere Nutzer, bessere SEO-Werte. Stattdessen bekam ich das Gegenteil. Meine Website wurde messbar langsamer. Nicht schleichend – ein unabhängiger Crawler, der zuvor 38-Sekunden-Ladezeiten gemeldet hatte, begann plötzlich mit 52 Sekunden zu berichten. Autsch.

Das ist nicht das erste Mal, dass Infraekturoptimierungen nach hinten loslaufen. Aber es war eine bescheidene Erinnerung daran, dass Caches ihren eigenen Performance-Overhead haben. Bevor du blind einen CDN in deinen Stack einbaust, hier die Rechnung, die ich lieber zuerst gemacht hätte.

Warum Caching schiefgehen kann

CDN klingen auf den ersten Blick wie ein klares Win-Win-Szenario. Statische Assets werden näher an den Nutzer gebracht, Serverlast reduziert, globale Latenz verbessert. Aber jeder Cache bringt Overhead mit sich:

1. **Latenz durch Cache-Entscheidungen**: Ist diese Anfrage gecacht? Muss ich revalidieren? Welche Header gelten?
2. **Netzwerk-Hops**: Selbst Edge-Knoten sind nicht unendlich nah am Nutzer
3. **Cache-Misses**: Wenn Caches ablaufen oder gepurgt werden, zahlen die Nutzer die volle Origin-Latenz plus CDN-Verarbeitungsverzögerung
4. **Kompression und Transformation**: Viele CDNs komprimieren oder modifizieren Inhalte, was zusätzliche Verarbeitungszeit bedeutet

In meinem Fall lag das Problem nicht am CDN selbst – sondern an der *Cache-Konfiguration*. Standardmäßig cachen viele CDN-Setups aggressive kleine Dateien, während größere ungecacht bleiben. Das erzeugt ein uneinheitliches Nutzererlebnis.

Die Zahlen, die zählen

Bevor du eine Caching-Lösung implementierst, rechne diese Werte durch:

Cache-Trefferquote
```
Trefferquote = Treffer / (Treffer + Fehler)
```

Wenn du nur 60 % der Anfragen aus dem Cache bedienst, zahlst du für 40 % der Requests den vollen CDN-Overhead – um keinen Nutzen zu haben. Ziel sollte mehr als 85 % sein.

Effektive Latenz
```
Effektive Latenz = (Trefferquote × Edge-Latenz) + (Fehlerquote × (Edge + Origin-Latenz))
```

Beispiel:
Edge-Latenz: 50 ms
Origin-Latenz: 300 ms
Trefferquote: 90 %
Effektive Latenz: (0,9 × 50) + (0,1 × 350) = 80 ms

Verglichen mit direktem Origin: 300 ms. Der CDN gewinnt klar.

Aber wenn die Trefferquote auf 60 % fällt:
Effektive Latenz: (0,6 × 50) + (0,4 × 350) = 170 ms
Noch immer schneller, aber kaum wert, die Komplexität zu tragen.

Time-to-Live (TTL) Optimierung
Kurze TTLs (< 30 Sekunden) bedeuten mehr Origin- Fetches. Lange TTLs (> 24 Stunden) führen zu veraltetem Inhalt. Finde das richtige Gleichgewicht basierend auf der Update-Frequenz.

Szenarien, in denen ich keinen CDN einbauen würde

1. Vorwiegend lokale Zielgruppe
Wenn 90 % deines Traffics aus einer Region kommen, kann ein CDN unnötige Komplexität hinzufügen. Ein gut konfigurierter Origin-Server könnte bessere Ergebnisse liefern.

Beispiel: Die Website eines lokalen Restaurants, die hauptsächlich Kunden aus der Umgebung bedient, profitiert nicht wirklich von globalen Edge-Caches.

2. Stark dynamischer Inhalt
Bei Websites, bei denen Inhalte alle paar Minuten aktualisiert werden (z. B. Nachrichtendashboards), zwingen kurze TTLs zu ständiger Revalidierung. Der Cache wird zur Last statt zum Vorteil.

Beispiel: Mein Analytik-Dashboard holt sich alle 30 Sekunden Live-Daten. Hier wäre Caching entweder veraltet oder bräuchte komplexe Invalidierungslogik.

3. Kleine Dateigrößen
CDNs optimieren die Netzwerknähe – aber wenn deine Dateien klein sind (unter 10 KB), kann der Overhead, die Anfrage über einen CDN zu leiten, die Übertragungsersparnis übersteigen.

Beispiel: JSON-API-Antworten unter 5 KB laden oft schneller direkt vom Origin als über Edge-Verarbeitung.

Tools zur Leistungsdiagnose

Bevor du annimmst, dass CDN = Verbesserung bedeutet, miss deine Basisperformance mit:

- **WebPageTest.org**: Detaillierte Wasserfalldiagramme, die zeigen, wo die Zeit verbracht wird
- **Lighthouse CI**: Automatisierte Leistungsprüfungen in deinem Deployment-Pipeline
- **Real User Monitoring (RUM)**: Tools wie [PostHog](https://posthog.com/) oder [Plausible](https://plausible.io/) zeigen das echte Nutzererlebnis

Führe Tests von verschiedenen geografischen Standorten durch, um das wahre Erlebnis deiner Zielgruppe zu verstehen.

Meinen Fehler korrigieren

Nach der Diagnose des Problems habe ich meinen Ansatz angepasst:

1. TTL für statische Assets von 30 Sekunden auf 6 Stunden erhöht
2. Proper Cache-Tags für dynamische Invalidierung implementiert
3. Prä-Warming-Logik für populäre Endpunkte hinzugefügt
4. Trefferquoten kontinuierlich mit [Cloudflare Analytics](https://www.cloudflare.com/analytics/) überwacht

Ergebnis? Die Ladezeiten sanken von 52 Sekunden auf 1,2 Sekunden global.

Fazit

CDNs sind keine Wunderwaffen. Sie sind hochentwickelte Werkzeuge, die sorgfältig abgestimmt werden müssen. Lege stets Basiswerte fest, bevor du optimierst, und nimm nie an, dass Standardeinstellungen für deinen Anwendungsfall funktionieren.

Teste gründlich, miss den Einfluss und denke immer dran: Manchmal verbessert die Entfernung von Komplexität mehr als das Hinzufügen neuer Elemente.

FAQ

Sollte ich immer einen CDN verwenden?
Nicht unbedingt. Entscheide basierend auf Geography deiner Zielgruppe, Content-Typ und Update-Frequenz. Lokale Zielgruppen mit kleinen Dateien sehen oft keinen Nutzen.

Was ist eine akzeptable Cache-Trefferquote?
Ziele: 85 % oder höher. Unter 70 %, frage dich, ob der CDN-Overhead wirklich lohnenswert ist.

Wie lange sollte ich statische Assets cachen?
Für versionierte Assets (mit Hash-Dateinamen), cache-unbegrenzt. Für andere: 1–24 Stunden abhängig von der Update-Frequenz.

Kann ein CDN negativ für SEO sein?
Ja, wenn es Ladezeiten erhöht oder uneinheitlichen Content ausliefert. Google berücksichtigt Page Speed in Rankings, also behalte Core Web Vitals im Blick.