Ein Edge-PoP („Point of Presence“) ist ein Standort eines CDN am Netzwerkrand – also nahe bei deinen Nutzer*innen. Dort stehen Cache-Server und Sicherheitskomponenten (z. B. WAF, DDoS-Schutz). Ziel: Inhalte mit kurzer Latenz ausliefern und deinen Origin-Server entlasten.

1) Vorab klären

• Ziele & KPIs definieren: Cache-Hit-Rate (CHR), Origin-Offload, TTFB p95/p99.

• Inhalte klassifizieren: statisch (CSS/JS/Fonts/Bilder), semi-dynamisch (HTML/SSR), dynamisch (APIs, personalisiert).

   

  ---

   

2) Header-Setup (Basis)

• HTTP/2/3, TLS 1.3, Brotli aktivieren.

• Für HTML (Edge-Cache kurz, Browser frisch halten): Cache-Control: public, max-age=0, s-maxage=600, stale-while-revalidate=30, stale-if-error=86400 Vary: Accept-Encoding

• Für versionierte Assets (mit Hash im Dateinamen): Cache-Control: public, max-age=31536000, immutable

• Optional (wenn CDN unterstützt): Surrogate-Control/CDN-Cache-Control für feinere Steuerung.
  
  

3) Cache-Key sauber halten

• Query-Parameter whitelisten: nur relevante in den Key (z. B. lang, page); Tracking-Parameter ignorieren (utm_*, gclid, fbclid).

• Cookies vermeiden: nur in den Key aufnehmen, wenn sie den Inhalt ändern (z. B. Sprache, Login).

• Geräte/Land: nur differenzieren, wenn die Antwort wirklich abweicht. Sonst responsiv lösen.
  
  

4) HTML sicher cachen

• Edge-TTL kurz (5–10 min), dafür stale-while-revalidate & stale-if-error nutzen.

• Uncacheable Bereiche (Warenkorb, „eingeloggt“, Admin, Consent-Banner) entkoppeln:

  • Client-seitig nachladen (API),

  • Edge-Includes/ESI,

  • separate Endpunkte mit no.store. 

• ETag/Last-Modified am Origin belassen (für Conditional Requests) – schaden dem Edge-Cache nicht.
  
  

5) Statische Assets hart cachen

• Dateinamen versionieren (app.abc123.css) → max-age=31536000, immutable.
  Nur bei neuer Version ausliefern; kein Purge nötig.
  
  

6) Purge-/Invalidate-Strategie

• Tag-/Key-basiertes Purging statt „Purge All“.

• Beim CMS/Deploy Tags mitschicken (z. B. post:42, template:header), damit granular invalidiert werden kann.

• Rollbacks einplanen: alte Versionen kurzfristig verfügbar halten.
  
  

7) Sicherheit & Origin-Schutz

• Origin-IP verbergen, Firewall nur für CDN-IP-Ranges öffnen.

• WAF erst beobachten, dann schärfen; Ausnahmen (Payment, Webhooks, Bots) definieren.

• Keine Set-Cookie-Header auf cachebaren HTML/Asset-Antworten setzen.
  
  

8) Edge-Funktionen & Personalisierung

• A/B-Tests: Variablen per Cookie/URL, aber nicht in globalen Cache-Key ziehen (nur test-Routen).

• Geotargeting: Edge-Logic ohne globale Cache-Fragmentierung, oder Werte client-seitig nachladen.
  
  

9) Monitoring & Metriken

• CHR getrennt nach Inhaltstyp (Assets/HTML) tracken.

• Origin-Offload und Fehlerquoten (Edge vs. Origin) überwachen.

• TTFB p95/p99 pro Region/Gerät; zusätzlich Bytes/Request & Kosten/GB.

• Header prüfen (X-Cache, cf-cache-status, Via), um Edge-Hits zu verifizieren.
  
  

10) Tests & Rollout

• Baseline ohne/mit CDN messen.

• Regeln stufenweise ausrollen (zuerst Assets, dann HTML kurz cachen).

• RUM-Daten (echte Nutzer) + Lab-Tests kombinieren; unterschiedliche Regionen testen.
  
  

11) Typische No-Gos

• „Alles oder nichts“ cachen → lieber selektiv.

• UTM/Cookies im Cache-Key → CHR sinkt.

• Purge All bei jedem Publish → Origin-Sturm.

• Consent/Admin/Warenkorb versehentlich gecacht.

• WAF zu hart ohne Ausnahmen → False Positives.
  
  

12) Mini-Blueprint (Origin-Beispiel, NGINX)
# HTML – Edge kurz cachen, Browser frisch location / { add_header Cache-Control "public, max-age=0, s-maxage=600, stale-while-revalidate=30, stale-if-error=86400"; add_header Vary "Accept-Encoding"; try_files $uri @app; } # Versionierte Assets – hart cachen location ~* \.(css|js|png|jpg|jpeg|gif|svg|webp|avif|woff2?)$ { add_header Cache-Control "public, max-age=31536000, immutable"; } 


.