Caching in einem Satz
Stell dir eine Bäckerei vor. Ohne Cache backt sie jedes Brötchen erst, wenn jemand danach fragt. Mit Cache liegen morgens schon Brötchen in der Auslage, und der Kunde bekommt sofort eins. WordPress funktioniert ohne Cache wie die erste Bäckerei: Bei jedem Aufruf holt es Texte, Einstellungen und Elementor-Daten aus der Datenbank, führt den Code aller Plugins aus und baut daraus die Seite. Ein Cache hebt das Ergebnis auf und gibt es beim nächsten Mal direkt heraus.
Die vier Cache-Arten in WordPress
„Cache“ meint in WordPress vier verschiedene Dinge. Sie arbeiten an unterschiedlichen Stellen und ergänzen sich.
| Cache-Art | Was wird aufgehoben? | Wo? | Wer profitiert? |
|---|---|---|---|
| Seiten-Cache | die fertige HTML-Seite | auf deinem Server, als Datei | Besucher, die nicht angemeldet sind |
| Browser-Cache | Bilder, CSS, JavaScript, Schriften | im Browser des Besuchers | wiederkehrende Besucher und jeder weitere Seitenaufruf |
| Objekt-Cache | Ergebnisse von Datenbankabfragen | im Arbeitsspeicher des Servers (Redis, Memcached) | alle, auch angemeldete Nutzer und das Backend |
| Opcode-Cache | der übersetzte PHP-Code | im Arbeitsspeicher des Servers (OPcache) | alle, bei jedem Aufruf |
Seiten-Cache
Der Seiten-Cache bringt am meisten. Beim ersten Aufruf baut WordPress die Seite wie immer, das Cache-Plugin speichert das fertige HTML als Datei. Alle weiteren Besucher bekommen diese Datei, ohne dass WordPress, die Datenbank oder die Plugins noch arbeiten müssen. Genau dafür sind Plugins wie WP Rocket, WP Super Cache oder W3 Total Cache da.
Der Haken: Für angemeldete Nutzer, den Warenkorb, die Kasse und das Backend gibt es keinen Seiten-Cache, denn dort sieht jeder etwas anderes. Deshalb hilft ein Seiten-Cache nicht gegen ein langsames Backend.
Browser-Cache
Der Browser-Cache spart nicht Serverzeit, sondern Datenmenge. Dein Server sagt dem Browser, wie lange er Bilder, CSS und Schriften aufbewahren darf. Beim nächsten Besuch lädt der Browser sie nicht noch einmal. Viele Hoster und Cache-Plugins stellen das über die Datei .htaccess ein.
Objekt-Cache
Der Objekt-Cache merkt sich Ergebnisse von Datenbankabfragen im Arbeitsspeicher. WordPress hat ihn eingebaut, aber nur für die Dauer eines Aufrufs. Damit er von Aufruf zu Aufruf hält, braucht es einen Dienst wie Redis oder Memcached beim Hoster und ein passendes Plugin. Er hilft vor allem dort, wo der Seiten-Cache nicht greift: im Backend, im Shop und für angemeldete Nutzer.
Opcode-Cache
PHP übersetzt seinen Code vor dem Ausführen in eine Maschinensprache. Der Opcode-Cache (OPcache) hebt diese Übersetzung auf. Er ist bei fast allen Hostern schon an, auch bei unserem. Du musst dich darum in der Regel nicht kümmern.
Was ein Seiten-Cache bei uns gebracht hat
Wir haben unsere Elementor-Testseite zweimal gemessen: ohne Cache-Plugin und mit WP Rocket in den Standardeinstellungen. Gemessen haben wir die Zeit bis zum ersten Byte direkt am Server, jeweils 20-mal.
| Situation | Ohne Seiten-Cache | Mit Seiten-Cache |
|---|---|---|
| Besucher (nicht angemeldet) | 684 ms | 386 ms |
| Angemeldeter Nutzer | 647 ms | 802 ms |
| Erster Besucher nach dem Leeren des Caches | – | 813 ms |
| Ladezeit mobil (LCP, Lighthouse) | 4,53 s | 4,79 s |
Für Besucher kam die erste Antwort mit Seiten-Cache 298 ms früher. Den größten Teil der übrigen Zeit kann kein Cache verkürzen: Eine kleine statische Datei ohne jedes PHP brauchte bei uns 256 ms. Das ist der Weg durchs Internet und der Verbindungsaufbau. Angemeldet wartete man mit WP Rocket sogar etwas länger als ohne (802 statt 647 ms), denn für angemeldete Nutzer baut WordPress jede Seite neu, und das Cache-Plugin läuft zusätzlich mit. Und der erste Besucher nach dem Leeren des Caches wartete 813 ms, weil WordPress die Seite für ihn erst bauen und speichern muss.
Die Ladezeit am Handy hängt aber nicht nur vom Server ab. Sie wartet auch auf CSS, Schriften und Bilder. Deshalb bringt ein Seiten-Cache allein mobil oft wenig. Wie du die übrigen Bremsen löst, zeigen wir in WP Rocket für Elementor einrichten.
Browser-Cache: der zweite Besuch
Wir haben die Startseite in einem frischen Browser zweimal hintereinander geöffnet. Beim ersten Besuch gingen 62 Anfragen mit 864 KB über die Leitung. Beim zweiten Besuch waren es nur noch 1 Anfrage mit weniger als 1 KB, die übrigen 61 Dateien kamen aus dem Browser-Cache. Das klappte schon ohne Cache-Plugin genauso (14 KB), weil unser Hoster die nötigen Angaben von sich aus mitschickt. Prüfe das bei deinem Hoster, bevor du dafür ein Plugin einschaltest.
Warum Elementor besonders profitiert
Elementor speichert jede Seite als Datenpaket und baut daraus bei jedem Aufruf das HTML. Das kostet Zeit: Auf unserer Testseite brauchte der Server dafür ohne Cache rund 251 ms, mit 50 zusätzlichen Plugins sogar über eine Sekunde (siehe Wie viele Plugins sind zu viele?). Mit Seiten-Cache fällt diese Arbeit für Besucher weg.
So prüfst du, ob deine Seite aus dem Cache kommt
- Melde dich ab oder öffne ein privates Browserfenster. Angemeldet bekommst du keine Seite aus dem Cache.
- Öffne deine Startseite zweimal. Der erste Aufruf füllt den Cache.
- Rechtsklick auf die Seite und Seitenquelltext anzeigen wählen.
- Ganz nach unten scrollen. Steht dort ein Kommentar deines Cache-Plugins (bei WP Rocket zum Beispiel „This website is like a Rocket“), kam die Seite aus dem Cache.
Wann Caching Probleme macht
- Änderungen sind nicht sichtbar. Die meisten Plugins leeren den Cache einer Seite automatisch, wenn du sie speicherst. Bei Änderungen an Header, Footer, Menüs oder globalen Farben musst du oft den ganzen Cache leeren.
- Persönliche Inhalte. Warenkorb, Kasse, Kundenkonto und Seiten mit „Hallo, Name“ dürfen nicht aus dem Cache kommen. Gute Plugins nehmen WooCommerce-Seiten automatisch aus.
- Formulare auf alten Cache-Seiten. Formulare nutzen oft einen Sicherheitscode, der nach einiger Zeit abläuft. Bleibt eine Seite länger im Cache, kann das Absenden scheitern. Plugins wie WP Rocket erneuern den Cache deshalb regelmäßig.
- Zwei Cache-Plugins gleichzeitig. Das bremst eher, als dass es hilft, und macht Fehler schwer zu finden. Nutze genau eins.
Welches Plugin?
Für Elementor-Seiten auf Shared Hosting haben wir WP Rocket im Detail gemessen, mit jeder einzelnen Einstellung: WP Rocket für Elementor einrichten. Einen Vergleich mit kostenlosen Plugins findest du bald hier.
Für Technikinteressierte: Testaufbau und Rohdaten
- Labor: WordPress 7.1.4, PHP 8.4 mit OPcache, Hello Elementor 3.5.2, Elementor 4.3.6, Elementor Pro 4.3.2, Shared Hosting bei All-Inkl. Referenzseite mit Hero-Bild, Icon-Boxen, Kundenstimmen-Slider, Galerie, Akkordeon, Formular und Popup. Methodik
- Zustände: ohne Cache-Plugin (Snapshot „basis“) und WP Rocket 3.24 mit allen Standardwerten einer Neuinstallation (Seiten-Cache, mobiler Cache, CSS und JavaScript minifizieren, Links vorladen).
- Server: Zeit bis zum ersten Byte mit curl, 20 Abrufe als Besucher und 10 als angemeldeter Administrator, nach drei Aufwärm-Abrufen. „Erster Besucher nach dem Leeren“: vor jedem der 8 Abrufe den ganzen Cache von WP Rocket geleert.
- Browser-Cache: Chrome mobil, 5 frische Browser, je zwei Besuche der Startseite. Gezählt wurden Anfragen und Bytes, die wirklich über das Netz gingen.
- Lighthouse 13.5.0, je 5 Läufe mobil (gedrosselt) und Desktop.
- Rohdaten: rohdaten.csv. Gemessen am 8. November 2026.
