Ein Content Delivery Network, kurz CDN, verteilt Inhalte einer Website über mehrere geografisch verteilte Server. Besucher müssen dadurch bestimmte Dateien nicht immer direkt vom ursprünglichen Webserver abrufen, sondern können sie von einem näher gelegenen oder besser erreichbaren CDN-Standort erhalten.

Das klingt zunächst wie ein großes internationales Cache-System – und genau das ist ein wichtiger Teil davon. Moderne CDNs können allerdings deutlich mehr. Sie können komplette Webseiten zwischenspeichern, HTTPS-Verbindungen übernehmen, Daten komprimieren, Angriffe abfangen oder Anfragen intelligent an verschiedene Systeme weiterleiten.

Ein CDN ersetzt deshalb weder automatisch das Hosting noch WordPress. Es setzt sich vielmehr zwischen Besucher und eigentlichen Webserver.

Der normale Weg ohne CDN

Angenommen, eine Website wird auf einem Server in Frankfurt betrieben.

Ein Besucher aus Wien ruft sie auf.

Seine Anfrage geht direkt zum Server in Frankfurt. Dort wird die Seite erzeugt und zurückgeschickt.

Vereinfacht:

Besucher in Wien
↓
Server in Frankfurt
↓
Website

Für diese Entfernung ist das normalerweise kein großes Problem.

Nun besucht jemand dieselbe Website aus Sydney.

Die Daten müssen über eine deutlich größere Strecke übertragen werden.

Auch wenn Licht und elektrische Signale sehr schnell sind, entstehen durch Netzwerke, Router und Verbindungsaufbau messbare Verzögerungen.

Ein CDN versucht, einen Teil dieser Entfernung zu vermeiden.

Der Weg mit CDN

Zwischen Besucher und Ursprungsserver befindet sich nun das CDN.

Vereinfacht:

Besucher
↓
CDN
↓
Ursprungsserver

Das CDN besitzt weltweit oder zumindest regional verschiedene Standorte.

Wenn eine bereits gespeicherte Datei an einem passenden Standort vorhanden ist, muss die Anfrage nicht bis zum eigentlichen Webserver weitergeleitet werden.

Der Besucher erhält sie direkt vom CDN.

Aus einer langen Strecke kann dadurch eine wesentlich kürzere werden.

Was ist der Origin?

Der ursprüngliche Server einer Website wird im CDN-Kontext häufig als Origin oder Origin Server bezeichnet.

Dort befindet sich die maßgebliche Quelle der Website beziehungsweise ihrer Inhalte.

Bei einer WordPress-Seite könnte dort beispielsweise laufen:

Webserver
↓
PHP
↓
WordPress
↓
Datenbank

Das CDN liegt davor.

Wenn eine benötigte Ressource nicht im CDN-Cache vorhanden ist, wird sie vom Origin abgerufen.

Der Origin bleibt damit die Quelle, aus der das CDN seine Daten erhält.

Was ist ein Edge-Server?

Die geografisch verteilten CDN-Systeme werden häufig als Edge-Server oder Edge-Standorte bezeichnet.

„Edge“ bezeichnet dabei vereinfacht den Rand des Netzwerks – möglichst nahe an den Benutzern.

Ein CDN könnte beispielsweise Standorte in mehreren europäischen, amerikanischen und asiatischen Städten betreiben.

Ein Besucher soll möglichst einen geeigneten nahen Standort erreichen.

Das Konzept sieht vereinfacht so aus:

                 Origin
                   │
        ┌──────────┼──────────┐
        │          │          │
     Edge A     Edge B     Edge C
        │          │          │
     Besucher   Besucher   Besucher

Die konkrete technische Architektur kann deutlich komplexer sein. Für das Verständnis genügt zunächst dieses Modell.

Ein CDN ist nicht einfach ein zweiter Webhoster

Wenn das CDN Inhalte speichert, könnte man meinen, die Website liege nun vollständig dort.

In vielen Fällen stimmt das nicht.

WordPress, Datenbank und Administrationssystem laufen weiterhin auf dem eigentlichen Hosting.

Das CDN besitzt lediglich Kopien bestimmter Inhalte.

Wird der Cache geleert, muss das CDN die Ressourcen erneut vom Origin abrufen.

Deshalb bleibt gutes Hosting auch mit CDN wichtig.

Ein langsamer oder instabiler Origin kann nicht in jedem Szenario dauerhaft hinter einem CDN versteckt werden.

Welche Dateien eignen sich besonders gut für ein CDN?

Besonders einfach lassen sich Inhalte verteilen, die sich für viele Besucher nicht unterscheiden.

Dazu gehören typischerweise Bilder, CSS, JavaScript, Schriftdateien und Downloads.

Ein Logo könnte beispielsweise einmal vom Origin abgeholt und anschließend an zahlreichen CDN-Standorten zwischengespeichert werden.

Der zehntausendste Besucher benötigt dann möglicherweise überhaupt keine Anfrage mehr an den ursprünglichen Server.

Gerade große Mediendateien profitieren davon.

Deshalb sind CDN und Bildoptimierung eng miteinander verbunden.

Ein CDN macht eine große Datei nicht automatisch klein

Dieser Punkt ist wichtig.

Angenommen, dein Titelbild besitzt fünf Megabyte.

Ohne CDN lädt ein Besucher fünf Megabyte vom Origin.

Mit CDN lädt er möglicherweise fünf Megabyte von einem näheren Edge-Standort.

