SpeedupWP

WordPress-Performance mit Plan.

LiteSpeed Cache: sichere Grundeinstellung statt Maximalmodus

← Zur Wissensdatenbank

Typischer Nutzwert
Hoch
Aufwand
Mittel
Risiko
Mittel
Hosting / Umgebung
Nur LiteSpeed/OpenLiteSpeed oder QUIC.cloud-Integration
Voraussetzungen
Serverseitiges LSCache-Modul und funktionierende Purges
Aussagekraft
hoch
Zuletzt geprüft
17. August 2026

Cookbook: Ziel und Ergebnis

Eine stabile LSCache-Basis liefert öffentliches HTML schnell aus, ohne aggressive Optimierungsoptionen oder unnötige Varianten. Diese Anleitung setzt tatsächlich aktives LiteSpeed-Server-Caching voraus.

Rezept: Schritt für Schritt

  1. Unter LiteSpeed Cache → Toolbox/Report prüfen, ob das Servermodul aktiv ist; zweimalige Header-Messung durchführen.
  2. Öffentlichen Cache einschalten, eingeloggte Nutzer zunächst auslassen, REST und Login nicht cachen. Mobile Cache nur bei abweichendem mobilen HTML.
  3. Als Startwert für häufig gepflegte Inhalte 1–7 Tage Public TTL wählen; Purge bei Änderungen muss funktionieren. TTL ist kein Ersatz für Purge.
  4. Guest Mode, CSS/JS-Kombination, UCSS, Delay, ESI und Crawler einzeln und nur bei messbarem Bedarf testen.

Rechenweg oder Entscheidungsregel

Varianten = URLs × Gerätevarianten × Sprachen × Cookie-/Rollenvarianten\nWarmup-Requests/h = Varianten / gewünschte Warmup-Stunden

Responsive CSS erzeugt keine Gerätevariante. Jede unnötige Vary-Dimension senkt Hit-Rate und erhöht Speicher sowie Crawlerlast.

Praxisbeispiel

2.000 URLs, 2 Sprachen und unnötiger Mobile Cache ergeben 8.000 Varianten. Bei vier Stunden Warmup wären das 2.000 Ursprungsaufrufe pro Stunde. Liefert das Theme identisches HTML, halbiert das Abschalten des Mobile Cache die Last.

Prüfen, ob es funktioniert

  • x-litespeed-cache: hit erscheint beim wiederholten anonymen Abruf.
  • Änderung, Menü, Kommentarstatus und relevante Archive werden korrekt gepurgt.
  • Login, Vorschau, Formulare, Consent und WooCommerce funktionieren in zwei getrennten Browser-Sitzungen.

Rollback

Zuletzt aktivierte LSCache-Option zurücksetzen, über die Toolbox alle LSCache-Ebenen gezielt leeren und Testmatrix wiederholen. Bei 5xx zuerst Optimierer/Crawler deaktivieren, nicht das gesamte Plugin löschen.

Empfohlene Basis

Aktiviere zuerst nur den öffentlichen Page Cache mit nachvollziehbarer TTL und automatischem Purge. Lass eingeloggte Nutzer, REST-Anfragen und private/personaliserte Antworten ungecacht, solange ein konkreter Anwendungsfall nichts anderes verlangt.

Wichtige Abhängigkeiten

  • Mobile Cache: nur wenn das Theme tatsächlich anderes HTML für Mobilgeräte liefert. Responsive CSS allein braucht keinen getrennten Cache.
  • Cache Vary: jede Variante multipliziert Cache-Dateien und Warmup-Aufwand.
  • Crawler: kann erhebliche CPU- und I/O-Last erzeugen; bei kleinen Seiten meist nicht nötig.
  • Gastmodus/Optimierung: gegen reale erste Besuche, Consent und Personalisierung testen.

Stufenweise aktivieren

Nach stabilem Page Cache können CSS-/JS-Optimierung und Medienfunktionen einzeln getestet werden. Kombinieren, verzögern oder Critical CSS erzeugen verändert Ausführungsreihenfolgen und kann Layout sowie Interaktionen brechen.

Erfolgskontrolle

Prüfe LSCache-Hit-Header, Cache-Größe, Purge nach Bearbeitung und Serverlast. Wiederhole Funktionstests nach jeder zusätzlichen Optimierungsoption.

Quellen und Prüfstand

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