CDN für WordPress: Worauf es bei der Auswahl ankommt

Für WordPress gibt es zwei Arten von CDN: ein Asset-CDN, das per Plugin die Adressen deiner Bilder, CSS- und JavaScript-Dateien umschreibt, und einen Full-Site-Proxy, der vor deiner kompletten Domain sitzt und auch die HTML-Seiten selbst zwischenspeichern kann. Welches besser passt, hängt davon ab, wo deine Website Zeit verliert, woher deine Besucher kommen und wie viel du an deinem DNS ändern möchtest. Hier erfährst du, worin sich beide Typen unterscheiden und worauf du bei der Wahl des Anbieters achten solltest.

Die Grundlagen erklärt der Ratgeber Was ist ein CDN?. Weißt du noch nicht, warum deine Seite langsam ist, such zuerst die Ursache: Dabei hilft dir WordPress schneller machen.

Zwei Arten von CDN für WordPress

Asset-CDN: statische Dateien per Plugin

Ein Asset-CDN liefert nur statische Dateien aus. Beim Anbieter legst du eine Pull Zone an und bekommst dafür einen Hostnamen wie cdn.example.com. Ein WordPress-Plugin schreibt dann die Adressen im HTML um, sodass Dateien aus wp-content und wp-includes von diesem Hostnamen geladen werden. Beim ersten Abruf holt sich das CDN jede Datei von deinem Server und behält eine Kopie.

Domain, DNS und HTML bleiben, wo sie sind. Jeder Seitenaufruf landet weiterhin bei deinem Hoster, der das HTML wie gewohnt erzeugt. Nur die Dateien, die in der Seite eingebunden sind, kommen aus dem CDN.

Full-Site-Proxy: die ganze Domain über Nameserver oder DNS

Ein Full-Site-Proxy übernimmt den gesamten Traffic deiner Domain. Je nach Anbieter stellst du dafür die Nameserver um oder lässt deine Domain per DNS auf ihn zeigen. Danach läuft jede Anfrage, auch die nach dem HTML, zuerst über die Edge-Server des Anbieters. Was gecacht werden darf, liefert der Edge direkt aus, alles andere reicht er an dein Hosting weiter.

Weil der komplette Traffic durch ihn fließt, kann ein Full-Site-Proxy das HTML öffentlicher Seiten cachen, HTTPS übernehmen und Angriffe abfangen, bevor sie deinen Server erreichen. Der Eingriff ist allerdings größer, denn deine ganze Website hängt jetzt davon ab, dass der Proxy richtig eingerichtet ist.

Was welcher Typ zwischenspeichert

Der entscheidende Unterschied ist das HTML. Bei einer typischen WordPress-Seite kostet vor allem die Arbeit auf dem Server Zeit, denn PHP und Datenbank bauen jede Seite neu zusammen. Daran ändert ein Asset-CDN nichts. Die Time to First Byte bleibt also gleich.

Ein Full-Site-Proxy kann dieses HTML für anonyme Besucher direkt vom Edge ausliefern, ganz ohne PHP und Datenbank. Deshalb bringt dieser Typ am meisten, wenn die TTFB hoch ist oder dein Server in Stoßzeiten in die Knie geht.

Dateien wie Bilder und Skripte cachen beide Typen. Baut dein Server die Seiten schon schnell (etwa dank eines guten Seiten-Caches) und warten deine Besucher vor allem auf große Dateien, kann ein Asset-CDN bereits einen großen Teil abdecken.

Vor- und Nachteile im Alltag

Wann ein Asset-CDN reicht

• Dein Server antwortet schon schnell, und große Bilder oder Skripte bremsen die Seite.
• Du kannst oder willst Nameserver und DNS deiner Domain nicht anfassen.
• Du möchtest eine Änderung, die du mit einem Klick auf „Deaktivieren“ im Plugin rückgängig machst.

Rechne mit ein paar typischen Nebenwirkungen. Dateien, die fest im Theme, im CSS eines Page Builders oder in Inline-Styles stehen, schreibt das Plugin oft nicht um, und sie kommen weiter von deinem Server. Webfonts von einem fremden Hostnamen brauchen einen passenden Access-Control-Allow-Origin-Header, sonst verwirft der Browser sie. Außerdem hängt WordPress an eingebundene Skripte und Stylesheets einen ?ver=-Parameter. Das CDN muss diesen Query-String im Cache-Schlüssel berücksichtigen, sonst sehen deine Besucher nach einem Update weiterhin die alte Datei.

Wann sich ein Full-Site-Proxy lohnt

• Deine öffentlichen Seiten haben eine hohe TTFB, oder der Server wird beim Newsletter-Versand oder im Sale langsam.
• Deine Besucher kommen aus mehreren Ländern oder Kontinenten.
• Du willst DDoS-Schutz und HTTPS vor deinem Hosting abwickeln.