Das kann schneller sein.

Es bleiben aber fünf Megabyte.

Bildkompression und CDN lösen also unterschiedliche Probleme.

Bildoptimierung reduziert die Datenmenge.

Das CDN verbessert unter anderem den Ort und die Effizienz der Auslieferung.

Am besten funktionieren beide gemeinsam.

Was bedeutet CDN-Caching?

Wenn ein Edge-Server eine Ressource zum ersten Mal benötigt, besitzt er möglicherweise noch keine lokale Kopie.

Dann passiert ein Cache Miss.

Der Edge fragt die Datei beim Origin an:

Besucher
↓
Edge
↓
Datei nicht vorhanden
↓
Origin
↓
Datei
↓
Edge speichert Kopie
↓
Besucher

Beim nächsten passenden Aufruf entsteht möglicherweise ein Cache Hit:

Besucher
↓
Edge
↓
Datei vorhanden
↓
direkt ausliefern

Genau diese Begriffe haben wir bereits in Caching einfach erklärt behandelt.

Das erste Laden kann deshalb langsamer sein

Nach einem vollständigen Cache-Purge besitzen die Edge-Standorte bestimmte Inhalte zunächst nicht mehr.

Der erste Besucher einer Region kann dadurch einen Cache Miss erzeugen.

Das CDN muss die Ressource vom Origin holen.

Danach profitieren weitere Besucher von der gespeicherten Kopie.

Bei stark frequentierten Inhalten füllt sich der Cache sehr schnell wieder.

Bei selten aufgerufenen Seiten kann ein Cache-Eintrag dagegen möglicherweise immer wieder verschwinden, bevor er erneut benötigt wird.

Nicht alles bleibt unbegrenzt im CDN

CDN-Speicher ist ebenfalls eine begrenzte Ressource.

Selten benötigte Inhalte können deshalb irgendwann aus dem Cache entfernt werden.

Zusätzlich besitzen Cache-Regeln Ablaufzeiten.

Ein Bild kann möglicherweise sehr lange gespeichert werden.

Eine Startseite vielleicht wesentlich kürzer.

Ob und wie lange etwas gecacht wird, hängt von:

HTTP-Headern,

CDN-Regeln,

Dateityp,

Websitekonfiguration

und den Fähigkeiten des jeweiligen Dienstes ab.

Was passiert nach einer Änderung?

Angenommen, du ersetzt ein Bild auf der Website.

Der Origin besitzt die neue Datei.

Ein CDN-Edge könnte jedoch noch die alte Fassung gespeichert haben.

Deshalb braucht auch ein CDN eine Strategie zur Cache-Invalidierung.

Eine Möglichkeit besteht darin, die betreffende URL gezielt zu leeren.

Eine andere besteht darin, bei geänderten Dateien neue URLs beziehungsweise Dateiversionen zu verwenden.

Das Grundproblem kennen wir bereits:

Ein Cache ist nur dann nützlich, wenn er schnell ist und trotzdem nicht dauerhaft veraltete Inhalte ausliefert.

Ein CDN kann auch HTML-Seiten cachen

Ein CDN muss sich nicht auf Bilder und andere statische Ressourcen beschränken.

Moderne Systeme können teilweise komplette HTML-Dokumente zwischenspeichern.

Für eine WordPress-Wissensseite ist das sehr interessant.

Statt:

Besucher
↓
CDN
↓
Origin
↓
PHP
↓
WordPress
↓
Datenbank
↓
HTML

kann bei einem Cache Hit entstehen:

Besucher
↓
CDN
↓
fertiges HTML

Der Origin muss diese Anfrage dann überhaupt nicht bearbeiten.

Das kann Serverlast und Antwortzeiten erheblich reduzieren.

Full-Page-Caching ist besonders stark bei Informationsseiten

Ein Artikel wie dieser sieht für nahezu alle anonymen Besucher gleich aus.

Das macht ihn ideal für vollständiges Seiten-Caching.

Ein CDN kann eine erzeugte Fassung speichern und anschließend sehr viele Besucher direkt damit bedienen.

Bei einem Wissensportal, Magazin oder Blog kann das ausgesprochen effektiv sein.

Je stärker eine Seite personalisiert wird, desto schwieriger wird dieses Verfahren allerdings.

Warenkorb und Kundenkonto sind ein anderes Problem

Ein Onlineshop kann nicht einfach jede Seite identisch an alle Besucher ausliefern.

Der eine besitzt drei Produkte im Warenkorb.

Der andere keines.

Ein Kunde ist eingeloggt.

Ein anderer nicht.

Deshalb müssen dynamische Bereiche vom gemeinsamen Cache ausgeschlossen oder anhand bestimmter Merkmale unterschiedlich behandelt werden.

Ein CDN kann bei einem Shop hervorragend funktionieren.

Die Konfiguration ist aber anspruchsvoller als bei einem reinen Artikelportal.

Cookies beeinflussen CDN-Caching

Cookies können anzeigen, dass ein Besucher eine besondere Sitzung besitzt.

Beispielsweise:

eingeloggt,

Warenkorb vorhanden,

bestimmte Sprache,

individuelle Einstellung.

CDN-Regeln können solche Cookies berücksichtigen.

Dadurch lässt sich beispielsweise festlegen:

Anonyme Besucher erhalten die gecachte öffentliche Seite.

Eingeloggte Benutzer werden zum Origin weitergeleitet.

