WordPress schneller machen: Cloudflare Cache Rules + PHP (OPcache & APCu) – Praxisleitfaden

Ziel: Eine kleine bis mittelgroße WordPress-Site ohne zusätzliche Komplexität (z. B. Redis) deutlich schneller ausliefern durch sicheres Edge-Cachen bei Cloudflare und schnelle PHP-Ausführung via OPcache & APCu.

Datenschutz-Hinweis: Die folgenden Schritte lassen sich nicht nur in WordPress anwenden, sondern auch auf eigene Websites und viele verbreitete CMS/Frameworks (z. B. Joomla, Drupal, TYPO3, Magento/Adobe Commerce, Shopware, PrestaShop, OpenCart, MediaWiki, Ghost, Laravel, Symfony, Django, Ruby on Rails, Express/Node.js, Next.js, Nuxt, Flask, Spring Boot usw.). Ersetze im Text example.com durch deine eigene Domain und teste die Regeln in deiner Umgebung (Cloudflare Cache Rules, nginx, php-fpm, OPcache, APCu). Typische Bereiche, die vom Caching ausgenommen werden sollten, sind Admin-/Login-/Vorschau-Routen (z. B. /wp-admin, /administrator, /typo3, /user/login, /admin, /api/*). Korrekt gesetzte Regeln senken die Serverlast und beschleunigen die Ladezeiten deiner Seiten.

1) Was wir erreichen wollen

• HTML an der Edge cachen (Cloudflare POPs) → niedrigere TTFB, weniger Last am Origin.
• Nie cachen: Login, Admin, PREVIEW, REST, PHP, Cookie-basierte Zugriffe.
• OPcache (PHP-Bytecode) + APCu (in-process Key/Value) aktivieren.
• Messbar prüfen: 1. Request MISS → 2. Request HIT mit Age: >0.

2) Cloudflare Cache Rules – zwei bewährte Regeln

Wichtig zur Reihenfolge: Cloudflare wendet die unterste passende Regel an. Lege die Bypass-Regel unter die „Eligible“-Regel. Entferne alte „Cache Everything“-Vorlagen oder positioniere sie so, dass sie nicht greift.

2.1 „Cache Eligible“ (anonyme GET/HEAD cachen)

Cache eligibility: Eligible for cache
Edge TTL: Use cache-control header if present, cache default TTL if not

Filter (Expression):

(http.host eq "example.com" and
 (http.request.method eq "GET" or http.request.method eq "HEAD") and
 not starts_with(http.request.uri.path, "/wp-admin") and
 http.request.uri.path ne "/wp-login.php" and
 http.request.uri.path ne "/wp-cron.php" and
 not starts_with(http.request.uri.path, "/wp-json") and
 not ends_with(http.request.uri.path, ".php") and
 not (http.request.uri.query contains "preview=true") and
 not (http.cookie contains "wordpress_logged_in_" or http.cookie contains "wp-postpass_")
)

Idee: Anonyme GET/HEAD-Anfragen auf Seiten/Beiträge werden an der Edge zwischengespeichert. Gibt der Origin cache-control zurück, nutzt Cloudflare das. Falls nicht, gilt das Cloudflare-Standard-TTL.

2.2 „Bypass Cache“ (dynamische & sensible Endpunkte)

Cache eligibility: Bypass cache

Filter (Expression):

(http.host eq "example.com" and
(
  (http.request.method ne "GET" and http.request.method ne "HEAD")
  or starts_with(http.request.uri.path, "/wp-admin")
  or http.request.uri.path in {"/wp-login.php" "/wp-cron.php" "/xmlrpc.php"}
  or starts_with(http.request.uri.path, "/wp-json")
  or ends_with(http.request.uri.path, ".php")
  or http.request.uri.query contains "preview=true"
  or http.cookie contains "wordpress_logged_in_"
  or http.cookie contains "wp-postpass_"
))

Optional verschärfen:

or (http.request.uri.query contains "s=")           # Suche
or starts_with(http.request.uri.path, "/feed")       # RSS/Atom
or ends_with(http.request.uri.path, "/amp/")         # AMP (falls ungenutzt)

3) Server optimieren: PHP OPcache & APCu

3.1 OPcache – Beispielkonfiguration

Datei (Version anpassen), z. B. /etc/php/8.3/fpm/conf.d/10-opcache.ini:

zend_extension=opcache.so
opcache.enable=1
opcache.jit=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

Neustart/Reload FPM:

systemctl reload php8.3-fpm

3.2 APCu – 8.3 & 8.4

Installation (Beispiel Debian/Ubuntu mit sury):

apt install -y php8.3-apcu php8.4-apcu

Overrides (pro SAPI & Version):

/etc/php/8.3/fpm/conf.d/99-apcu.ini
/etc/php/8.3/cli/conf.d/99-apcu.ini
/etc/php/8.4/fpm/conf.d/99-apcu.ini
/etc/php/8.4/cli/conf.d/99-apcu.ini

Inhalt:

apc.enabled=1
apc.shm_size=64M
apc.ttl=0
apc.gc_ttl=3600
apc.enable_cli=0

Reload:

systemctl reload php8.3-fpm || true
systemctl reload php8.4-fpm || true

4) Warm-up & Verifikation

4.1 Edge „anwärmen“

wget -e robots=off -r -l1 -np -k -p -q -U "WarmupBot" -H -D example.com --delete-after https://example.com/

4.2 Header prüfen (MISS → HIT + Age)

# Startseite
curl -I https://example.com/ | egrep -i 'cf-cache-status|age'
sleep 2
curl -I https://example.com/ | egrep -i 'cf-cache-status|age'

# Einzelbeitrag (Beispiel-Slug)
u="https://example.com/mein-beitrag/"
curl -I "$u" | egrep -i 'cf-cache-status|age|cache-control'
sleep 2
curl -I "$u" | egrep -i 'cf-cache-status|age|cache-control'

Erwartung: zuerst MISS, danach HIT und Age: >0.

5) Warum (vorerst) ohne Redis?

Für kleine Sites ist ein Redis Object Cache oft nicht erforderlich. Falsch konfigurierte Clients/Serializer (z. B. „phpredis“ erzwungen, Extension fehlt) erzeugen 500-Fehler. Mit Edge-Cache + OPcache/APCu erreichst du bereits den Großteil des Performance-Gewinns. Redis nur dann ergänzen, wenn echte DB-Engpässe messbar sind.

6) Troubleshooting – Kurzcheck

• 500 an der Edge: Syntax der Cache-Ausdrücke prüfen; Admin/Login/Preview/REST garantiert „Bypass“?
• Immer MISS: Setzt der Origin cache-control? Wird ein Set-Cookie gesendet? Greift eine andere Regel?
• 500 am Origin: Testweise wp-content/object-cache.php entfernen & FPM reload; Plugins mit WP-CLI gesammelt deaktivieren und einzeln aktivieren.
• Schwankende TTFB: Edge-Wärme, PoP, Geografie, momentane Last. Mehrfach testen.

7) Gemessene Wirkung (Beispielwerte)

• Vorher (ohne Edge-Cache): TTFB Startseite ~ 0.45–0.60 s
• Nachher (HIT): TTFB Startseite ~ 0.08–0.12 s
• Origin-Last: spürbar geringer (besonders zu Peak-Zeiten)

8) Optional: Cloudflare Cache Reserve

Für kleinen Traffic oft überdimensioniert. Bei stärkerem Traffic/Backfill-Szenarien kann es helfen, Misses und Origin-Spitzen weiter zu reduzieren. Kostenseitig abwägen.

9) Häufige Ausdrucksfehler in Cloudflare

Klammern: Bedingungen klar gruppieren; „Bypass“-Regel in der Reihenfolge unter der „Eligible“-Regel.

Mengenliterale: in {"GET" "HEAD"} (Werte in geschweiften Klammern, durch Leerzeichen getrennt; keine Kommata).

Fazit

Mit zwei sauberen Cache-Regeln bei Cloudflare und OPcache + APCu auf dem Server erreichst du ohne Zusatzkomplexität bereits einen sehr großen Performance-Sprung. Baue erst dann weiter (z. B. Redis), wenn Messwerte echte Engpässe zeigen.