Dafür nimmst du aber auch einiges in Kauf. Die Ausnahmen müssen sitzen, damit nie eine persönliche Seite für alle gecacht wird. Nach jedem neuen oder geänderten Beitrag muss das gecachte HTML erneuert werden. Dein Server sieht jetzt den Proxy als Absender, also müssen Sicherheits- und Statistik-Plugins die echte IP des Besuchers aus dem Header lesen, den der Anbieter mitschickt. Und wer die IP-Adresse deines Servers kennt, kann den Edge weiterhin umgehen, es sei denn, dein Server nimmt nur Anfragen vom Proxy an.

Checkliste für die Auswahl

Mit diesen Fragen vergleichst du Anbieter, ganz gleich, wie sie heißen.

HTML-Caching und Ausnahmen

Kann das CDN HTML cachen, und woran erkennt es, was es auslassen muss? Bei WordPress muss Folgendes immer ungecacht bei deinem Server ankommen:

• /wp-admin/, wp-login.php und admin-ajax.php
• Besucher mit einem wordpress_logged_in_-Cookie (alle Cookies von WordPress findest du in der Cookie-Übersicht auf developer.wordpress.org)
• Kommentierende mit einem comment_author_-Cookie, damit sie ihren eigenen Kommentar in der Moderation sehen
• Passwortgeschützte Beiträge, erkennbar am wp-postpass_-Cookie
• Beitragsvorschauen und alles Personalisierte, im Shop etwa Warenkorb und Kundenkonto

WordPress nimmt dir dabei schon einiges ab. Für eingeloggte Nutzer, passwortgeschützte Beiträge und 404-Seiten schickt es Cache-Control: no-cache, must-revalidate, max-age=0, no-store, private. Ein Proxy, der Cache-Control beachtet, lässt diese Antworten also durch. Riskant sind Plugins, die Seiten personalisieren, ohne solche Header zu senden. Teste sie deshalb gezielt.

Cache leeren nach dem Veröffentlichen

Aktualisierst du einen Beitrag, ändert sich nicht nur der Beitrag selbst, sondern auch die Startseite, die Kategorie- und Schlagwort-Archive und der Feed. Frag nach, wie du den Cache leerst: für einzelne URLs, für die ganze Domain, im Dashboard, per API? Ob das automatisch beim Veröffentlichen passiert, hängt vom Anbieter und deinem Setup ab. Ohne Automatik brauchst du eine kurze Cache-Dauer oder eine feste Routine nach jeder Änderung.

Bildoptimierung

Wandelt das CDN Bilder in WebP oder AVIF um, und bekommen Browser ohne Unterstützung für das neue Format weiterhin das Original? Das kann dir ein Bild-Plugin sparen, das sonst auf deinem Server rechnet.

SSL zwischen Besucher, Edge und Server

Beim Asset-CDN braucht der CDN-Hostname ein eigenes Zertifikat. Beim Full-Site-Proxy liegt das Zertifikat für deine Domain auf dem Edge. Achte darauf, dass auch die Verbindung vom Edge zu deinem Server über HTTPS läuft. Spricht der Proxy nur HTTP mit einer WordPress-Seite, die HTTPS erzwingt, kann eine endlose Weiterleitungsschleife entstehen. Die HTTPS-Dokumentation von WordPress beschreibt genau diesen Fall.

Sicherheit und DDoS-Schutz

Ein Asset-CDN schützt nur die Dateien, die es ausliefert. Angriffe auf deine Seiten, den Login oder XML-RPC treffen weiterhin direkt deinen Server. Ein Full-Site-Proxy kann Anfragefluten abwehren, Länder oder IP-Bereiche sperren und auffällige Clients am Edge drosseln. Prüf, was in deinem Tarif enthalten ist und was extra kostet.

Edge-Standorte in der Nähe deiner Besucher

Gegen lange Wege hilft ein CDN nur, wenn es Edge-Server in der Nähe deiner Besucher hat. Schau dir an, woher deine Besucher tatsächlich kommen, und prüf dann, welche Regionen der Anbieter in deinem Tarif abdeckt.

Aufwand bei der Einrichtung, DNS und E-Mail

Für ein Asset-CDN trägst du einen Hostnamen im Plugin ein und legst eventuell einen CNAME-Eintrag an. Beim Full-Site-Proxy zieht dein DNS meist zum Anbieter um. Dort muss dann vor dem Wechsel jeder Eintrag vorhanden sein, auch die MX-Einträge für deine E-Mails und die TXT-Einträge für SPF, DKIM und Domain-Verifizierungen. Wie das ohne Ausfall klappt, zeigt die Checkliste Nameserver ändern.

Transparenz