Eine saubere Trennung ist besonders wichtig, damit keine personalisierten Inhalte versehentlich gemeinsam gecacht werden.

Sicherheit geht vor Cache-Hit-Rate

Theoretisch könnte ein besonders aggressiver Cache fast alles speichern.

Das wäre schnell.

Wenn dadurch allerdings persönliche Kundendaten an andere Besucher gelangen, wäre die Website zwar performant, aber katastrophal falsch konfiguriert.

Caching darf deshalb nie nur nach Geschwindigkeit optimiert werden.

Die wichtigste Frage lautet zuerst:

Darf diese Antwort überhaupt von mehreren Benutzern gemeinsam verwendet werden?

Erst danach kommt Performance.

Ein CDN kann die Entfernung zum Besucher verkürzen

Der offensichtlichste Vorteil eines CDN ist die geografische Verteilung.

Stell dir einen Origin in Europa vor.

Besucher kommen aus:

Europa,

Nordamerika,

Asien,

Australien.

Ohne CDN laufen sämtliche Anfragen zum europäischen Server.

Mit CDN können häufig benötigte Ressourcen näher an den jeweiligen Besuchern liegen.

Je internationaler das Publikum, desto interessanter wird dieser Effekt.

Für eine rein lokale Website kann der Effekt kleiner sein

Wenn die Website auf einem schnellen Server in Wien läuft und fast alle Besucher aus Österreich kommen, sind die geografischen Wege ohnehin relativ kurz.

Ein CDN kann trotzdem Vorteile bieten.

Aber allein das Argument „näher am Benutzer“ fällt weniger stark ins Gewicht.

Bei einer global genutzten Website kann derselbe Mechanismus deutlich mehr bewirken.

Deshalb ist ein CDN keine Pflichtkomponente für jede Website.

Netzwerkqualität ist wichtiger als Luftlinie

Der geografisch nächste Server ist nicht zwangsläufig der technisch schnellste.

Internetverkehr folgt nicht einfach einer geraden Linie auf der Landkarte.

Routing, Peering und Netzauslastung spielen ebenfalls eine Rolle.

CDN-Anbieter versuchen deshalb, Anfragen intelligent an geeignete Standorte zu führen.

„Nächster Edge“ bedeutet in der Praxis eher:

ein sinnvoll erreichbarer CDN-Standort

und nicht zwingend das Rechenzentrum mit der geringsten Entfernung in Kilometern.

Was ist Anycast?

Viele große Netzwerke verwenden Technologien, bei denen dieselbe IP-Adresse von mehreren Standorten aus angekündigt werden kann.

Der Netzwerkverkehr wird dann anhand des Internet-Routings zu einem geeigneten Standort geführt.

Dieses Prinzip wird häufig mit Anycast realisiert.

Für einen Website-Betreiber ist die technische Umsetzung meist unsichtbar.

Er sieht nur:

Die Domain zeigt auf die CDN-Infrastruktur.

Das Netzwerk sorgt anschließend dafür, dass Besucher einen passenden Einstiegspunkt erreichen.

DNS spielt deshalb eine wichtige Rolle

Damit Anfragen überhaupt beim CDN landen, muss die Domain entsprechend konfiguriert werden.

Die genaue Umsetzung hängt vom Dienst ab.

Häufig wird DNS so eingestellt, dass der öffentliche Datenverkehr zunächst zur CDN- beziehungsweise Proxy-Infrastruktur gelangt.

Das CDN kennt anschließend den eigentlichen Origin.

Wer diesen Zusammenhang verstehen möchte, findet die Grundlage unter Was ist DNS?.

Der Origin kann dadurch weniger direkt sichtbar sein

Wenn Besucher ausschließlich die CDN-Infrastruktur erreichen, tritt der eigentliche Webserver nach außen weniger in Erscheinung.

Das kann für Sicherheit und Architektur nützlich sein.

Es bedeutet allerdings nicht automatisch, dass der Origin vollkommen verborgen oder unangreifbar ist.

Wenn seine IP-Adresse anderweitig bekannt wird und direkte Verbindungen erlaubt sind, kann er weiterhin erreichbar sein.

Sicherheitsarchitektur sollte deshalb nicht allein auf die Existenz eines CDN vertrauen.

Ein CDN kann DDoS-Angriffe abfangen

Distributed-Denial-of-Service-Angriffe versuchen, Systeme durch sehr viele Anfragen oder große Datenmengen zu überlasten.

Ein einzelner kleiner Webserver kann damit relativ schnell an seine Grenzen geraten.

Ein großer CDN-Anbieter besitzt dagegen eine verteilte Infrastruktur und kann bestimmte Angriffsmuster bereits vor dem Origin abfangen.

Damit kann ein CDN zusätzlich zur Performance eine wichtige Sicherheitsfunktion übernehmen.

Die genauen Schutzmöglichkeiten hängen allerdings stark vom Anbieter und Tarif ab.

CDN und Web Application Firewall

Manche CDN-Plattformen bieten zusätzlich eine Web Application Firewall, kurz WAF.

Sie kann HTTP-Anfragen untersuchen und bestimmte verdächtige Muster blockieren, bevor sie WordPress oder eine andere Anwendung erreichen.

Das kann eine zusätzliche Schutzebene bilden.

Die vereinfachte Architektur lautet dann:

Besucher
↓
CDN / WAF
↓
Webserver
↓
WordPress

