Cloudflare-Cache-Hit-Rate nur 30 %? Mit diesen 3 Regeln auf 90 % bringen

Die Cloudflare-Cache-Hit-Rate meines Blogs schwankte dauerhaft bei etwa 30 %. Bilder und CSS wurden gecacht, HTML ging bei jedem Aufruf zum Origin – der Server blieb unter Last. Cloudflare cached HTML standardmäßig nicht, und Page Rules sind deprecated.

Nach Recherche zu Cache Rules und Edge TTL stieg die Hit-Rate von 30 % auf 90 %, TTFB von 500 ms auf gut 100 ms, Origin-Last minus 90 %. Dieser Artikel zeigt die Cloudflare-Cache-Konfiguration: warum HTML nicht gecacht wird, Cache-Rules-Schritte und Verifizierung.

Warum cached Cloudflare standardmäßig kein HTML?

Standard-Cache-Verhalten von Cloudflare

Zuerst das Default-Verhalten: Cloudflare cached standardmäßig nur statische Assets – Bilder (JPG, PNG, GIF), CSS, JS. HTML? Standardmäßig nicht.

Die Logik: Drei Bedingungen entscheiden, ob eine Ressource gecacht werden kann:

1. Cache-Control-Header: Bei private, no-store, no-cache oder max-age=0 kein Cache
2. Statuscode: Nur bestimmte HTTP-Codes (200, 301, 404 usw.)
3. Request-Methode: Nur GET – POST, PUT nicht

HTML gilt als „dynamischer Inhalt“ mit möglicherweise nutzerspezifischen Daten – deshalb kein Standard-Cache. Sinnvoll: Bei Login können Benutzernamen oder persönliche Infos im HTML stehen – das darf das CDN nicht für andere ausliefern.

Der echte Grund: Sicherheit

Kurz gesagt: Cloudflare priorisiert Sicherheit. In Foren las ich von jemandem, der Full-Site-Caching aktiviert hatte – sogar wp-login.php wurde gecacht, inklusive Login-Daten. Jeder Besucher konnte über die gecachte Seite ins WordPress-Backend – erschreckend.

Wenn Ihre Site überwiegend statisch ist, z. B.:

• Statischer Blog mit Next.js, Gatsby
• Selten aktualisierte Unternehmens- oder Dokumentationsseiten
• Reine Produkt-Showcase-Seiten

… kann HTML-Caching die Performance deutlich verbessern – vorausgesetzt, Sie schließen Backend und Login korrekt aus.

Wie viel bringt HTML-Caching?

Auf Medium teilte jemand: TTFB von 500 ms auf 100–160 ms, Origin-Last minus 90 %.

Warum so groß? Früher holte jeder Besucher HTML vom Origin – Request, DB, Rendering. Jetzt liefert das CDN gecachtes HTML, der Origin bleibt unberührt. Je mehr Traffic, desto größer der Effekt.

Page Rules sind deprecated – Cache Rules als Ersatz

Das Ende von Page Rules

Wer Cloudflare schon länger nutzt, kennt Page Rules und die Option „Cache Everything“ für HTML. Leider ist Page Rules deprecated.

Zeitlinie:

• Juli 2024: Neue Free-Accounts ohne Page Rules
• 2025: Cloudflare migriert bestehende Page Rules automatisch
• Neue Konfigurationen nur noch über Cache Rules

Warum? Page Rules sind alt, unflexibel – Free nur 3 Regeln. Für komplexe Strategien zu wenig.

Die neue Welt: Cache Rules

Cache Rules ist das neue System – deutlich mächtiger. Der wichtigste Unterschied:

Page-Rules-Ära: Manuell „Cache Everything“ wählen

Cache-Rules-Ära: Bei „Eligible for cache“ ist Cache Everything automatisch aktiv

Ich suchte erst nach „Cache Everything“, bis mir klar wurde, dass es umbenannt wurde.

Zusätzlich flexiblere Match-Bedingungen:

• URI-Pfad, Dateiendung, Hostname
• Regex (selten nötig)
• Kombinierbare Bedingungen

Migrationshinweise

Noch Page Rules im Einsatz? Beachten Sie:

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

1. Automatische Migration: 2025 wandelt Cloudflare Page Rules in Cache Rules um (Sie können auch vorher manuell migrieren)
2. Nicht alles wird migriert: „Disable Security“ und „Disable Performance“ sind deprecated
3. Leicht unterschiedliches Verhalten: „Eligible for cache“ ≈ „Cache Everything“, Implementierung weicht etwas ab

Empfehlung: Jetzt auf Cache Rules umstellen – früher oder später unvermeidlich, und die Konfiguration ist klarer.

Cache Rules in der Praxis: 3 Regeln für Full-Site-Caching

Genug Theorie – jetzt die Praxis. Drei Cache Rules decken Bypass bis Full-Site-Caching ab.

Vorbereitung: Konfigurationsseite

1. Cloudflare-Dashboard → Domain
2. Links „Caching“ → Tab „Cache Rules“
3. „Create rule“

Dann Regel für Regel.

Regel 1: Backend und Admin umgehen (höchste Priorität)

Warum zuerst? Sicherheit! Backend und Login dürfen nie gecacht werden.

Schritte:

1. Rule name: Bypass Admin Pages
2. When incoming requests match:
   • „Custom filter expression“
   • Field: „URI Path“
   • Operator: „contains“
   • Value: /wp-admin
3. Weitere Pfade per „Or“:
   • /wp-login.php (WordPress-Login)
   • /admin/ (generisches Backend)
   • /api/auth/ (API-Auth)
4. Then:
   • Cache eligibility: „Bypass cache“
5. Priorität: 1 (höchste)

„Deploy“ – Requests mit diesen Pfaden gehen direkt zum Origin.

Vollständige WordPress-Ausschlussliste:

/wp-admin
/wp-login.php
/wp-json
/cart
/checkout
/my-account

Passen Sie die Liste an Ihre Site an.

Regel 2: Statische Assets cachen (mittlere Priorität)

Optional, da Cloudflare statische Assets standardmäßig cached – explizite Regel gibt präzisere TTL-Kontrolle.

Schritte:

1. Rule name: Cache Static Assets
2. When incoming requests match:
   • Field: „File extension“
   • Operator: „is in“
   • Value: jpg png gif css js woff woff2 ttf svg ico
3. Then:
   • Cache eligibility: „Eligible for cache“
   • Edge cache TTL: „Use cache-control header if present, use default Cloudflare caching behavior if not“
4. Priorität: 2

Statische Assets nutzen zuerst Origin-Cache-Control, sonst Cloudflare-Standard-TTL (je nach Dateityp 4 Stunden bis 1 Monat).

Regel 3: Alles andere cachen (niedrigste Priorität)

Die Hauptregel – cached auch HTML.

Schritte:

1. Rule name: Cache Everything Else
2. When incoming requests match:
   • „All incoming requests“
   • Oder „Custom filter expression“ mit gezielten Ausschlüssen
3. Then:
   • Cache eligibility: „Eligible for cache“
   • Edge cache TTL: „Ignore cache-control header and use this TTL“
   • Dauer: 7 days (1 Woche)
4. Priorität: 3 (niedrigste)

Warum 1 Woche? Guter Kompromiss. Zu kurz (1 Tag) – wenig Effekt; zu lang (1 Monat) – veralteter Content. Für Blogs und Docs ideal.

Free-Tier: Mindest-TTL 2 Stunden, Pro 1 Stunde. Bei häufigen Updates kürzer wählen.

Reihenfolge ist entscheidend

Cloudflare führt Regeln nach Priorität aufsteigend aus:

1. Regel 1 (Priorität 1): Admin? → Bypass
2. Regel 2 (Priorität 2): Statisch? → passende TTL
3. Regel 3 (Priorität 3): Rest → 1 Woche Cache

So bleiben Admin-Seiten ungecacht, statische Assets sinnvoll gecacht, HTML 1 Woche erzwungen.

Checkliste nach der Konfiguration

• Regel 1 hat höchste Priorität (kleinste Zahl)
• Alle Backend-Pfade in der Ausschlussliste
• Regel-3-TTL an Update-Frequenz angepasst
• Alle Regeln deployed

Konfiguration fertig – als Nächstes Edge TTL und typische Fallstricke.

Edge TTL im Detail: typische Fehler vermeiden

Edge TTL (Edge-Cache-Ablauf) ist Kern der Strategie – und häufige Fehlerquelle.

Drei Edge-TTL-Modi

Modus 1: Use cache-control header if present, bypass cache if not

• Mit Cache-Control folgen, ohne Header kein Cache
• Sinnvoll bei vollständig konfiguriertem Origin
• Einschätzung: Zu strikt – ohne Origin-Header kein Cache

Modus 2: Use cache-control header if present, use default Cloudflare caching behavior if not (empfohlen für gemischte Sites)

• Mit Cache-Control folgen, sonst Cloudflare-Standard
• Sinnvoll bei teilweise konfiguriertem Origin
• Einschätzung: Ausgewogen

Modus 3: Ignore cache-control header and use this TTL

• Origin ignorieren, feste TTL erzwingen
• Sinnvoll für statische Sites oder klare Strategie
• Einschätzung: Durchsetzungsstark – ideal für HTML Full-Site-Caching

Für HTML empfehle ich Modus 3. Viele Seiten haben kein Cache-Control oder no-cache – Modus 1 und 2 cachen dann nicht.

TTL-Dauer wählen

Free-Tier: Mindest-TTL 2 Stunden.

Mein Blog: 1 Woche TTL. Nach Veröffentlichung manuell Purge – ansonsten sehr hohe Hit-Rate.

Häufige Fehler (auch mir passiert)

Fehler 1: Backend nicht ausgeschlossen

Am Anfang eine „Cache Everything“-Regel – WordPress-Backend wurde mitgecacht. Login zeigte alte Seiten, nach Aktionen manueller Refresh nötig.

Lösung: Zuerst Bypass-Regel, höchste Priorität.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Fehler 2: TTL zu lang → veralteter Content

Einmal 1 Monat TTL – Titel geändert, Besucher sahen den alten. Tage später fiel mir der Cache ein.

Lösung: TTL an Update-Frequenz anpassen. Unsicher: 1 Woche testen.

Fehler 3: Edge TTL und Browser TTL verwechseln

Edge TTL = CDN-Knoten, Browser TTL = Besucher-Browser – unabhängig!

• Edge TTL: Wie oft Cloudflare zum Origin geht
• Browser TTL: Wie oft der Browser das CDN anfragt

Nur Edge TTL: CDN spart Origin, Besucher profitieren weniger.

Lösung: Browser TTL „Respect origin“ oder z. B. 1 Tag.

Cache manuell leeren: Purge Cache

Content aktualisiert? Nicht auf TTL warten.

Im Cloudflare-Dashboard:

1. „Caching“
2. „Purge Cache“
3. Optionen:
   • Purge Everything: gesamte Site
   • Custom Purge: bestimmte URLs

Ich nutze Custom Purge. Purge Everything lässt kurz alle Requests zum Origin gehen.

Tipp: WordPress-Cloudflare-Plugin – beim Veröffentlichen automatisch Purge.

Verifizierung und Optimierung

Konfiguration fertig – prüfen Sie mit Daten, nicht Vermutungen.

Methode 1: Browser-DevTools

1. Chrome (oder anderer Browser)
2. F12 → DevTools
3. Tab „Network“
4. Startseite aufrufen
5. HTML-Dokument (meist erster Request) wählen
6. „Headers“ prüfen

Wichtige Header:

cf-cache-status – der Schlüssel:

• HIT: Cache-Treffer, CDN ohne Origin
• MISS: kein Treffer, diesmal Origin, wird gecacht
• DYNAMIC: dynamisch, kein Cache (evtl. Bypass-Regel)
• BYPASS: Cache umgangen (Admin)
• EXPIRED: abgelaufen, CDN holt neu

Erster Aufruf oft MISS, zweiter HIT. Dauerhaft DYNAMIC oder BYPASS → Konfiguration prüfen.

age: Wie lange (Sekunden) der Inhalt im CDN liegt. age: 3600 = 1 Stunde.

cache-control: Origin-Strategie. Bei „Ignore cache-control“ zeigt Cloudflare den Header, folgt ihm aber nicht.

