Foto von Mathew Schwartz auf Unsplash
Deine WordPress-Webseite baut jede einzelne Seite neu zusammen, jedes Mal, wenn jemand sie aufruft. PHP startet, fragt die Datenbank ab, lädt Theme und Plug-ins, setzt daraus HTML zusammen und schickt es los. Je nach Ausstattung dauert das zwischen 200 Millisekunden und über einer Sekunde, bevor der Browser das erste Zeichen sieht.
Ein Cache beendet diese Arbeit. Und er ist der Punkt, an dem am meisten schiefgeht, ohne dass es jemand merkt.
Was ein Cache in WordPress macht
Das fertige HTML einer Seite ändert sich zwischen zwei Aufrufen fast nie. Wer heute deine Leistungsseite öffnet und wer sie morgen öffnet, bekommt dasselbe zu sehen. Trotzdem rechnet WordPress ohne Cache jedes Mal von vorn.
Ein Cache legt das Ergebnis ab und liefert beim nächsten Aufruf die gespeicherte Fassung. Aus „Datenbank fragen, zusammenbauen, ausliefern” wird „Datei ausliefern”. Die Zeit bis zum ersten Byte fällt dabei häufig von mehreren hundert Millisekunden auf unter fünfzig.
Das wirkt sich auf zwei Dinge aus, die du messen kannst: die Ladezeit und die Core Web Vitals, die Google in die Bewertung einbezieht. Und es wirkt sich auf den Server aus, der bei einem Besucheransturm nicht mehr für jeden Aufruf dieselbe Rechnung anstellt.
Wie der Cache technisch arbeitet
„Cache” ist ein Sammelbegriff für mehrere Schichten, die unabhängig voneinander arbeiten. Wer nur die erste kennt, wundert sich später über Ergebnisse.
Seiten-Cache. Das fertige HTML wird als Datei abgelegt. Das ist die Schicht, um die es meistens geht, und die mit dem größten Effekt.
Objekt-Cache. Ergebnisse einzelner Datenbankabfragen werden zwischengespeichert, üblicherweise im Arbeitsspeicher über Redis oder Memcached. Das hilft dort, wo der Seiten-Cache nicht greifen kann, etwa im Backend oder bei angemeldeten Nutzern.
Opcode-Cache. PHP übersetzt seinen Quelltext bei jedem Aufruf in Maschinencode. OPcache speichert dieses Zwischenergebnis. Das läuft auf jedem ordentlichen Hosting ohne dein Zutun.
Browser-Cache. Der Server sagt dem Browser über Kopfzeilen, wie lange er Bilder, CSS und Schriften behalten darf. Beim zweiten Besuch lädt der Browser sie gar nicht erst neu.
Server-Cache oder Cache-Plugin: der Unterschied
Hier liegt der Unterschied, der über das Ergebnis entscheidet, und er wird selten erklärt.
Ein normales Cache-Plugin ist selbst ein Stück PHP. Damit es die gespeicherte Seite ausliefern kann, muss PHP starten, WordPress muss hochfahren, und erst dann greift das Plugin ein. Das ist immer noch viel schneller als der volle Aufbau, aber der Start kostet Zeit.
Ein serverseitiger Cache sitzt davor. Der Webserver selbst erkennt, dass er die Seite schon hat, und schickt sie raus, ohne PHP auch nur anzufassen. Der Unterschied liegt je nach Ausstattung bei 50 bis 150 Millisekunden pro Aufruf.
Cache-Plug-ins für WordPress im Überblick
Die Zahlen stammen aus dem WordPress-Plugin-Verzeichnis, Stand August 2026.
| Plugin | Installationen | Kosten | Wofür es taugt |
|---|---|---|---|
| LiteSpeed Cache | 7 Mio.+ | kostenlos | Erste Wahl auf LiteSpeed-Servern, dort mit Abstand am schnellsten |
| WP Rocket | nicht im Verzeichnis | 49 € / 99 € / 249 € im Jahr | Rundestes Paket für Apache und Nginx, wenig Einstellarbeit |
| WP Fastest Cache | 1 Mio.+ | frei, Premium optional | Einsteigerfreundlich, wenige Schalter |
| WP Super Cache | 1 Mio.+ | kostenlos | Von Automattic, sehr solide Grundfunktion |
| W3 Total Cache | 900.000+ | frei, Premium optional | Viele Stellschrauben, entsprechend leicht falsch einzustellen |
WP Rocket gibt es nur gegen Geld und nur beim Hersteller, deshalb fehlt es im Verzeichnis. Die 49 € gelten für eine Webseite und verlängern sich jährlich. Was das Plugin im Einzelnen kann und wie ich es einstelle, habe ich im Beitrag zu WP Rocket aufgeschrieben.
W3 Total Cache steht hier mit einer Warnung. Es kann am meisten, und genau deshalb sehe ich es bei Kunden am häufigsten falsch eingestellt. Wer sich nicht mit den Schichten oben beschäftigen will, ist mit einem der schlankeren Plug-ins besser bedient.
LiteSpeed Cache und warum der Server entscheidet
LiteSpeed Cache ist mit über sieben Millionen Installationen das meistgenutzte Cache-Plugin für WordPress, und es ist kostenlos. Der Haken steht in der eigenen Beschreibung: Die Cache-Funktionen brauchen einen LiteSpeed-Unterbau, also LiteSpeed Web Server Enterprise mit LSCache-Modul, OpenLiteSpeed, LiteSpeed WebADC oder das QUIC.cloud-CDN. Auf Apache oder Nginx fällt das Plugin auf gewöhnliches Datei-Caching zurück und verliert seinen Vorteil.
Läuft deine Webseite dagegen auf LiteSpeed, ist die Sache klar. Dann cacht das Plugin auf Serverebene, PHP bleibt aus, und du sparst dir die Lizenzkosten eines kostenpflichtigen Plug-ins.
Ob dein Hoster LiteSpeed einsetzt, siehst du an der Server-Kopfzeile deiner eigenen Webseite. Diese hier läuft bei FastPress und meldet server: LiteSpeed, deshalb setze ich in meinem WordPress-Hosting auf LiteSpeed Cache statt auf eine Jahreslizenz.
Stolperfallen: Wenn der Cache etwas kaputt macht
Ein Cache-Plugin einzuschalten dauert zwei Minuten. Die Prüfung danach dauert eine halbe Stunde, und sie ist der Teil, den fast alle überspringen.
Der Grund: Cache-Plug-ins bringen längst mehr mit als das Speichern von HTML. Sie fassen CSS und JavaScript zusammen, verzögern Skripte, laden Bilder erst beim Scrollen und erzeugen kritisches CSS. Jede dieser Optionen greift in den Aufbau deiner Webseite ein, und jede kann etwas zerlegen, das vorher lief.
Das sind die Stellen, an denen es bei mir am häufigsten klemmt:
- JavaScript zusammenfassen oder verzögern. Die mit Abstand größte Fehlerquelle, dazu unten mehr.
- Kritisches CSS. Das Plugin erzeugt für eine Vorlage einen abgespeckten Stil und lädt den Rest später. Wenn eine Unterseite eine andere Vorlage nutzt, springt das Layout beim Laden oder bleibt falsch.
- Warenkorb und Kasse. Bei WooCommerce müssen Warenkorb, Kasse und Konto vom Cache ausgenommen sein. Sonst sieht der zweite Kunde den Warenkorb des ersten.
- Angemeldete Nutzer. Redakteure, die Änderungen im Frontend nicht sehen, sind fast immer eine Cache-Frage, kein Fehler im Editor.
- Cookie-Banner und Einwilligungen. Wird die Seite mit einem gespeicherten Zustand ausgeliefert, erscheint der Banner erneut oder gar nicht.
- Bilder erst beim Scrollen laden. Beim ersten sichtbaren Bild ist das schädlich: Es wird später geladen und verschlechtert genau den Wert, den du verbessern wolltest.
Warum Kontaktformulare am Cache scheitern
Ein Kontaktformular besteht aus mehr als Feldern und einem Knopf. Dahinter liegen ein Skript für die Prüfung der Eingaben, meist ein Spamschutz und ein Sicherheitscode, den WordPress mitschickt und beim Absenden wieder erwartet.
Fasst das Plugin nun alle JavaScript-Dateien zu einer zusammen, ändert sich die Reihenfolge, in der sie ausgeführt werden. Ein Skript, das eine Bibliothek erwartet, die es noch nicht gibt, bricht ab. Sichtbar wird das nicht als Fehlermeldung, sondern als Knopf, der beim Klicken nichts tut.
Beim Verzögern ist es ähnlich. Die Option lädt JavaScript erst bei der ersten Bewegung des Nutzers, was die Messwerte hübsch aussehen lässt. reCAPTCHA muss aber beim Laden der Seite anlaufen, um das Verhalten zu bewerten. Kommt es zu spät, stuft es jede Einsendung als verdächtig ein.
Der Sicherheitscode ist der dritte Fall. Er hat eine begrenzte Gültigkeit. Wird die Formularseite mit einem alten Code aus dem Cache ausgeliefert, weist WordPress das Absenden ab, oft mit einer Meldung über eine fehlgeschlagene Sicherheitsprüfung.
Die Lösung ist in allen drei Fällen dieselbe: Nimm das Skript des Formular-Plug-ins vom Zusammenfassen und Verzögern aus, und schließe Seiten mit Formularen vom Cache aus. Jedes ernstzunehmende Cache-Plugin hat dafür eine Ausnahmeliste.
So prüfst du deine Webseite nach dem Einschalten
Diese Liste arbeite ich bei jeder Einrichtung ab, und zwar in einem privaten Fenster, damit ich nicht angemeldet bin:
- Jedes Formular absenden. Kontakt, Rückruf, Newsletter, Bewerbung. Bis die Bestätigung kommt und die Mail wirklich im Postfach liegt.
- Die Browser-Konsole öffnen. Rote Meldungen nach dem Einschalten sind fast immer Folgen des Zusammenfassens.
- Durch die Vorlagen klicken. Startseite, eine Leistungsseite, ein Beitrag, das Archiv, die 404-Seite. Kritisches CSS wird je Vorlage erzeugt.
- Bei WooCommerce bestellen. Produkt in den Warenkorb, zur Kasse, Testzahlung. Danach in einem zweiten Browser prüfen, ob der Warenkorb dort leer ist.
- An- und abmelden. Und als angemeldeter Nutzer eine Änderung machen, die sofort sichtbar sein muss.
- Auf dem Handy nachsehen. Viele Plug-ins cachen mobil getrennt, und Fehler zeigen sich oft nur dort.
- Cache leeren und alles wiederholen. Der erste Aufruf nach dem Leeren verhält sich anders als der zweite.
Dieselbe Runde gehört nach jedem größeren Update wiederholt. Ein Formular-Plugin, das seine Skripte umbenennt, hebelt deine Ausnahmeliste aus, ohne dass irgendwo eine Warnung erscheint.
Fazit zum WordPress-Cache
Die Wahl des Plug-ins ist die kleinere Entscheidung. Auf LiteSpeed nimmst du LiteSpeed Cache, auf Apache und Nginx WP Rocket oder eine der kostenlosen Alternativen. Damit ist der größte Teil des Tempogewinns geholt.
Die größere Entscheidung ist, wie viele der Zusatzoptionen du einschaltest. Jede davon bringt ein paar Punkte im Messwerkzeug und kann dir dafür ein Formular kosten, von dem du erst drei Wochen später erfährst, weil sich niemand meldet. Im Zweifel lieber eine Option weniger und dafür eine Webseite, die funktioniert.
Häufige Fragen zum WordPress-Cache
Brauche ich überhaupt ein Cache-Plugin?
Wenn deine Webseite auf WordPress läuft, in aller Regel ja. WordPress baut jede Seite bei jedem Aufruf neu zusammen, und das kostet je nach Theme und Anzahl der Plug-ins ein paar hundert Millisekunden bis über eine Sekunde. Ein Cache liefert stattdessen die fertige Datei aus. Eine Ausnahme sind Webseiten, deren Hoster bereits serverseitig cacht; dann kann ein zusätzliches Plugin sogar stören.
Welches Cache-Plugin ist das beste?
Das hängt am Server, nicht am Plugin. Auf einem LiteSpeed-Server ist LiteSpeed Cache die erste Wahl, weil es auf Serverebene arbeitet, noch bevor PHP startet. Diesen Vorteil kann ein reines PHP-Plugin technisch nicht einholen. Auf Apache oder Nginx liefert WP Rocket die verlässlichsten Ergebnisse, ist mit 49 € im Jahr aber kostenpflichtig. Wer kostenlos bleiben will, nimmt dort WP Fastest Cache oder WP Super Cache.
Warum funktioniert mein Kontaktformular nach dem Einschalten nicht mehr?
Meist liegt es an einer der JavaScript-Optionen. Wird das JavaScript aller Plug-ins zu einer Datei zusammengefasst oder verzögert geladen, laufen Skripte in einer anderen Reihenfolge oder zu spät. Formular-Prüfungen, Spamschutz und reCAPTCHA brechen dann ab. Ein zweiter Grund ist der Sicherheitscode des Formulars: Wird die Seite mit einem alten Code ausgeliefert, lehnt WordPress das Absenden ab. Abhilfe schafft, das Formular-Skript vom Zusammenfassen auszunehmen und die Formularseite vom Cache auszuschließen.
Wie oft muss ich den Cache leeren?
Im Normalbetrieb gar nicht. Gute Plug-ins leeren die betroffenen Seiten selbst, sobald du einen Beitrag speicherst. Von Hand leeren solltest du nach jedem Update von WordPress, Theme oder Plug-ins, nach Änderungen am CSS und immer dann, wenn eine Änderung im Backend sichtbar ist, im Frontend aber nicht.
Ersetzt ein Cache-Plugin gutes Hosting?
Nein. Ein Cache verkürzt die Zeit bis zur Auslieferung, er repariert keine überladene Webseite und keinen überlasteten Server. Wenn 40 Plug-ins laufen, unkomprimierte Bilder ausgeliefert werden oder die Datenbank aufgebläht ist, verschiebt der Cache das Problem nur auf den ersten Besucher jeder Seite. Tempo entsteht aus Hosting, sauberem Aufbau und Cache zusammen.