Auch hier gilt:

Eine WAF ergänzt die Sicherheit.

Sie macht Updates, sichere Passwörter und saubere Serverkonfiguration nicht überflüssig.

Ein CDN kann Bots filtern

Nicht jeder Websiteaufruf stammt von einem Menschen.

Automatisierte Systeme durchsuchen Websites für:

Suchmaschinen,

Monitoring,

Spam,

Scraping,

Angriffe.

Ein CDN kann bestimmte Bots bereits am Netzwerkrand erkennen oder begrenzen.

Dadurch erreicht weniger unnötiger Traffic den eigentlichen Server.

Bei stark angegriffenen Websites kann dieser Effekt durchaus relevanter sein als die reine geografische Beschleunigung.

Rate Limiting kann einzelne Funktionen schützen

Ein Loginformular muss möglicherweise nicht tausende Anfragen pro Sekunde von derselben Quelle akzeptieren.

Ein CDN oder Reverse Proxy kann solche Zugriffsmuster begrenzen.

Damit lassen sich bestimmte Angriffe oder missbräuchliche Zugriffe reduzieren.

Rate Limiting sollte jedoch vorsichtig konfiguriert werden.

Zu aggressive Regeln können auch legitime Besucher blockieren.

HTTPS kann am CDN beendet werden

Bei HTTPS müssen verschlüsselte Verbindungen aufgebaut werden.

Ein CDN kann die Verbindung des Besuchers zunächst an seinem Edge-Standort entgegennehmen.

Von dort läuft eine weitere Verbindung zum Origin.

Vereinfacht:

Besucher
⇄ HTTPS
CDN
⇄ HTTPS
Origin

Die Verbindung zwischen CDN und Origin sollte dabei ebenfalls angemessen abgesichert sein.

Ein CDN ist kein Grund, den letzten Abschnitt unverschlüsselt zu behandeln.

Zertifikatsverwaltung kann dadurch einfacher werden

CDN-Anbieter können Zertifikate für öffentliche Domains häufig automatisiert bereitstellen und erneuern.

Das vereinfacht die HTTPS-Verwaltung.

Der Origin benötigt je nach Architektur trotzdem ein eigenes Zertifikat für die sichere Verbindung zum CDN.

Für den Website-Betreiber bleibt vieles davon im Alltag unsichtbar.

Der Besucher sieht einfach eine normale HTTPS-Verbindung.

CDNs können moderne Protokolle bereitstellen

Ein CDN kann moderne Netzwerk- und Webprotokolle gegenüber Besuchern anbieten, auch wenn die Infrastruktur dahinter anders aufgebaut ist.

Damit lassen sich Verbesserungen zentral bereitstellen, ohne jeden Origin einzeln identisch zu konfigurieren.

Das ist besonders interessant für Betreiber vieler Websites.

Der CDN-Layer wird dann zu einer gemeinsamen technischen Frontschicht.

Kompression kann ebenfalls am Edge stattfinden

HTML, CSS und JavaScript lassen sich komprimiert übertragen.

Ein CDN kann solche Optimierungen teilweise übernehmen.

Dadurch muss der Origin nicht jede Funktion selbst bereitstellen.

Je nach Plattform können außerdem automatische Optimierungen für Bilder oder andere Ressourcen angeboten werden.

Das klingt bequem – sollte aber nicht dazu führen, dass niemand mehr weiß, wo welche Optimierung stattfindet.

Zu viele automatische Optimierungen können Probleme erzeugen

Angenommen:

WordPress optimiert JavaScript.

Ein Performance-Plugin macht dasselbe.

Der Hoster besitzt ebenfalls eine Optimierungsschicht.

Das CDN versucht zusätzlich, Dateien zusammenzufassen oder umzuschreiben.

Nun existieren vier Systeme, die dieselben Ressourcen verändern.

Wenn etwas nicht funktioniert, wird die Fehlersuche schwierig.

Deshalb gilt auch beim CDN:

Nur Funktionen aktivieren, deren Aufgabe im System klar ist.

Ein CDN kann den Origin deutlich entlasten

Nehmen wir eine große Wissensseite.

Sie erhält täglich 100.000 Seitenaufrufe.

Wenn 90 Prozent der Anfragen bereits am CDN beantwortet werden, erreicht nur ein Bruchteil den eigentlichen WordPress-Server.

Das kann bedeuten:

weniger CPU,

weniger Datenbanklast,

weniger Traffic am Origin,

weniger Lastspitzen.

Ein kleinerer Server kann dadurch mehr Besucher bedienen.

Caching wird somit auch zu einem Kostenfaktor.

Cache Hit Ratio beschreibt die Cache-Nutzung

Ein interessanter Wert ist die Cache Hit Ratio.

Sie beschreibt vereinfacht, welcher Anteil der Anfragen aus dem Cache beantwortet wird.

Angenommen:

100.000 Anfragen treffen beim CDN ein.

80.000 werden aus dem Cache beantwortet.

20.000 müssen zum Origin.

Dann ist der Cache ein wesentlicher Teil der Auslieferungsarchitektur.

Ein niedriger Wert muss allerdings nicht automatisch schlecht sein.

Bei stark personalisierten Anwendungen lässt sich naturgemäß weniger gemeinsam cachen.

Die ideale Cache-Hit-Rate hängt vom Projekt ab

Eine statische Dokumentationsseite könnte extrem hohe Cache-Raten erreichen.

Ein Benutzer-Dashboard vielleicht fast keine.

Beides kann vollkommen korrekt sein.

Auch hier zeigt sich ein wiederkehrendes Prinzip unserer Performance-Serie:

Messwerte brauchen Kontext.

Eine hohe Zahl ist nur dann gut, wenn sie zur Aufgabe passt.

Cache Keys entscheiden, wann zwei Anfragen gleich sind

Ein CDN muss bestimmen können, ob zwei Anfragen dieselbe Cache-Antwort verwenden dürfen.

Dabei können beispielsweise berücksichtigt werden:

URL,

Query-Parameter,

Cookies,

Header.

Diese Kombination wird sinngemäß Teil des Cache Keys.

Eine schlechte Konfiguration kann dazu führen, dass fast jede Anfrage eine eigene Cache-Variante erzeugt.

Dann sinkt der Nutzen des Caches.

Oder unterschiedliche Anfragen werden fälschlich zusammengelegt.

Dann kann die Antwort sogar falsch werden.

Query-Parameter können den Cache fragmentieren

Angenommen, dieselbe Seite wird aufgerufen als:

/artikel/
/artikel/?utm_source=a
/artikel/?utm_source=b

Inhaltlich kann es dieselbe Seite sein.

Wenn das CDN alle Varianten getrennt behandelt, entstehen mehrere Cache-Einträge.

Bei hunderten Trackingparametern kann das den Cache unnötig fragmentieren.

Eine gute Konfiguration entscheidet deshalb bewusst, welche Parameter für den Inhalt tatsächlich relevant sind.

Aber Parameter dürfen nicht einfach ignoriert werden

Ein Shop könnte beispielsweise eine URL verwenden, bei der ein Parameter tatsächlich den angezeigten Inhalt verändert.

Würde das CDN ihn ignorieren, könnten falsche Inhalte ausgeliefert werden.

Auch hier gilt:

Cache-Regeln müssen die Anwendung verstehen.

Blindes „maximal cachen“ kann gefährlich sein.

Was bedeutet Origin Shield?

Größere CDN-Architekturen können zwischen Edge-Standorten und Origin noch eine weitere Cache-Schicht verwenden.

Die Idee:

Viele Edge-Server müssen dieselbe Ressource nicht jeweils separat beim Origin anfordern.

Stattdessen gibt es eine zentrale oder regionale Zwischenschicht.

Vereinfacht:

Edge A ─┐
Edge B ─┼→ Shield Cache → Origin
Edge C ─┘

Dadurch kann die Last auf dem Origin weiter sinken.

Für eine kleine WordPress-Seite muss man dieses Konzept nicht zwingend benötigen. Es zeigt aber, wie weit Caching in großen Plattformen gestaffelt werden kann.

Was ist Edge Computing?

Moderne CDN-Plattformen beschränken sich teilweise nicht mehr auf das Speichern von Dateien.

Sie können Programmcode direkt an ihren Edge-Standorten ausführen.

Damit lassen sich beispielsweise:

Weiterleitungen,

Authentifizierungsprüfungen,

Personalisierungen,

API-Logik

oder andere Funktionen

näher am Benutzer ausführen.

Diese Entwicklung wird häufig unter Edge Computing zusammengefasst.

Ein CDN wird dadurch teilweise selbst zu einer Anwendungsplattform.

Für normale Websites reicht das Caching-Verständnis

Es ist nicht notwendig, eine einfache WordPress-Seite sofort in eine globale Edge-Anwendung zu verwandeln.

Für die meisten Betreiber sind zunächst vier Fragen entscheidend:

Kommt der Besucher über das CDN?

Welche Inhalte werden dort gecacht?

Wann werden sie invalidiert?

Was passiert, wenn das CDN oder der Origin nicht erreichbar ist?

Wer diese vier Fragen beantworten kann, versteht bereits einen großen Teil der praktischen Architektur.

Was passiert, wenn das CDN ausfällt?

Wenn sämtlicher öffentlicher Traffic über das CDN geführt wird und der Dienst Probleme hat, kann die Website unter Umständen ebenfalls nicht erreichbar sein – selbst wenn der Origin perfekt funktioniert.

Das CDN beseitigt also nicht jede Abhängigkeit.

Es verschiebt einen Teil davon.

Große CDN-Anbieter bauen ihre Infrastruktur entsprechend redundant auf.

Trotzdem sollte man verstehen, dass jede zusätzliche zentrale Komponente einen neuen möglichen Fehlerpunkt darstellt.

Kann man das CDN einfach umgehen?

Technisch hängt das von der Architektur ab.

Wenn der Origin öffentlich direkt erreichbar bleibt, könnte man grundsätzlich auch direkt dorthin zugreifen.

Das kann für Tests praktisch sein.

Für die Sicherheit kann es aber unerwünscht sein.

Manche Architekturen erlauben deshalb am Origin nur noch Verbindungen aus bekannten CDN-Netzen oder über private Verbindungen.

Dann wird das CDN tatsächlich zum kontrollierten Eingang zur Website.

CDN und WordPress funktionieren gut zusammen

Ein typisches WordPress-Setup könnte beispielsweise so aussehen:

Besucher
↓
CDN
↓
Webserver
↓
PHP
↓
WordPress
↓
Datenbank

Das CDN kann statische Ressourcen und möglicherweise HTML cachen.

WordPress bleibt weiterhin das Content-Management-System.

