← Zurück zum Glossar
webentwicklung

CDN

Content Delivery Network — geografisch verteilte Serverinfrastruktur, die statische Inhalte näher am Nutzer ausliefert und damit Ladezeiten reduziert.

Aktualisiert: 23. Februar 2026

Was ist ein CDN?

Ein Content Delivery Network (CDN) ist ein Netzwerk geografisch verteilter Server (Edge-Nodes oder Points of Presence, PoPs), die Inhalte näher am Nutzer zwischenspeichern und ausliefern. Statt dass alle Anfragen nach Frankfurt reisen, antwortet für einen Nutzer in Sydney ein Server in Sydney — mit dem gleichen Inhalt, den der Origin-Server in Frankfurt bereitstellt, aber mit einem Bruchteil der Latenz.

Für WordPress-Seiten mit globalem Publikum ist ein CDN der effektivste einzelne Hebel für Performance-Verbesserungen. Aber auch für primär nationale Seiten bieten CDNs DDoS-Schutz, Redundanz und Entlastung des Origin-Servers.

Kurzprofil CDN

Kurzprofil

  • Typ: Infrastruktur-Dienst
  • Hauptvorteil: Reduzierte Latenz durch geografische Nähe, Schutz vor DDoS
  • Typische Anbieter: Cloudflare, BunnyCDN, AWS CloudFront, Fastly, KeyCDN
  • Was wird gecacht: Statische Dateien (Bilder, CSS, JS), oft auch dynamische Inhalte
  • Relevanz für WordPress/Web: Hoch

Wie funktioniert ein CDN?

Das grundlegende Prinzip ist Edge-Caching:

  1. Nutzer in Tokio ruft https://example.com/bild.jpg ab.
  2. CDN-DNS leitet die Anfrage an den nächsten PoP (z.B. Tokyo-Datacenter) weiter.
  3. Ist das Bild dort gecacht und nicht abgelaufen (TTL): Sofortige Auslieferung aus dem Cache.
  4. Ist es nicht gecacht: Edge-Node holt die Datei vom Origin-Server in Frankfurt (Origin Pull), cached sie lokal, liefert aus.
  5. Folgeanfragen aus Tokio: Direkt aus Cache.

Moderne CDNs gehen weit über statisches File-Serving hinaus:

CDN als Reverse Proxy: Cloudflare und andere CDNs können als vollständiger Reverse Proxy vor dem Origin-Server agieren — alle HTTP-Requests laufen durch das CDN. Das ermöglicht:

  • WAF (Web Application Firewall): Angriffs-Traffic wird am Edge gefiltert
  • DDoS-Mitigation: Volumetrische Angriffe werden absorbiert bevor sie den Origin erreichen
  • HTTP/3 am Edge: Auch wenn der Origin nur HTTP/2 spricht
  • Bot-Management: Verdächtiger Traffic wird am Edge erkannt und blockiert

Push vs. Pull CDN:

  • Pull (Standard): CDN holt Inhalte bei Bedarf vom Origin. Konfigurationsarm, universell einsetzbar.
  • Push: Dateien werden explizit hochgeladen. Sinnvoll für sehr häufig abgerufene, sich selten ändernde Assets.

CDN in der Praxis

Für WordPress sind mehrere CDN-Integrationsmuster verbreitet:

Cloudflare als DNS/Proxy: Die einfachste Option — DNS auf Cloudflare, Proxy aktiviert. Alle HTTP-Anfragen laufen durch Cloudflare. Kostenlos für Grundfunktionen. Cache-Rules konfigurieren:

# WordPress-spezifische Cache-Bypass-Regel (Page Rules)
URL: example.com/wp-admin/*  → Cache Level: Bypass
URL: example.com/*           → Cache Level: Standard

BunnyCDN für statische Assets: DNS-Record für cdn.example.com auf BunnyCDN zeigen, WordPress siteurl für statische Assets auf die CDN-URL umlenken (via WP-Plugin oder wp-config.php):

define('WP_CONTENT_URL', 'https://cdn.example.com/wp-content');

CORP-Header für CDN-Assets: Assets die von anderen Domains eingebettet werden sollen, benötigen auf Cross-Origin-Isolation-Seiten einen CORP-Header: Cross-Origin-Resource-Policy: cross-origin.

Auf einen Blick

Das Wichtigste

  • CDN = geografisch verteilte Caches, die Inhalte näher am Nutzer ausliefern
  • Origin Pull ist der Standard: Edge-Node cached beim ersten Abruf
  • CDNs bieten auch DDoS-Schutz, WAF und Bot-Management
  • Cloudflare ist die häufigste Free-Tier-Option für WordPress
  • Cache-Invalidierung: Deployments müssen CDN-Cache leeren (per API oder Version-Suffix)

Was passiert bei CDN-Fehlkonfiguration?

Das häufigste Problem: WordPress-Admin und dynamische Inhalte werden versehentlich gecacht. Nutzer A sieht den eingeloggten Admin-Bereich von Nutzer B. Oder: Formular-Nonces werden gecacht und sind bei Aufruf bereits abgelaufen.

Lösung: Strikte Cache-Bypass-Regeln für wp-admin/*, wp-login.php, wp-json/*, URLs mit Query-Parameter ?nocache=1, und Requests mit eingeloggtem Cookie (wordpress_logged_in_*).

Ein weiteres Risiko: Nach einem WordPress-Update sind CSS/JS-Dateien am CDN noch gecacht, die neue Version auf dem Origin-Server. Symptom: Broken Admin-UI. Lösung: Cache-Purge per CDN-API nach jedem Deploy automatisieren.

Häufige Fragen

Wann brauche ich kein CDN? Bei sehr geringem Traffic auf einem performanten Server in der Nähe der Zielgruppe. Ein gut konfigurierter Nginx-Server in Frankfurt ist für eine deutschsprachige Seite mit wenigen hundert täglichen Besuchern ausreichend. CDN-Komplexität lohnt sich erst ab messbarem Performance-Problem oder ernsthafter DDoS-Gefahr.

Was ist der Unterschied zwischen CDN und Page Cache? Page Cache (z.B. Souin in WordPress) cached Seiten auf dem Origin-Server — weniger PHP-Ausführung, weniger Datenbankabfragen. CDN cached den fertig generierten Output geografisch verteilt — weniger Netzwerklatenz. Beide zusammen sind die maximale Performance-Kombination.

Wie funktioniert Cache-Invalidierung bei CDNs? Over CDN-API oder durch URL-Versioning. Cloudflare bietet POST /zones/:id/purge_cache mit spezifischen URLs oder purge_everything. BunnyCDN und AWS CloudFront haben ähnliche APIs. Für automatische Purges nach WordPress-Updates gibt es Plugins (Cloudflare Cache Purger, WP Rocket CDN Add-on).

Verwandte Begriffe

DDoS · HTTPS · LCP

start call_