SpeedupWP

WordPress-Performance mit Plan.

Page Cache passend zum Hosting auswählen

← Zur Wissensdatenbank

Typischer Nutzwert
Hoch
Aufwand
Mittel
Risiko
Mittel
Hosting / Umgebung
Abhängig von Webserver und Managed-Hosting-Stack
Voraussetzungen
Dynamische Ausnahmen und Cache-Header müssen bekannt sein
Aussagekraft
hoch
Zuletzt geprüft
17. August 2026

Cookbook: Ziel und Ergebnis

Du wählst genau eine federführende Full-Page-Cache-Schicht, die zum Webserver passt. Browser-, Object- und OPcache bleiben getrennte Ebenen und dürfen zusätzlich bestehen.

Rezept: Schritt für Schritt

  1. Im Hosting-Panel oder per Header feststellen, ob LiteSpeed, Nginx/FastCGI, Varnish oder ein Managed-Host-Cache bereits aktiv ist.
  2. Eine Testmatrix aus öffentlich, eingeloggt, Suche, Formular, Vorschau und – bei Shops – Warenkorb/Kasse anlegen.
  3. Zuerst nur HTML-Cache und Purge aktivieren. Minify, Delay, Bildoptimierung und Crawler bleiben aus.
  4. Nach erfolgreichem Funktionstest TTL und Ausnahmen passend zur Änderungsfrequenz festlegen.

Rechenweg oder Entscheidungsregel

Entscheidungsregel: Serverintegrierten Cache bevorzugen. LiteSpeed → LSCache; Managed WordPress → Host-Cache; Nginx/Varnish → Host- oder Serverkonfiguration; Apache ohne Cache → ein bewährter dateibasierter Cache. Nie zwei Plugins gleichzeitig fertiges HTML cachen lassen.

Hit-Rate = Cache-Hits / (Hits + Misses) × 100\nUrsprungsersparnis ≈ Hits × mittlere dynamische Rechenzeit

Praxisbeispiel

Eine Inhaltsseite wird 10.000-mal täglich aufgerufen, dynamisch 650 ms, als Hit 90 ms. Bei 90 % Hit-Rate vermeidet der Cache grob 9.000 vollständige WordPress-Ausführungen. Für einen Shop bleiben Warenkorb, Kasse, Konto und kundenspezifische Varianten ungecacht.

Prüfen, ob es funktioniert

  • Zweiter anonymer Abruf ist nachweislich ein Hit und deutlich schneller.
  • Bearbeiten eines Artikels invalidiert genau die betroffenen Ansichten.
  • Cookies oder Login führen niemals zur Auslieferung fremder Inhalte.

Rollback

Neue Cache-Schicht deaktivieren, ihre Dateien über die vorgesehene Plugin-/Host-Funktion leeren und ursprünglichen Host-Cache wieder aktivieren. Keine Cache-Verzeichnisse blind im Dateisystem löschen.

Grundsatz

Ein Page Cache speichert fertiges HTML und umgeht bei Cache-Hits einen großen Teil von PHP und Datenbankarbeit. Der beste Cache ist der, der mit dem vorhandenen Server-Stack integriert ist und korrekte Ausnahmen beherrscht.

Entscheidung nach Umgebung

Umgebung Bevorzugter Ansatz
LiteSpeed/OpenLiteSpeed LSCache auf Serverebene plus LiteSpeed-WordPress-Plugin.
Managed WordPress Host-Cache zuerst; kein zweiter Full-Page-Cache ohne Freigabe des Hosts.
Nginx/Varnish Host- oder Server-Cache nutzen; Plugin nur als Steuerung, falls unterstützt.
Apache ohne Host-Cache Bewährter dateibasierter WordPress-Page-Cache ist meist pragmatisch.

Nicht blind aktivieren

Mehrere HTML-Caches können widersprüchliche Purges, veraltete Inhalte und schwer auffindbare Cookie-Probleme verursachen. Separat davon sind Browser-, Object- und Opcode-Cache andere Ebenen und können sinnvoll kombiniert werden.

Erfolgskontrolle

Prüfe bei zwei anonymen Abrufen Cache-Hit-Header und deutlich niedrigere Serverzeit. Teste danach Login, Formulare, Vorschau, Suche und personalisierte Seiten. Inhalte müssen nach Änderungen zuverlässig invalidiert werden.

Quellen und Prüfstand

Inhalt fachlich geprüft am 17. August 2026. Konkrete Werte sind Ausgangspunkte, keine Universaldosierung.