Methode 2: curl

curl -I https://your-website.com

Response-Header prüfen – cf-cache-status auf HIT oder MISS.

Detaillierter:

curl -svo /dev/null https://your-website.com 2>&1 | grep -i "cf-cache"

Nur Cloudflare-relevante Header.

Methode 3: Cloudflare Analytics

1. Domain wählen
2. „Analytics“
3. Tab „Caching“
4. „Cache Hit Ratio“

Vorher 30 %, am nächsten Tag 85 %, jetzt stabil ~90 %. Ähnlicher Anstieg = Erfolg.

Referenzwerte:

• Hit-Rate: Ziel über 80 %
• Bandbreite: deutlicher Rückgang
• Requests: mehr CDN, weniger Origin

Fortgeschrittene Tipps für höhere Hit-Rate

Tipp 1: Cache-Warming

Neuer Content startet als MISS. Vor dem Launch selbst alle Seiten aufrufen oder ein Crawl-Skript nutzen.

Tipp 2: Einheitliche URL-Formate

Unterschiedliche URLs = unterschiedliche Cache-Objekte:

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

• https://example.com/page und https://example.com/page? sind verschieden
• https://example.com/page und https://example.com/page/ sind verschieden

Einheitliche Links vermeiden unnötige MISSes.

Tipp 3: Überflüssige Query Strings entfernen

Tracking-Parameter (?utm_source=twitter) erzeugen pro Kombination ein neues Cache-Objekt.

„Query String Sort“ in den Caching-Einstellungen sortiert Parameter vor dem Cachen.

Besser: Transform Rules, um irrelevante Query-Parameter zu entfernen.

Häufige Probleme

Problem 1: cf-cache-status dauerhaft DYNAMIC

Mögliche Ursachen:

• Origin setzt no-cache oder private
• Cache Rule passt nicht, Request trifft „Eligible for cache“ nicht

Lösung: Match-Bedingungen prüfen. Mit Modus 3 (Ignore cache-control) sollte HTML erzwungen werden.

Problem 2: Hit-Rate nur 50–60 %

Mögliche Ursachen:

• Dynamische URL-Parameter
• Origin-Header blockieren Cache
• CDN füllt Cache noch (frische Konfiguration)

Lösung: 1–2 Tage warten, Analytics prüfen, schwache Bereiche gezielt optimieren.

Problem 3: Besucher sehen alten Content nach Update

Mögliche Ursachen: TTL zu lang oder Browser-Cache

Lösung: Nach Veröffentlichung Purge Cache oder Automatisierung (WordPress-Plugins).

Zusammenfassung

Kernschritte im Überblick:

1. Warum kein HTML-Standard-Cache: Sicherheit – dynamische und sensible Seiten nicht im CDN
2. Page Rules → Cache Rules: Page Rules deprecated, „Eligible for cache“ = früheres „Cache Everything“
3. 3 Cache Rules:
   • Regel 1 (Priorität 1): Bypass Backend und Login
   • Regel 2 (Priorität 2): Statische Assets
   • Regel 3 (Priorität 3): Alles andere (HTML) erzwingen, TTL ~1 Woche
4. Edge-TTL-Modus: Für HTML „Ignore cache-control and use this TTL“, Dauer an Update-Frequenz
5. Verifizierung: cf-cache-status in DevTools, Analytics Hit-Rate, Ziel über 80 %

Nach meiner Konfiguration: Hit-Rate 30 % → 90 %, TTFB 500 ms → gut 100 ms, Origin-Last minus 90 %. Besonders bei hohem Traffic spürbar.

Jetzt starten:

1. Aktuelle Hit-Rate in Cloudflare Analytics prüfen
2. 3 Cache Rules nach Anleitung (Backend zuerst ausschließen!)
3. 1–2 Tage warten, Analytics erneut prüfen

Bei Problemen prüfen:

• Backend per Bypass ausgeschlossen?
• Prioritäten korrekt?
• Edge-TTL-Modus passend?

Bei WordPress: Cloudflare-Offizielles-Plugin – automatisches Purge beim Veröffentlichen.

Fragen oder Optimierungstipps? Gerne in den Kommentaren teilen!