Ein Content Delivery Network liefert Inhalte über verteilte Server aus und entlastet damit den Ursprungsserver. Weil es die Zeit bis zum ersten Byte verkürzt, wirkt es besonders auf den LCP. Statische Dateien gehören mit langer Gültigkeitsdauer hinein, dynamische mit sehr kurzer – private Inhalte für einzelne Nutzer gar nicht.
Website & Technik
CDN: Wann es sich lohnt und was dabei schiefgeht
Das Wichtigste in Kürze
- Weil ein CDN die Zeit bis zum ersten Byte verkürzt, ist es besonders wirksam zur Verbesserung des LCP.
- Auch nicht cachebare Inhalte profitieren – über kürzeren Verbindungsaufbau und vorgewärmte Verbindungen.
- Private Ressourcen enthalten Daten für einen einzelnen Nutzer und sollten von einem CDN nicht zwischengespeichert werden.
- Schon sehr kurze Gültigkeitsdauern für dynamische Inhalte – im Bereich von Sekunden – senken die Last am Ursprung deutlich.
Ein CDN wird meist als Maßnahme für internationale Websites verstanden – Server in Frankfurt, Besucher in Sydney. Das ist der offensichtliche Fall und nicht der häufigste.
Was ein CDN tatsächlich tut
Es liefert Inhalte über ein verteiltes Netz von Servern aus. Daraus folgen drei Wirkungen, von denen nur die erste meist genannt wird:
- Kürzerer Weg zum Besucher. Die Verbindung endet an einem nahegelegenen Server, nicht am Ursprung.
- Entlastung des Ursprungsservers. Was aus dem Cache kommt, erreicht den eigenen Server nicht – das hilft besonders bei Lastspitzen.
- Schnellerer Verbindungsaufbau, auch für nicht cachebare Inhalte. Vorgewärmte Verbindungen zwischen CDN und Ursprung verkürzen den Weg selbst dann, wenn jede Anfrage durchgereicht werden muss.
Der dritte Punkt ist der unterschätzte: Ein CDN lohnt sich auch für eine Website, deren Inhalte sich ständig ändern.
Und die messbare Folge: Weil ein CDN die Zeit bis zum ersten Byte verkürzt, ist es besonders wirksam zur Verbesserung des LCP – jener Kennzahl aus den Core Web Vitals, die am schwersten zu bewegen ist.
Was wie lange dort liegen darf
| Inhalt | Empfehlung | Begründung |
|---|---|---|
| Bilder, Videos, versionierte Bibliotheken | Lange Gültigkeit – Monate bis ein Jahr | Ändern sich selten; bei Änderung ändert sich der Name |
| CSS und JavaScript mit Versionskennung | Lange Gültigkeit | Wie oben |
| HTML einer Übersichtsseite | Sehr kurz – Sekunden bis Minuten | Senkt die Last am Ursprung deutlich, ohne dass Inhalte veralten |
| HTML mit aktiver Leerung bei Änderung | Lange Gültigkeit plus Leerung | Beste Variante, wenn das CDN schnell leeren kann |
| Warenkorb, Kundenkonto, angemeldete Sitzungen | Nicht zwischenspeichern | Private Ressourcen enthalten Daten für einen einzelnen Nutzer |
| Formularseiten mit Einmal-Token | Nicht zwischenspeichern | Das Token läuft ab, das Absenden scheitert |
Die dritte Zeile ist die Erkenntnis, die am meisten bringt: Schon eine Gültigkeitsdauer von wenigen Sekunden senkt die Last am Ursprung erheblich. Bei einer Seite mit fünfhundert Aufrufen pro Minute bedeutet das, dass der eigene Server nur noch einen Bruchteil davon beantwortet – ohne dass ein Besucher einen veralteten Inhalt sieht.
Die fünfte und sechste Zeile sind die, bei denen Fehler teuer werden. Ein ausgelieferter Warenkorb gehört jemand anderem; eine Formularseite aus dem Cache ist nicht absendbar – dazu Formulare, die ankommen.
Die vier typischen Probleme
1. Veraltete Inhalte
Das Zurückziehen eines Inhalts erfordert ein ausdrückliches Leeren. Bei einer Preiskorrektur ist genau das der kritische Schritt – und der, der am häufigsten vergessen wird.
Praktische Konsequenz: Das Leeren des CDN gehört in die Veröffentlichungsroutine, nicht in die Fehlersuche. Die Reihenfolge der Ebenen steht in Caching verstehen.
2. Fragmentierung des Caches
Nicht normalisierte Parameter, abweichende Header und Cookies können eine Ressource in mehrere Cache-Einträge aufspalten. Statt eines Treffers für alle entstehen viele Einträge mit wenigen Treffern.
Der häufigste Auslöser im Alltag sind Kampagnenparameter in Adressen. Sie gehören normalisiert oder aus dem Cache-Schlüssel ausgeschlossen.
3. Weniger Treffer durch mehr Standorte
Anbieter müssen zwischen zwei Zielen abwägen: möglichst geringe Latenz und möglichst hohe Trefferquote. Viele Standorte verkürzen den Weg, verteilen den Verkehr aber auf mehr Caches – und senken damit die Trefferquote. Mehr Standorte sind also nicht automatisch besser.
4. Protokollfehler nach der Umstellung
Die Aktivierung von HTTP/2 kann Header-Verstöße sichtbar machen, die vorher toleriert wurden. Die Folge sind fehlgeschlagene Abrufe mit einer Protokollfehlermeldung. Das ist kein Grund, es nicht zu tun – aber ein Grund, nach der Umstellung zu prüfen.
Wie du erkennst, ob es wirkt
- Antwort-Header prüfen. Die meisten Anbieter setzen einen Header, der angibt, ob ein Treffer vorlag.
- Serverprotokolle ansehen. Wenn dort nach der Einrichtung deutlich weniger ankommt, funktioniert es – siehe Logfile-Analyse.
- LCP vorher und nachher messen, über echte Nutzerdaten statt über einen Einzeltest.
- Eine Änderung veröffentlichen und prüfen, wie lange sie braucht, bis sie durchkommt.
Punkt vier ist der, der die Betriebsfrage klärt – und die Antwort darauf entscheidet, ob eine lange Gültigkeitsdauer mit Leerung oder eine kurze ohne die richtige Wahl ist.
Wann sich der Aufwand nicht lohnt
Bei einer Website mit wenigen Besuchern aus der Region, die auf einem ausreichend dimensionierten Server läuft, ist der Gewinn klein und die zusätzliche Fehlerquelle real. Dort sind die größeren Hebel andere: weniger laden, Bilder in passenden Formaten ausliefern, den Einwilligungsdialog schlank halten.
Die Reihenfolge, die wirkt, steht in WordPress-Performance; was der Anbieter davon ohnehin mitbringt, in Hosting für kleine Unternehmen.
Häufige Fragen
Für die Entfernung meist nicht – wenn Besucher und Server in Deutschland sind, ist der Weg kurz. Für die Entlastung des Servers und die Abfederung von Lastspitzen kann es sich trotzdem lohnen, und viele Hoster bringen eines mit.
Weil das CDN eine Kopie hält. Das Zurückziehen von Inhalten erfordert ein ausdrückliches Leeren – es ist der Schritt, der beim Veröffentlichen von Korrekturen am häufigsten vergessen wird.
Wenn dieselbe Ressource unter mehreren Varianten gespeichert wird – etwa wegen unterschiedlich sortierter Parameter, abweichender Header oder Cookies. Statt eines Treffers entstehen viele Einträge, und die Trefferquote sinkt.
Quellen
- web.dev: Content delivery networks (CDNs) (abgerufen am 14.10.2026)
- web.dev: Prevent unnecessary network requests with the HTTP Cache (abgerufen am 14.10.2026)
Lass uns dreißig Minuten über deine Sichtbarkeit sprechen
Kostenlos, unverbindlich, und mit einer ehrlichen Einschätzung - auch wenn die lautet, dass du mich gerade nicht brauchst.
Erstgespräch vereinbaren