Achte auf einen Response-Header, der bei jeder Anfrage Hit, Miss oder Bypass anzeigt, und auf Statistiken zu Cache-Trefferquote, Traffic vom Edge und vom Origin sowie Fehlerraten. Ohne diese Daten weißt du nicht, ob das CDN überhaupt etwas bringt.

Vorher und nachher messen

Verlass dich bei einem CDN nicht auf dein Gefühl. Halte vor dem Wechsel einen Ausgangswert fest:

1. Prüf Startseite, einen Beitrag und eine Archivseite mit corewebvitals.page. Notier dir die Felddaten echter Nutzer (sofern deine Seite genug Traffic hat) und die Lighthouse-Ergebnisse für Mobil und Desktop.
2. Miss die Antwortzeit des HTML von deinem eigenen Rechner aus:

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://example.com/

3. Ruf nach dem Wechsel dieselbe Seite zweimal auf und schau dir die Header an. Beim zweiten Mal sollte ein Cache-Hit erscheinen.

curl -sI https://example.com/ | grep -i -E "cache|age"

4. Log dich ein und kontrolliere, dass wp-admin und das Frontend einen Bypass zeigen und keinen Hit.
5. Vergleiche die Felddaten erneut, sobald sie nachgezogen haben, denn sie umfassen die letzten 28 Tage.

Wie du so einen Vergleich sauber aufsetzt, erklärt der Ratgeber Ladezeit richtig messen.

So hilft dir fast.site

fast.site ist ein Full-Site-Proxy und sitzt vor deinem bestehenden WordPress-Hosting. Hoster und Website behältst du. Du fügst deine Domain im Dashboard hinzu, stellst die Nameserver auf fast.site um und bestätigst den Wechsel. Ab dann verwaltet fast.site dein DNS, deshalb müssen alle bestehenden Einträge, auch die MX-Einträge für E-Mail, in der DNS-Zone bei fast.site stehen.

Fast Edge Cache™ liefert öffentliche Seiten und Dateien von Edge-Servern in den Regionen aus, die dein Tarif umfasst. fast.site beachtet die Cache-Control-Header deiner WordPress-Seite, und der Response-Header fs-cache zeigt HIT, MISS oder BYPASS. So prüfst du selbst, dass wp-admin und eingeloggte Sitzungen am Cache vorbeigehen. Nach dem Veröffentlichen leerst du den Cache für einzelne URLs oder die ganze Domain im Dashboard, samt Protokoll, oder per API aus deinen eigenen Skripten.

JPEG- und PNG-Bilder wandelt fast.site für Browser, die es unterstützen, direkt in WebP um, je nach Tarif auch in AVIF. Jede Domain bekommt automatische Layer-7-DDoS-Erkennung und kostenlose SSL-Zertifikate, die sich selbst erneuern. Mehr dazu findest du auf der WordPress-Seite und in der Caching-Dokumentation.

Miss deine Seite vorher und nachher mit denselben Seiten und Tools. Du kannst fast.site in einer kostenlosen 7-Tage-Testphase ausprobieren.

Häufige Fragen

Brauche ich ein CDN-Plugin für WordPress?

Nur für ein Asset-CDN, denn dort schreibt das Plugin die Dateiadressen auf den CDN-Hostnamen um. Ein Full-Site-Proxy arbeitet auf DNS-Ebene und muss nichts umschreiben, weil deine Domain gleich bleibt. Manche Anbieter bieten trotzdem ein Plugin an, etwa zum Leeren des Caches.

Ersetzt ein CDN mein Caching-Plugin?

Nicht unbedingt. Ein Seiten-Cache auf dem Server beschleunigt alle Anfragen, die am CDN vorbeigehen, und den gesamten Traffic eingeloggter Nutzer. Die Cache-Dokumentation von WordPress beschreibt diese Ebenen. Mit einem Full-Site-Proxy verliert er für anonyme Besucher an Gewicht, schaden tut er aber selten.

Funktionieren wp-admin und der Login mit einem CDN noch?

Ja, solange wp-admin, die Login-Seite und eingeloggte Besucher am Cache vorbeigehen. WordPress schickt für eingeloggte Nutzer ohnehin No-Cache-Header. Teste es nach der Einrichtung trotzdem: Log dich ein, bearbeite einen Beitrag und prüf den Cache-Header im Adminbereich.

Warum sehe ich meine Änderungen nach dem Aktualisieren eines Beitrags nicht?

Das CDN liefert noch die gecachte Kopie aus. Leere den Cache für die Beitrags-URL und für die Seiten, die den Beitrag auflisten, etwa die Startseite und die Kategorie-Archive. Bei CSS und JavaScript prüfst du, ob das CDN den ?ver=-Parameter im Cache-Schlüssel berücksichtigt.