Kurz erklärt
Ein CDN (Content Delivery Network) ist ein weltweit verteiltes Netzwerk von Servern, das statische Inhalte wie Bilder, CSS, JavaScript und Videos zwischenspeichert und vom nächstgelegenen Standort ausliefert.
Ohne CDN: Ein Nutzer in München ruft eine Website ab, deren Server in den USA steht → hohe Latenz, langsamer TTFB (200-400 ms).
Mit CDN: Der gleiche Nutzer erhält die Inhalte von einem Server in Frankfurt → deutlich schnellerer TTFB (10-50 ms) und damit besserer LCP.
Vorteile eines CDN:
- Schnellere Ladezeiten durch geografische Nähe
- Reduzierter TTFB (Time to First Byte)
- Bessere Core Web Vitals (LCP profitiert direkt)
- Entlastung des Origin-Servers
- DDoS-Schutz und höhere Verfügbarkeit
Bekannte CDN-Anbieter: Cloudflare, Fastly, AWS CloudFront, Bunny.net. Für statische Websites (Astro, Next.js) ist ein CDN quasi Pflicht für optimale Performance.
Wie funktioniert ein CDN?
1. Origin-Server vs. Edge-Server
Origin-Server:
- Der “echte” Server, auf dem Ihre Website gehostet ist
- Steht z. B. in Frankfurt, Virginia (AWS us-east-1), oder Kalifornien
- Generiert dynamische Inhalte (API-Responses, SSR)
Edge-Server:
- Weltweit verteilte CDN-Server
- Speichern Kopien statischer Inhalte zwischen (Cache)
- Liefern Inhalte mit minimaler Latenz aus
2. Request-Flow mit CDN
Erster Request (Cold Cache):
- Nutzer ruft
https://example.com/hero.jpg auf
- Request geht an nächstgelegenen Edge-Server (Frankfurt)
- Edge-Server hat Datei nicht im Cache → fragt Origin-Server
- Origin-Server sendet Datei an Edge-Server
- Edge-Server speichert Datei und liefert sie an Nutzer
- Dauer: ~200-400 ms (Origin-Latenz)
Folge-Requests (Warm Cache):
- Nutzer ruft
https://example.com/hero.jpg auf
- Request geht an Edge-Server (Frankfurt)
- Edge-Server hat Datei im Cache → liefert sofort
- Dauer: ~10-50 ms (Edge-Latenz)
Cache-Dauer: Bestimmt durch HTTP-Header (Cache-Control, Expires)
CDN-Typen
1. Pull CDN (am häufigsten)
Funktionsweise:
- CDN holt Inhalte automatisch vom Origin-Server, wenn nicht im Cache
- Sie ändern nichts an Ihrem Origin-Server-Setup
- CDN fungiert als transparenter Proxy
Beispiele: Cloudflare, Fastly, AWS CloudFront
Vorteile:
- Einfaches Setup (DNS-Änderung reicht)
- Kein Upload nötig
- Automatisches Cache-Management
2. Push CDN (selten)
Funktionsweise:
- Sie laden Dateien manuell auf CDN-Server hoch
- CDN verteilt sie auf Edge-Server
- Kein automatisches Fetching vom Origin
Beispiele: Bunny.net (optional), StackPath
Vorteile:
- Volle Kontrolle über gecachte Inhalte
- Geeignet für statische Sites ohne Origin
Nachteil: Manuelle Uploads bei jedem Update
3. Hybrid (moderne Ansätze)
Beispiel: Cloudflare Pages, Vercel, Netlify
- Statische Inhalte werden automatisch global verteilt
- Dynamische Inhalte über Edge Functions am Edge ausgeführt
- Keine Unterscheidung zwischen CDN und Hosting mehr nötig
Core Web Vitals und CDN
LCP (Largest Contentful Paint)
Problem ohne CDN:
- Hero-Bild von US-Server nach Deutschland: 200-400 ms TTFB + Bildgröße
- LCP oft >3 Sekunden
Lösung mit CDN:
- Hero-Bild vom Frankfurt-Edge: 10-50 ms TTFB + Bildgröße
- LCP typisch <2,5 Sekunden
Best Practice:
<!-- Preload wichtigstes Bild, CDN liefert es aus -->
<link rel="preload" as="image" href="https://cdn.example.com/hero.jpg">
<img src="https://cdn.example.com/hero.jpg" fetchpriority="high" loading="eager">
Siehe auch: LCP
TTFB (Time to First Byte)
CDN ist der wichtigste Faktor für niedrigen TTFB:
| Standort | Ohne CDN | Mit CDN |
|---|
| München → USA-Server | 250 ms | 15 ms (Frankfurt-Edge) |
| Tokyo → USA-Server | 400 ms | 20 ms (Tokyo-Edge) |
| Sydney → USA-Server | 500 ms | 30 ms (Sydney-Edge) |
Siehe auch: TTFB
INP (Interaction to Next Paint)
Indirekt profitieren:
- API-Requests über Edge-Functions statt Origin-Server
- Schnellere Response-Zeiten = bessere INP-Werte
CDN-Anbieter im Vergleich
| Anbieter | Edge-Standorte | Besonderheiten | Preis |
|---|
| Cloudflare | 310+ | Kostenloser Plan, DDoS-Schutz, Workers (Edge Functions) | Ab 0 € |
| AWS CloudFront | 450+ | AWS-Integration, Lambda@Edge | Pay-per-use |
| Fastly | 80+ | Instant Purge, Echtzeit-Logs, Edge Computing (Compute@Edge) | Ab 50 €/Monat |
| Bunny.net | 100+ | Günstiger Storage, einfaches Setup | Ab 1 €/Monat |
| Cloudinary | 300+ | Spezialisiert auf Bilder/Videos, automatische Optimierung | Ab 0 € (Freemium) |
Cloudflare (Empfehlung für KMU)
Vorteile:
- Kostenloser Plan für kleine Sites
- DDoS-Schutz inklusive
- Edge Functions (Workers) für dynamische Logik
- Einfaches Setup (DNS-Änderung)
Ideal für: Astro, Next.js, statische Sites
AWS CloudFront (Empfehlung für Enterprise)
Vorteile:
- Meiste Edge-Standorte weltweit
- Tiefe Integration mit AWS-Services (S3, Lambda)
- Granulare Kontrolle
Ideal für: AWS-basierte Infrastrukturen, große Unternehmen
Vorteile:
- Instant Cache Purge (Änderungen sofort live)
- Echtzeit-Logs und Monitoring
- Edge Computing mit Compute@Edge (Rust/JavaScript)
Ideal für: E-Commerce, Medien, High-Traffic-Sites
CDN einrichten
Option 1: DNS-basiertes CDN (z. B. Cloudflare)
1. Cloudflare-Account erstellen
2. Domain hinzufügen
- Cloudflare scannt DNS-Records
- Übernimmt bestehende Einträge
3. Nameserver ändern
- Bei Domain-Registrar (z. B. INWX, Namecheap)
- Cloudflare-Nameserver eintragen
4. Automatisches Caching aktiviert
- Statische Inhalte werden automatisch gecacht
- Konfiguration über Page Rules möglich
Setup-Dauer: 5-30 Minuten (DNS-Propagation)
Option 2: Origin-Shield (AWS CloudFront)
1. CloudFront-Distribution erstellen
- Origin: S3-Bucket oder eigener Server
- Edge-Locations auswählen
2. CNAME-Record setzen
cdn.example.com CNAME d111111abcdef8.cloudfront.net
3. TLS-Zertifikat einbinden
- AWS Certificate Manager (kostenlos)
- Automatische Renewal
4. Cache-Behavior konfigurieren
- TTL für statische Inhalte: 1 Jahr
- TTL für dynamische Inhalte: 5 Minuten
Setup-Dauer: 30-60 Minuten
1. Projekt deployen
npm run build
vercel deploy
2. Automatisch global verteilt
- Kein manuelles CDN-Setup nötig
- Vercel/Netlify Edge Network automatisch aktiv
3. Custom Domain verbinden
vercel domains add example.com
Setup-Dauer: 5-10 Minuten
Cache-Strategien
Cache-Control: public, max-age=31536000, immutable
Wichtige Direktiven:
public – Darf von CDN gecacht werdenprivate – Nur Browser-Cache, nicht CDNmax-age=31536000 – Cache-Dauer: 1 Jahr (in Sekunden)immutable – Datei ändert sich nie (bei versionierten Assets)
Best Practices
Versionierte Assets (mit Hash im Dateinamen):
Cache-Control: public, max-age=31536000, immutable
Beispiel: app.a3f2e1b.js
HTML-Dateien (immer aktuell halten):
Cache-Control: public, max-age=0, must-revalidate
Bilder (lange cachen, aber nicht immutable):
Cache-Control: public, max-age=2592000
API-Responses (kurzes Caching):
Cache-Control: public, max-age=300
Cache Purging (Cache leeren)
Wann nötig?
- Nach Deployment (neue Version ist live)
- Bei Fehlern (falsche Inhalte im Cache)
- Bei Notfall-Updates (Security-Fixes)
Methoden:
1. Full Cache Purge (alles löschen):
- Cloudflare: Dashboard → Caching → “Purge Everything”
- CloudFront: Invalidation erstellen (
/*)
2. Selective Purge (einzelne URLs):
# Cloudflare API
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
-H "Authorization: Bearer {token}" \
-d '{"files":["https://example.com/style.css"]}'
3. Tag-based Purge (z. B. Fastly):
- Inhalte mit Tags versehen (
Surrogate-Key: product-123)
- Purge alle Inhalte mit Tag:
curl -X PURGE -H "Surrogate-Key: product-123"
CDN und Security
DDoS-Schutz
CDN-Anbieter bieten automatischen DDoS-Schutz:
- Verteilte Architektur absorbiert Traffic-Spitzen
- Rate Limiting am Edge
- Bot-Detection
SSL/TLS-Verschlüsselung
Flexible SSL (Cloudflare):
- Browser → CDN: verschlüsselt
- CDN → Origin: unverschlüsselt
- Nicht empfohlen (Man-in-the-Middle-Risiko)
Full SSL:
- Browser → CDN: verschlüsselt
- CDN → Origin: verschlüsselt (selbst-signiertes Zertifikat OK)
Full SSL (strict):
- Browser → CDN: verschlüsselt
- CDN → Origin: verschlüsselt (gültiges Zertifikat erforderlich)
- Empfohlen
Firewall-Regeln
CDN-Anbieter bieten Web Application Firewall (WAF):
- Blockiere Requests nach Land/IP
- Rate Limiting (max. X Requests/Minute)
- Challenge verdächtiger Traffic (CAPTCHA)
Hit Ratio (Cache-Trefferquote)
Definition: Prozentsatz der Requests, die vom CDN-Cache beantwortet werden (nicht vom Origin).
Ziel: >90% Hit Ratio
Berechnung:
Hit Ratio = (Cache Hits / Total Requests) × 100
Verbesserung:
- Cache-Control-Header optimieren
- Mehr Inhaltstypen cachen (JSON, API-Responses)
- Longer TTLs für statische Inhalte
Bandwidth Savings
Definition: Reduzierung des Traffic zum Origin-Server.
Beispiel:
- Ohne CDN: 10 TB/Monat vom Origin ausgeliefert
- Mit CDN: 1 TB/Monat vom Origin (9 TB vom Cache)
- Bandwidth Savings: 90%
Kosteneinsparung: Origin-Server-Traffic ist teurer als CDN-Traffic.
Häufige Fehler
❌ Statische Assets ohne Versionierung: Änderungen werden nicht sichtbar wegen langem Cache
✅ Lösung: Asset-Hashing verwenden (app.a3f2e1b.js)
❌ HTML-Dateien lange cachen: Nutzer sehen veraltete Inhalte
✅ Lösung: HTML mit max-age=0 oder kurzer TTL
❌ Cookies in Cache-Key: Jeder Nutzer erzeugt separaten Cache-Entry
✅ Lösung: Cookies aus Cache-Key ausschließen
❌ Origin-Server blockiert CDN: Firewall blockiert CDN-IPs
✅ Lösung: CDN-IP-Ranges whitelisten
❌ Zu kurze TTL: Viele Origin-Requests, schlechte Hit Ratio
✅ Lösung: Längere TTL für statische Inhalte (1 Jahr)
Nächste Schritte
- CDN-Anbieter wählen (Cloudflare für Einstieg, CloudFront für AWS-Setup)
- Domain mit CDN verbinden (DNS-Änderung oder CNAME)
- Cache-Control-Header korrekt setzen
- Test: TTFB und LCP vor/nach CDN messen (PageSpeed Insights)
- Hit Ratio im CDN-Dashboard monitoren (Ziel: >90%)
- Edge Functions für dynamische Logik evaluieren (Cloudflare Workers, Lambda@Edge)
Siehe auch
TTFB – CDN verbessert TTFB drastischLCP – Schnellere Bildauslieferung verbessert LCPCore Web Vitals – Gesamtbild der Performance-MetrikenEdge Computing – Dynamische Logik am Edge