Der Redakteur veröffentlicht einen Artikel im WordPress-Backend.

Das Cache-System sorgt anschließend dafür, dass Besucher die neue Fassung effizient erhalten.

WordPress muss Cache-Änderungen dem CDN mitteilen können

Wenn ein Artikel geändert wird, soll die alte CDN-Version verschwinden.

Dafür können Hostingplattformen, Plugins oder APIs eingesetzt werden.

Eine gute Integration invalidiert gezielt die betroffenen URLs.

Dadurch muss nicht nach jeder Textkorrektur die komplette Website aus dem weltweiten Cache gelöscht werden.

Gerade bei großen Websites ist diese gezielte Invalidierung wichtig.

Ein CDN kann keinen langsamen WordPress-Adminbereich reparieren

Das Backend ist in der Regel dynamisch und benutzerspezifisch.

Es wird normalerweise nicht wie ein öffentlicher Artikel komplett gecacht.

Wenn /wp-admin/ langsam ist, können Ursachen beispielsweise sein:

Datenbank,

Plugins,

PHP,

Serverressourcen,

externe API-Aufrufe.

Ein CDN bringt dort häufig wenig.

Das ist ein gutes Beispiel dafür, warum Performanceprobleme zuerst eingeordnet werden müssen.

Ein CDN kann schlechte Datenbankabfragen verstecken

Die öffentliche Seite läuft plötzlich extrem schnell, weil fast alle Besucher aus dem CDN-Cache bedient werden.

Beim ersten Cache Miss benötigt WordPress allerdings fünf Sekunden.

Auch das Backend ist langsam.

Die eigentliche Anwendung bleibt also ineffizient.

Das muss nicht zwangsläufig kritisch sein, solange die Architektur bewusst darauf ausgelegt ist.

Man sollte es aber wissen.

Cache ist eine Optimierung.

Er sollte nicht dazu führen, dass grundlegende Probleme unbemerkt wachsen.

Ein CDN kann LCP verbessern

Bei Core Web Vitals haben wir gesehen, dass LCP aus mehreren Zeitanteilen besteht.

Ein CDN kann beispielsweise helfen, indem es:

HTML schneller bereitstellt,

das LCP-Bild geografisch näher ausliefert,

Origin-Antworten cached,

Netzwerkwege optimiert.

Der Effekt hängt davon ab, welcher Teil des LCP tatsächlich langsam ist.

Wenn JavaScript das Titelbild erst nach fünf Sekunden in die Seite einfügt, kann auch das schnellste CDN die grundlegende Ursache nicht beseitigen.

Ein CDN hilft CLS normalerweise nicht direkt

CLS entsteht durch Layoutverschiebungen.

Ein CDN kann Inhalte schneller liefern und dadurch manche sichtbaren Effekte reduzieren.

Die eigentliche Lösung besteht aber häufig darin:

Platz für Bilder reservieren,

dynamische Elemente stabil einbauen,

Fonts sinnvoll behandeln.

Ein CDN ist deshalb kein universelles Core-Web-Vitals-Werkzeug.

Jede Metrik besitzt eigene Ursachen.

Bei INP ist der Nutzen ebenfalls begrenzt

INP betrifft die Reaktion auf Benutzerinteraktionen.

Wenn der Browser durch umfangreiches JavaScript blockiert wird, hilft ein CDN nur teilweise.

Die JavaScript-Datei wurde vielleicht schneller heruntergeladen.

Der Browser muss sie trotzdem ausführen.

Auch hier kann die eigentliche Optimierung darin bestehen, weniger oder effizienteren Code auszuführen.

Wann bringt ein CDN besonders viel?

Ein CDN wird besonders interessant, wenn eine Website ein geografisch weit verteiltes Publikum besitzt, viele statische Dateien oder Bilder ausliefert, hohen Traffic hat oder durch Caching erhebliche Origin-Arbeit einsparen kann.

Auch Sicherheitsanforderungen können ein wichtiger Grund sein.

Bei einer kleinen lokalen Website mit sehr geringem Traffic und bereits schnellem Hosting kann der messbare Performancegewinn dagegen gering sein.

Das macht ein CDN dort nicht falsch.

Nur möglicherweise unnötig.

Wann kann ein CDN sogar zusätzlichen Aufwand erzeugen?

Jede neue Infrastrukturkomponente muss konfiguriert und verstanden werden.

Mit einem CDN kommen beispielsweise hinzu:

weitere DNS-Konfiguration,

Cache-Regeln,

TLS-Einstellungen,

Purge-Mechanismen,

Fehlersuche über mehrere Ebenen.

Für eine einfache Website kann ein schlecht verstandenes CDN mehr Verwirrung erzeugen als Nutzen.

Technische Architektur sollte deshalb nicht nach dem Motto aufgebaut werden:

Mehr Komponenten wirken professioneller.

Die beste Infrastruktur ist die einfachste, die die Aufgabe zuverlässig erfüllt.

Ein kostenloses CDN kann vollkommen ausreichen

Für viele Websites sind grundlegende CDN-Funktionen bereits in kostenlosen oder sehr günstigen Angeboten verfügbar.

Teurere Tarife können zusätzliche Funktionen bieten wie:

erweiterte Sicherheitsregeln,

mehr Analysen,

umfangreicheres Bot-Management,

spezialisierte Performancefunktionen,

mehr Kontrolle.

Welche Stufe sinnvoll ist, hängt von Traffic, Schutzbedarf und Geschäftsmodell ab.

