Zum Hauptinhalt springen
How Can We Help?
< All Topics

Caching ist der grösste Performance-Hebel für WordPress. Es gibt aber nicht „den Cache“, sondern mehrere Ebenen, die unterschiedliche Probleme lösen.

Die Ebenen
Ebene Was wird gecacht Hilft bei
Browser-Cache Statische Assets beim Besucher Wiederholte Besuche
CDN / Edge Assets, optional ganze HTML-Seiten Latenz, Lastspitzen, globale Besucher
Page Cache Fertiges HTML Anonyme Besucher (grösster Effekt)
Object Cache Ergebnisse von DB-Queries und Berechnungen Eingeloggte Benutzer, Shops, Admin, REST
OPcache Kompilierter PHP-Code Jeden PHP-Request

Page Cache

Liefert HTML, ohne PHP und Datenbank zu bemühen. Varianten: Server-Cache (Nginx FastCGI Cache, Varnish, LiteSpeed Cache) oder Plugin-Lösungen, die statische Dateien ablegen (WP Rocket, WP Super Cache u. a.). Server-Caches sind schneller, weil PHP gar nicht startet.

Ausnahmen definieren: Warenkorb, Checkout, „Mein Konto“, Seiten mit personalisierten Inhalten, eingeloggte Benutzer (Cookie wordpress_logged_in_), Requests mit Nonces in Formularen. Nonces sind bis zu 24 Stunden gültig; Seiten mit Formular-Nonces dürfen nicht länger gecacht werden, sonst schlagen Absendungen fehl.

Persistenter Object Cache

WordPress hat einen Object Cache, der ohne Erweiterung nur innerhalb eines Requests lebt. Mit Redis oder Memcached und einem Drop-in (wp-content/object-cache.php) bleibt er über Requests hinweg erhalten.

wp plugin install redis-cache --activate
wp redis enable
wp redis status
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PREFIX', 'example_' );   // Pflicht, wenn sich mehrere Sites einen Redis teilen
define( 'WP_REDIS_MAXTTL', 86400 );

Besonders wirksam für WooCommerce, Membership-Sites, Multisite und den Admin-Bereich. Website-Zustand empfiehlt einen persistenten Object Cache ab einer gewissen Grösse ausdrücklich.

Sicherheit: Redis nie öffentlich erreichbar machen; per Unix-Socket oder bind 127.0.0.1 und mit Passwort/ACL betreiben.

CDN

  • Statische Assets mit langen Cache-Zeiten (Cache-Control: public, max-age=31536000, immutable), WordPress hängt Versionsparameter an.
  • Bildoptimierung am Edge (WebP/AVIF, Grössenanpassung).
  • HTML am Edge cachen (z. B. Cloudflare APO oder Cache Rules mit Cookie-Bypass) bringt sehr viel, braucht aber saubere Purge-Logik bei Inhaltsänderungen.

Cache-Invalidierung

Die eigentliche Schwierigkeit. Beim Speichern eines Beitrags müssen betroffene Seiten (Beitrag, Startseite, Archive, Feeds) aus Page Cache und CDN entfernt werden. Gute Plugins/Integrationen erledigen das per Hook (save_post, transition_post_status). Bei eigenen Lösungen: lieber gezielt als „alles leeren“, sonst bricht nach jeder Änderung die Last ein.

Messen

Response-Header prüfen (x-cache, cf-cache-status, x-fastcgi-cache), TTFB vorher/nachher vergleichen, Trefferquote des Object Cache mit wp redis status bzw. Query Monitor überwachen.

Weiterführende Artikel

Quellen und Dokumentation

Schlagwörter: