Was ist Caching bei WordPress?

Caching speichert eine Kopie generierter Inhalte, damit sie bei nachfolgenden Anfragen schneller ausgeliefert werden koennen, ohne sie von Grund auf neu zu erzeugen. Fuer WordPress bedeutet das, PHP-Ausfuehrung und Datenbankabfragen bei wiederholten Seitenaufrufen zu ueberspringen. Eine WordPress-Seite, die 800ms braucht, um von Grund auf generiert zu werden, kann gecacht in unter 50ms ausgeliefert werden. Caching ist eine der wirkungsvollsten Optimierungen, die du fuer jede WordPress-Seite vornehmen kannst.

Die fuenf Arten von WordPress-Caching

Caching in WordPress ist nicht eine einzelne Sache. Es gibt fuenf verschiedene Schichten, die jeweils an einem anderen Punkt im Anfrage-Zyklus arbeiten. Zu verstehen, was jede einzelne tut, hilft dir, die richtige Caching-Strategie fuer deine Seite zu waehlen.

Browser-Cache

Der Browser-Cache ist die erste Schicht und arbeitet vollstaendig auf dem Geraet des Besuchers. Wenn ein Browser eine CSS-Datei, ein Bild oder eine JavaScript-Datei herunterlaed, speichert er eine lokale Kopie. Beim naechsten Seitenaufruf prueft der Browser, ob die gecachte Kopie noch gueltig ist (basierend auf Cache-Control-, Expires- und ETag-Headern) und ueberspringt den Download komplett, wenn sie es ist. Das eliminiert Netzwerkanfragen und laesst nachfolgende Seitenaufrufe fuer wiederkehrende Besucher fast sofort wirken.

Du steuerst Browser-Caching ueber HTTP-Response-Header. Die wichtigsten sind:

• Cache-Control: max-age=31536000: Sagt dem Browser, die Datei ein Jahr lang zu cachen (31.536.000 Sekunden). Wird fuer versionierte statische Assets verwendet, die einen neuen Dateinamen bekommen, wenn sie sich aendern.
• Cache-Control: no-cache: Der Browser muss beim Server nachfragen, bevor er die gecachte Kopie verwendet. Der Server kann mit "304 Not Modified" antworten, wenn sich die Datei nicht geaendert hat, was Bandbreite spart.
• Cache-Control: no-store: Der Browser darf diese Antwort niemals cachen. Wird fuer sensible oder hochdynamische Inhalte verwendet.

Page-Cache

Page-Caching ist der groesste Performance-Gewinn fuer die meisten WordPress-Seiten. Hier ist das Problem, das es loest: Bei jeder Seitenanfrage laedt WordPress seinen Core, initialisiert die Datenbankverbindung, fuehrt Dutzende von Datenbankabfragen aus, verarbeitet Plugin-Hooks und rendert Theme-Templates. Dieser PHP/MySQL-Zyklus dauert je nach Server und Komplexitaet der Seite zwischen 200ms und mehreren Sekunden. Er produziert fuer jeden anonymen Besucher dieselbe HTML-Ausgabe.

Ein Page-Cache speichert diese HTML-Ausgabe nach der ersten Anfrage. Wenn der naechste Besucher dieselbe Seite anfragt, wird die gecachte HTML-Datei direkt vom Webserver (oder sogar von einem Reverse Proxy davor) ausgeliefert, wobei WordPress, PHP und die Datenbank komplett umgangen werden. Der Unterschied ist dramatisch. Anstatt 50-200 Datenbankabfragen auszufuehren und Tausende Zeilen PHP zu verarbeiten, liest der Server einfach eine Datei und sendet sie.

Object-Cache

Der Object-Cache sitzt zwischen WordPress und der Datenbank. WordPress fragt haeufig dieselben Daten wiederholt ab, sowohl innerhalb eines Seitenaufrufs als auch ueber Seitenaufrufe hinweg: Optionen, Benutzer-Metadaten, Beitragsdaten, Transients. Der Object-Cache speichert diese Abfrageergebnisse im Speicher (mit Redis oder Memcached), damit sie nicht jedes Mal die Datenbank belasten.

WordPress hat einen eingebauten Object-Cache, aber standardmaessig funktioniert er nur innerhalb einer einzelnen Anfrage (er persistiert nicht zwischen Anfragen). Fuer persistentes Object-Caching brauchst du ein Drop-in-Plugin, das WordPress mit Redis oder Memcached verbindet. Beliebte Optionen sind Redis Object Cache und Object Cache Pro.

Object-Caching ist besonders wertvoll fuer Seiten, die kein Full-Page-Caching nutzen koennen, wie WooCommerce-Shops mit personalisierten Inhalten, Mitgliederseiten oder Foren, in denen sich Inhalte haeufig aendern.

Opcode-Cache (OPcache)

Jedes Mal, wenn PHP ein Script verarbeitet, kompiliert es zuerst den menschenlesbaren PHP-Code in Bytecode (maschinenlesbare Anweisungen). Dieser Kompilierungsschritt wird bei jeder Anfrage wiederholt, es sei denn, Opcode-Caching ist aktiviert. PHPs eingebaute OPcache-Erweiterung speichert den kompilierten Bytecode im Shared Memory und eliminiert den Kompilierungsschritt fuer nachfolgende Anfragen.

OPcache ist eine Server-Level-Einstellung, nichts, was du ueber WordPress konfigurierst. Die meisten modernen Hosting-Umgebungen haben OPcache standardmaessig aktiviert. Du kannst dies ueberpruefen, indem du deine PHP-Konfiguration (phpinfo) checkst oder deinen Hosting-Anbieter fragst. OPcache allein kann die PHP-Ausfuehrungsgeschwindigkeit um 30-50% verbessern.

CDN-Cache

Ein CDN (Content Delivery Network) cached deine statischen Assets auf Edge-Servern, die weltweit verteilt sind. Wenn ein Besucher in Tokio ein Bild von deiner in Amsterdam gehosteten WordPress-Seite anfragt, liefert das CDN es von einem nahegelegenen Edge-Server statt die Anfrage den ganzen Weg nach Amsterdam zu leiten. Das reduziert die Latenz fuer statische Assets erheblich. Einige CDN-Anbieter wie Cloudflare bieten ueber ihr APO-Feature auch Full-Page-Caching fuer WordPress an. Mehr Details findest du in unserem Artikel ueber Content Delivery Networks.

Wie Page-Caching Schritt fuer Schritt funktioniert

Da Page-Caching den groessten Einfluss hat, hier ein genauerer Blick darauf, wie es in der Praxis funktioniert:

1. Ein Besucher fragt deinedomain.com/ueber-uns/ zum ersten Mal an.
2. WordPress verarbeitet die Anfrage normal: PHP laeuft, die Datenbank wird abgefragt, das Theme-Template wird gerendert und das HTML wird generiert.
3. Das Caching-Plugin speichert eine Kopie des fertigen HTML im Dateisystem (typischerweise in wp-content/cache/) oder im Speicher.
4. Ein zweiter Besucher fragt deinedomain.com/ueber-uns/ an.
5. Das Caching-Plugin faengt die Anfrage ab, bevor WordPress geladen wird. Es findet die gecachte HTML-Datei und liefert sie direkt aus. PHP wird kaum ausgefuehrt, und die Datenbank wird nicht beruehrt.
6. Wenn sich der Seiteninhalt aendert (ein Beitrag wird aktualisiert, ein Kommentar wird freigegeben), wird der Cache fuer diese spezifische Seite invalidiert, und die naechste Anfrage generiert eine frische Kopie.

Beliebte WordPress-Caching-Plugins im Vergleich

Es gibt viele Caching-Plugins fuer WordPress. Hier sind die am weitesten verbreiteten und wie sie sich vergleichen:

• WP Rocket: Ein Premium-Plugin (ab 59 $/Jahr), das weithin als die benutzerfreundlichste Caching-Loesung gilt. Es aktiviert Page-Caching, Browser-Caching, GZIP-Komprimierung und Lazy Loading mit minimaler Konfiguration. WP Rocket uebernimmt auch CSS/JS-Minifizierung, Datenbankoptimierung und integriert sich mit Cloudflare fuer CDN-Cache-Purging. Es ist die beste Wahl fuer Seitenbetreiber, die grossartige Performance ohne stundenlange Konfiguration wollen.
• W3 Total Cache: Ein kostenloses Plugin mit enormem Funktionsumfang. Es unterstuetzt Page-Caching, Object-Caching (Redis, Memcached, APCu), Browser-Caching, CDN-Integration und Minifizierung. Der Nachteil ist die Komplexitaet. W3 Total Cache hat Dutzende von Einstellungsseiten, und Fehlkonfiguration kann deine Seite kaputt machen. Es ist maechtig, aber besser geeignet fuer Entwickler oder fortgeschrittene Nutzer.
• WP Super Cache: Ein kostenloses Plugin, entwickelt von Automattic (dem Unternehmen hinter WordPress.com). Es konzentriert sich auf Page-Caching und haelt die Dinge einfach. WP Super Cache generiert statische HTML-Dateien und kann sie ueber mod_rewrite-Regeln ausliefern, was sehr schnell ist. Es fehlen die erweiterten Funktionen von WP Rocket und W3 Total Cache, aber es ist zuverlaessig und einfach zu konfigurieren.
• LiteSpeed Cache: Ein kostenloses Plugin, das aussergewoehnliche Performance bietet, wenn es mit LiteSpeed-Webservern verwendet wird. Es unterstuetzt Page-Caching, Object-Caching, Bildoptimierung, CSS/JS-Minifizierung und CDN-Integration. Wenn dein Hosting LiteSpeed nutzt (viele Shared Hosts tun das), nutzt dieses Plugin Server-Level-Caching, das schneller ist als PHP-basiertes Caching. Es funktioniert auch auf Apache und Nginx, aber mit eingeschraenkter Funktionalitaet.

Server-Level-Caching-Loesungen

Ueber WordPress-Plugins hinaus kann Caching auch auf Server-Ebene stattfinden, was oft schneller ist, weil es Anfragen abfaengt, bevor PHP ueberhaupt beteiligt ist:

• Varnish: Ein Reverse-Proxy-Cache, der vor deinem Webserver sitzt. Varnish speichert komplette Seitenantworten im Speicher und liefert sie direkt fuer gecachte Anfragen aus. Es ist extrem schnell (Antwortzeiten unter einer Millisekunde) und wird von hochfrequentierten WordPress-Seiten eingesetzt. Die Konfiguration erfordert VCL (Varnish Configuration Language), was eine Lernkurve hat.
• Nginx FastCGI Cache: Wenn dein Server Nginx nutzt (was viele moderne WordPress-Hoster tun), speichert FastCGI-Caching die komplette PHP-Ausgabe und liefert sie direkt von Nginx bei nachfolgenden Anfragen aus. Das ist schneller als jedes PHP-basierte Caching-Plugin, weil Nginx die Anfrage vollstaendig ohne PHP-Aufruf bearbeitet. Viele Managed-WordPress-Hoster (Kinsta, GridPane, SpinupWP) nutzen diesen Ansatz.
• Redis Full-Page-Cache: Einige Setups nutzen Redis nicht nur fuer Object-Caching, sondern auch fuer Full-Page-Caching. Das gecachte HTML wird im Redis-Speicher gespeichert, und ein kleines PHP-Script oder Nginx-Modul liefert es direkt aus. Das kombiniert die Geschwindigkeit von In-Memory-Speicher mit der Flexibilitaet von schluesselbasierter Cache-Invalidierung.

Object-Caching mit Redis und Memcached

Fuer WordPress-Seiten mit hoher Datenbanklast kann persistentes Object-Caching transformativ sein. So vergleichen sich die beiden Hauptoptionen:

• Redis: Die beliebtere Wahl fuer WordPress. Redis speichert Daten im Speicher und unterstuetzt komplexe Datentypen (Strings, Hashes, Listen, Sets). Es kann Daten auf der Festplatte persistieren, unterstuetzt Replikation und kann sowohl fuer Object-Caching als auch fuer Session-Speicherung verwendet werden. Das Redis Object Cache Plugin ist der gaengigste Weg, WordPress mit Redis zu verbinden.
• Memcached: Ein aelteres, einfacheres In-Memory-Caching-System. Memcached ist schnell und leichtgewichtig, aber es fehlen Redis' Datenpersistenz und erweiterte Funktionen. Es wird in einigen Hosting-Umgebungen noch eingesetzt, besonders in aelteren.

Persistentes Object-Caching macht den groessten Unterschied bei Seiten mit komplexen Abfragen: WooCommerce-Shops mit Tausenden von Produkten, BuddyPress-Communities, Multisite-Netzwerke oder jede Seite, bei der das WordPress-Admin-Dashboard traege wirkt.

Wenn Caching Probleme verursacht

Caching ist nicht immer unkompliziert. Es gibt Situationen, in denen aggressives Caching Probleme schafft:

• Eingeloggte Nutzer: Page-Caching darf eingeloggten Nutzern keine gecachten Seiten ausliefern, weil jeder Nutzer andere Inhalte sieht (seinen Namen im Header, die Admin-Bar, ein persoenliches Dashboard). Alle grossen Caching-Plugins handhaben das standardmaessig korrekt, aber benutzerdefinierte Implementierungen machen es manchmal falsch.
• WooCommerce und E-Commerce: Warenkorbseiten, Checkout-Seiten und "Mein Konto"-Seiten sind dynamisch und nutzerspezifisch. Sie muessen vom Page-Caching ausgeschlossen werden. WP Rocket und LiteSpeed Cache schliessen WooCommerce-Seiten automatisch aus. Bei anderen Plugins musst du die Ausschlussregeln moeglicherweise manuell konfigurieren.
• Dynamische Inhalte und AJAX: Wenn deine Seite stark auf per AJAX geladene Inhalte, Echtzeitdaten oder personalisierte Elemente (zuletzt angesehene Produkte, nutzerspezifische Empfehlungen) setzt, kann Full-Page-Caching veraltete Inhalte ausliefern. Loesungen umfassen Fragment-Caching (alles cachen ausser den dynamischen Teilen) oder das Laden dynamischer Inhalte per JavaScript, nachdem die gecachte Seite geladen wurde.
• Mitgliederseiten: Seiten mit mehreren Mitgliedschaftsstufen zeigen verschiedenen Nutzergruppen verschiedene Inhalte. Page-Caching muss diese Variationen beruecksichtigen, entweder durch Ueberspringen des Caches fuer eingeloggte Nutzer oder durch Pflege separater gecachter Versionen pro Nutzerrolle (was die meisten Plugins nicht unterstuetzen).
• Formulare und Nonces: WordPress verwendet Nonces (Number-Used-Once-Tokens) fuer Sicherheit in Formularen. Wenn eine Seite mit einem Formular gecacht wird, erhalten alle Besucher denselben Nonce, der ablaufen und zu Fehlern bei der Formularuebermittlung fuehren kann. Caching-Plugins handhaben das normalerweise, aber es ist eine haeufige Quelle von Problemen bei benutzerdefinierten Formularen.

Cache-Invalidierung: Der schwierige Teil

Es gibt einen beruehmten Spruch in der Informatik: "Es gibt nur zwei schwere Dinge in der Informatik: Cache-Invalidierung und die Benennung von Dingen." Cache-Invalidierung ist der Prozess, gecachte Inhalte zu loeschen oder zu aktualisieren, wenn sich die zugrundeliegenden Daten aendern. In WordPress bedeutet das:

• Wenn du einen Beitrag veroeffentlichst oder aktualisierst, sollte der Cache fuer diesen Beitrag, seine Kategorie-Archive, Tag-Archive, die Startseite und jede Seite, die aktuelle Beitraege anzeigt, geleert werden.
• Wenn du Theme-Einstellungen aenderst, sollte der gesamte Page-Cache geleert werden, weil jede Seite anders aussehen koennte.
• Wenn ein neuer Kommentar freigegeben wird, sollte die gecachte Version dieses Beitrags aktualisiert werden, um den neuen Kommentar anzuzeigen.

Gute Caching-Plugins handhaben die meisten dieser Szenarien automatisch ueber WordPress-Hooks. Sie lauschen auf Events wie save_post, switch_theme und wp_update_comment_count und loeschen die relevanten Cache-Eintraege. Wenn du allerdings benutzerdefinierten Code hast, der Inhalte aendert, ohne WordPress' Standardfunktionen zu nutzen, wird der Cache moeglicherweise nicht korrekt invalidiert.

Im Zweifelsfall bieten die meisten Caching-Plugins einen "Gesamten Cache leeren"-Button in der WordPress-Admin-Bar. Nutze ihn nach groesseren Aenderungen, wenn gecachte Seiten deine Aktualisierungen nicht widerspiegeln.

Was InspectWP prueft

InspectWP erkennt, ob ein WordPress-Caching-Plugin aktiv ist, indem es nach cache-bezogenen HTML-Kommentaren sucht (viele Plugins fuegen einen Kommentar wie <!-- Cached by WP Rocket --> am Seitenende ein), Response-Headern (wie X-Cache, X-Cache-Enabled oder X-LiteSpeed-Cache) und bekannten Plugin-Signaturen im Seitenquelltext. Der Report identifiziert, welches Caching-Plugin genutzt wird, damit du ueberpruefen kannst, ob dein Caching-Setup korrekt funktioniert. Wenn kein Caching erkannt wird, markiert InspectWP dies als Performance-Verbesserungsmoeglichkeit, da Caching eine der effektivsten Methoden ist, jede WordPress-Seite zu beschleunigen.