Ein Wissensblog benötigt nicht automatisch dieselbe Infrastruktur wie eine globale Handelsplattform.

CDN-Kosten können anders entstehen als Hostingkosten

Bei manchen Diensten werden Kosten anhand von übertragenen Daten, Anfragen oder zusätzlichen Funktionen berechnet.

Eine Website mit vielen großen Downloads kann deshalb eine andere Kostenstruktur haben als eine reine Textseite.

Bei sehr hohem Traffic sollte nicht nur geprüft werden:

Wie schnell ist das CDN?

Sondern auch:

Was kostet die tatsächliche Nutzung bei meinem Datenvolumen?

Performance und Wirtschaftlichkeit gehören zusammen.

CDN-Statistiken können bei der Fehlersuche helfen

Viele Plattformen zeigen Informationen über:

Anfragen,

Bandbreite,

Cache Hits,

Cache Misses,

Fehler,

Herkunftsregionen.

Damit lässt sich beispielsweise erkennen, ob tatsächlich große Mengen Traffic vom Origin ferngehalten werden.

Oder ob praktisch jede Anfrage einen Cache Miss produziert.

Ein CDN sollte nicht nur eingerichtet, sondern auch verstanden werden.

Logs können zusätzlich wertvoll sein

Bei größeren Projekten können CDN-Logs zeigen:

welche URLs besonders häufig aufgerufen werden,

welche Statuscodes auftreten,

wie Cache-Regeln greifen,

welche Regionen Traffic erzeugen.

Das kann für Performance, Sicherheit und Betriebsanalyse wertvoll sein.

Je umfangreicher die Protokollierung wird, desto stärker müssen allerdings auch Datenschutz und Aufbewahrung berücksichtigt werden.

Das CDN sollte nicht das einzige Performancekonzept sein

Eine schnelle Website entsteht weiterhin aus mehreren Ebenen.

Vereinfacht:

gutes Hosting
+
sauberes WordPress
+
sinnvolle Plugins
+
optimierte Bilder
+
Caching
+
bei Bedarf CDN

Wenn die ersten fünf Punkte schlecht umgesetzt sind, sollte das CDN nicht als Reparaturpflaster verwendet werden.

Je sauberer der Origin arbeitet, desto robuster wird auch die CDN-Architektur.

CDN oder stärkerer Server?

Diese Frage lässt sich nicht pauschal beantworten.

Wenn die Website langsam ist, weil eine sehr rechenintensive dynamische Anwendung bei jedem Benutzer individuell verarbeitet wird, kann mehr Serverleistung helfen.

Wenn tausende Besucher dieselben unveränderten Dateien anfordern, kann ein CDN wesentlich effizienter sein.

Wenn das Problem ein gigantisches Titelbild ist, sollte zunächst das Bild optimiert werden.

Wie immer gilt:

Der Engpass entscheidet über die Lösung.

CDN oder Cache-Plugin?

Auch das ist kein Entweder-oder.

Ein WordPress-Cache kann fertige Seiten am Origin erzeugen.

Das CDN kann diese Seiten anschließend weltweit verteilen.

Beide Ebenen können also zusammenarbeiten.

Problematisch wird es nur, wenn zwei Systeme dieselbe Aufgabe unterschiedlich behandeln und die Cache-Invalidierung nicht sauber abgestimmt ist.

Klare Zuständigkeiten sind wichtiger als die Zahl der eingesetzten Werkzeuge.

CDN oder Bildoptimierungsdienst?

Ein klassisches CDN verteilt vorhandene Dateien.

Ein Image-CDN kann zusätzlich Bilder dynamisch umrechnen.

Zum Beispiel:

Original:

4000 × 3000 Pixel

Besucher A erhält:

640 Pixel WebP

Besucher B:

1280 Pixel AVIF

Damit verschmelzen CDN und Bildoptimierung zunehmend.

Für große Medienprojekte kann das hervorragend funktionieren.

Für kleinere Websites ist es möglicherweise komfortabler, die Varianten bereits in WordPress zu erzeugen.

Ein CDN verändert nicht die Informationsarchitektur

Ein weiterer wichtiger Punkt:

Ein CDN hat nichts damit zu tun, ob eine Website sinnvoll strukturiert ist.

Es verbessert nicht:

Navigation,

Inhalt,

interne Verlinkung,

Suchintention,

Textqualität.

Es beschleunigt technische Auslieferung und kann Infrastruktur schützen.

Damit ist es ein wichtiges Werkzeug – aber ausschließlich innerhalb seiner eigenen Aufgabe.

CDN ist kein SEO-Trick

Auch ein CDN garantiert keine besseren Rankings.

Eine schnelle und zuverlässige Website kann eine bessere Nutzererfahrung bieten und technische Probleme reduzieren.

Aber Suchmaschinen bewerten Inhalte nicht danach, ob das Logo von einem CDN-Edge geladen wurde.

Ein CDN sollte eingesetzt werden, weil es ein reales technisches Problem löst.

Nicht weil irgendwo behauptet wird, jede SEO-Seite brauche zwingend eines.

Die Entscheidung kann später getroffen werden

Eine neue Website muss nicht vom ersten Tag an sämtliche denkbaren Skalierungsstufen besitzen.

Man kann mit gutem Hosting beginnen.

Traffic messen.

Performance beobachten.

Später ein CDN ergänzen.

Das ist häufig sinnvoller, als bereits für Millionen Besucher zu bauen, bevor überhaupt die ersten hundert da sind.

Moderne Infrastruktur lässt sich erweitern.

Ein CDN kann für viele Websites zentral eingesetzt werden

Wer zahlreiche Websites betreibt, kann eine gemeinsame CDN- beziehungsweise Proxy-Schicht besonders interessant finden.

Dort können zentral geregelt werden:

HTTPS,

Caching,

Sicherheitsregeln,

DDoS-Schutz,

Weiterleitungen,

Monitoring.

Dadurch müssen bestimmte Funktionen nicht auf jedem einzelnen WordPress-System separat implementiert werden.

Gleichzeitig steigt die Bedeutung dieser zentralen Ebene.

Eine Fehlkonfiguration kann dann mehrere Websites gleichzeitig betreffen.

Zentralisierung spart Arbeit und erhöht die Tragweite von Fehlern

Das ist ein allgemeines Infrastrukturprinzip.

Hundert unabhängig konfigurierte Systeme erzeugen viel Verwaltungsaufwand.

Eine zentrale Plattform reduziert diesen Aufwand.

Fällt die zentrale Plattform aus oder wird falsch konfiguriert, sind dafür möglicherweise hundert Systeme betroffen.

Die richtige Architektur versucht deshalb, Standardisierung mit ausreichender Isolation und Wiederherstellbarkeit zu kombinieren.

Wie erkenne ich, ob meine Website ein CDN braucht?

Statt nach einer pauschalen Empfehlung zu suchen, sollte man die eigenen Anforderungen betrachten.

Eine einfache Entscheidung lässt sich aus vier Fragen ableiten: Wo sitzen die Besucher? Wie viel statischer oder cachebarer Traffic entsteht? Ist der Origin bereits schnell genug? Brauche ich zusätzliche Schutz- oder Edge-Funktionen?

Wenn fast sämtliche Besucher in derselben Region sitzen, die Website wenig Traffic hat und der Server sehr schnell antwortet, besteht kein dringender Grund.

Wenn Besucher weltweit verteilt sind, große Mengen an Medien ausgeliefert werden oder der Origin durch viele wiederholte identische Anfragen belastet wird, wird ein CDN deutlich interessanter.

Messen vor und nach der Einführung

Wie bei allen Performanceänderungen sollte auch ein CDN nicht allein nach Gefühl beurteilt werden.

Vorher können gemessen werden:

Antwortzeiten,

LCP,

Datenübertragung,

Origin-Last,

Ladezeiten aus unterschiedlichen Regionen.

Danach werden dieselben Werte erneut betrachtet.

So lässt sich erkennen, ob das CDN tatsächlich etwas verbessert.

Vielleicht sinkt die globale Ladezeit deutlich.

Vielleicht verändert sich für die lokale Zielgruppe fast nichts.

Beide Ergebnisse sind nützlich.

Ein CDN sollte wieder entfernbar sein

Eine robuste Architektur sollte möglichst nicht unnötig vollständig von einem einzelnen CDN-Anbieter abhängen.

Domain, Origin und Anwendung sollten so dokumentiert sein, dass ein Wechsel prinzipiell möglich bleibt.

Je mehr proprietäre Funktionen direkt in der CDN-Plattform umgesetzt werden, desto schwieriger kann ein späterer Umzug werden.

Das bedeutet nicht, dass solche Funktionen vermieden werden müssen.

Ihre Abhängigkeit sollte lediglich bewusst sein.

Dokumentation wird bei mehreren Ebenen wichtiger

Ohne CDN lautet die Architektur vielleicht:

Domain
↓
Webserver
↓
WordPress

Mit CDN entsteht:

Domain
↓
CDN
↓
Firewall / Cache
↓
Origin
↓
Webserver
↓
WordPress

Nun gibt es mehr Stellen, an denen ein Fehler entstehen kann.

Deshalb sollte dokumentiert sein:

Wo wird DNS verwaltet?

Welche Cache-Regeln gelten?

Wie wird ein Purge durchgeführt?

Wie lautet der Origin?

Welche Zertifikate existieren?

Wer besitzt Zugriff?

Eine gute Dokumentation macht zusätzliche Komplexität beherrschbar.

Was du dir über CDNs merken solltest

Ein CDN ist eine geografisch verteilte Infrastruktur zwischen Besucher und ursprünglichem Webserver.

Der eigentliche Webserver wird als Origin bezeichnet.

Die verteilten Standorte arbeiten an der Edge.

Dort können Inhalte zwischengespeichert und direkt an Besucher ausgeliefert werden.

Dadurch kann ein CDN Netzwerkwege verkürzen, Origin-Last reduzieren, hohe Besucherzahlen besser abfangen und zusätzliche Sicherheitsfunktionen bereitstellen.

Besonders gut lassen sich statische und identische Inhalte cachen.

Komplette HTML-Seiten können je nach Architektur ebenfalls am Edge gespeichert werden.

Personalisierte Inhalte wie Warenkörbe und Benutzerkonten benötigen dagegen besondere Regeln.

Und vor allem:

Ein CDN ist kein Ersatz für gutes Hosting, kleine Bilder, sauberen Code oder funktionierendes Caching.

Es ist eine zusätzliche Auslieferungsebene.

Seinen größten Nutzen entfaltet es dann, wenn klar ist, welches konkrete Problem diese Ebene lösen soll.