LiteSpeed Cache für WordPress: die Einstellungen, die wirklich zählen

02.09.2026 · 10 Min. Lesezeit

LiteSpeed Cache (LSCWP) ist das mit Abstand mächtigste kostenlose Caching-Plugin für WordPress — und gleichzeitig das mit der steilsten Lernkurve. Über 200 einzelne Schalter verteilt auf ein Dutzend Reiter führen in der Praxis zu zwei Extremen: Entweder wird nur der Page-Cache eingeschaltet und der Rest nie angefasst, oder es wird reihenweise alles aktiviert — bis das Layout bricht und am Ende wieder alles ausgeht.

Dieser Artikel zeigt, welche Einstellungen tatsächlich messbar etwas bringen, welche du besser in Ruhe lässt, und in welcher Reihenfolge du vorgehst.

Erst prüfen: Läuft deine Seite überhaupt auf LiteSpeed?

Das Plugin besteht aus zwei völlig getrennten Hälften, und diese Unterscheidung entscheidet über alles Weitere:

• Der Server-Cache funktioniert ausschließlich auf LiteSpeed Enterprise oder OpenLiteSpeed. Auf Apache oder nginx bleibt der komplette Cache-Reiter wirkungslos.
• Der Optimierungsteil (CSS, JavaScript, Bilder, Lazy Load, Datenbank) läuft auf jedem Server.

Ob dein Hosting LiteSpeed einsetzt, siehst du am Response-Header:

curl -sI https://deinedomain.de | grep -i -E 'server|litespeed'

Erscheint dort server: LiteSpeed und nach dem zweiten Aufruf x-litespeed-cache: hit, arbeitet der Server-Cache. Fehlt die Zeile, hast du zwei Möglichkeiten: das Hosting wechseln, oder QUIC.cloud als Cache-Ebene davorschalten — dazu unten mehr.

Der Page-Cache: die Basis

Unter LiteSpeed Cache → Cache liegen die Grundeinstellungen. Die Standardwerte sind für die meisten Seiten brauchbar; wichtig sind vor allem diese Punkte:

• Cache aktivieren: an. Ohne diesen Schalter macht der Rest des Reiters nichts.
• Cache für eingeloggte Nutzer: aus. Bei Shops und Mitgliederseiten führt dieser Schalter am zuverlässigsten zu vertauschten Inhalten zwischen Benutzern.
• Cache REST API: an, solange du keine personalisierten REST-Endpunkte ausliefert.
• TTL für öffentliche Seiten: Der Standard von einer Woche ist völlig in Ordnung. Entscheidend ist nicht die Lebensdauer, sondern dass beim Veröffentlichen sauber geleert wird.
• Purge All On Upgrade: an. Nach jedem Plugin- oder Theme-Update ist der alte Cache potenziell inkonsistent.
• Browser-Cache: an, wenn dein Server nicht ohnehin passende Cache-Control-Header setzt.

Der Page-Cache allein bringt bereits den größten Sprung beim TTFB — von mehreren hundert Millisekunden PHP-Ausführung auf eine direkt ausgelieferte HTML-Datei. Wie weit sich dieser Wert treiben lässt, steht im Artikel TTFB unter 200 ms.

ESI: der eigentliche Unterschied zu anderen Plugins

Edge Side Includes sind der Grund, warum LiteSpeed auf dynamischen Seiten Vorteile gegenüber klassischen Caching-Plugins hat. Die Idee: Eine Seite wird vollständig gecacht, einzelne Fragmente werden davon ausgenommen und bei jedem Aufruf frisch eingesetzt — der Warenkorb-Zähler, die Begrüßung mit dem Benutzernamen, ein Nonce-Feld.

Ohne ESI bleibt bei solchen Seiten nur die Alternative, gar nicht zu cachen. Mit ESI ist der statische Teil der Seite trotzdem im Cache.

Die Einstellung liegt unter Cache → ESI. Zwei Hinweise aus der Praxis:

• ESI setzt einen LiteSpeed-Server voraus. Auf Apache oder nginx passiert nichts.
• Falsch abgegrenzte ESI-Blöcke sind die häufigste Ursache für Berichte über „falsche Warenkorbinhalte". Nach der Aktivierung unbedingt mit zwei verschiedenen Browsern gegentesten — einmal eingeloggt, einmal anonym.

CSS und JavaScript: hier bricht es am ehesten

Der Reiter Page Optimization enthält die wirksamsten und zugleich riskantesten Optionen. Die pragmatische Reihenfolge:

1. Minify CSS und JS — risikoarm, kleiner, aber sicherer Gewinn. Fang hiermit an.

2. Combine CSS / Combine JS — lass diese Schalter aus. Das Zusammenfassen vieler Dateien zu einer war unter HTTP/1.1 sinnvoll, weil parallele Verbindungen knapp waren. Unter HTTP/2 und HTTP/3 überträgt der Browser Dateien gemultiplext über eine Verbindung; Combine bringt dann kaum noch etwas, zerstört aber das granulare Browser-Caching und ist mit weitem Abstand die häufigste Ursache für kaputte Layouts und JavaScript-Fehler nach der Aktivierung. Warum das so ist, steht ausführlich in HTTP/3 für WordPress.

3. Load JS Deferred — spürbarer Hebel für TBT und INP, weil Skripte den Hauptthread nicht mehr vor dem Rendern blockieren. Aber: Slider, Consent-Banner und Analytics-Snippets reagieren empfindlich. Nach der Aktivierung jede Seitenvorlage einmal durchklicken.

4. Unused CSS (UCSS) und Critical CSS (CCSS) — der stärkste verbleibende Hebel gegen render-blocking Ressourcen. LSCWP ermittelt pro Seitentyp, welche CSS-Regeln tatsächlich gebraucht werden, liefert diese inline aus und lädt den Rest verzögert nach. Zwei Einschränkungen: Die Berechnung läuft über QUIC.cloud, du brauchst also eine Verbindung dorthin. Und Elemente, die erst per JavaScript erscheinen (Menüs, Modals, Akkordeons), landen regelmäßig fälschlich im Papierkorb — dafür gibt es die UCSS-Ausnahmeliste.

5. Font Display: swap — verhindert unsichtbaren Text während des Schriftladens und verbessert damit direkt den LCP.

Der wichtigste Grundsatz für diesen Reiter: eine Einstellung nach der anderen, danach jeweils messen und die Seite durchklicken. Wer fünf Schalter gleichzeitig umlegt und danach einen Fehler sieht, weiß nicht, welcher es war — und schaltet erfahrungsgemäß alles wieder aus.

Bilder: der häufigste Selbstschuss

Unter Image Optimization konvertiert LSCWP deine Mediathek nach WebP und komprimiert sie. Die Verarbeitung läuft über eine QUIC.cloud-Warteschlange, bei großen Mediatheken dauert der erste Durchlauf entsprechend.

Zwei Einstellungen entscheiden hier über Erfolg oder Rückschritt:

• Lazy Load Images: grundsätzlich sinnvoll — aber das LCP-Element darf niemals lazy geladen werden. Genau das passiert standardmäßig bei Hero-Bildern, und der LCP verschlechtert sich durch die Optimierung. LSCWP bietet dafür Lazy Load Image Excludes sowie die Option, die ersten Bilder im Viewport auszunehmen. Diese Ausnahme ist Pflicht, nicht Kür.
• Add Missing Sizes: an. Ergänzt fehlende width- und height-Attribute und verhindert damit Layoutsprünge, die sonst direkt in den CLS einfließen.

Objekt-Cache und Datenbank

Der Page-Cache hilft nicht bei Anfragen, die per Definition nicht gecacht werden: Warenkorb, Checkout, Login, das gesamte Backend. Genau dort greift der Objekt-Cache.

Unter Cache → Object verbindest du Redis oder Memcached, sofern dein Hosting das anbietet. Der Effekt ist bei WooCommerce und mitgliederbasierten Seiten am deutlichsten spürbar, weil wiederkehrende Datenbankabfragen im Speicher beantwortet werden.

Der Reiter Database räumt zusätzlich auf: alte Post-Revisionen, abgelaufene Transients, verwaiste Metadaten. Das ist kein Performance-Wunder, hält aber die Tabellen schlank — und vor allem: erst ein Backup, dann aufräumen.

QUIC.cloud: wann es sich lohnt

QUIC.cloud ist der zugehörige CDN- und Verarbeitungsdienst. Er ist für drei Dinge relevant:

• Bildoptimierung und WebP-Konvertierung laufen darüber.
• UCSS und Critical CSS werden dort berechnet.
• Edge-Caching funktioniert auch dann, wenn dein Hosting kein LiteSpeed einsetzt — damit wird das Plugin auch auf Apache- und nginx-Servern zur echten Cache-Lösung.

Ein kostenloses Monatskontingent deckt kleine bis mittlere Seiten ab. Zwei Punkte solltest du vorher klären: Bei aktivem CDN läuft dein Traffic über einen US-Anbieter, du brauchst also einen Auftragsverarbeitungsvertrag und einen passenden Eintrag in der Datenschutzerklärung. Und die Bildoptimierung überträgt deine Mediathek zur Verarbeitung — bei sensiblen Inhalten ist das eine bewusste Entscheidung.

Die fünf häufigsten Fehler

1. Alles auf einmal aktivieren. Danach ist unklar, welcher Schalter das Layout zerlegt hat.
2. Combine CSS/JS anlassen. Unter HTTP/2 und HTTP/3 kaum Nutzen, viel Risiko.
3. Das LCP-Bild lazy laden. Die Optimierung verschlechtert dann genau die Metrik, die verbessert werden sollte.
4. Cache für eingeloggte Nutzer bei WooCommerce ohne ESI. Der schnellste Weg zu vertauschten Warenkörben.
5. Eingeloggt testen. Als angemeldeter Administrator siehst du fast nie den Cache — Messungen gehören ins private Fenster.

Was du danach misst

Optimieren ohne Messen ist Raten. Die vier Werte, die bei LSCWP tatsächlich Auskunft geben:

• TTFB — zeigt, ob der Page-Cache greift. Vergleiche den ersten Aufruf einer Seite (Cache-Miss) mit dem zweiten (Cache-Hit). Liegt der zweite nicht deutlich niedriger, arbeitet der Cache nicht.
• LCP — reagiert auf Bildoptimierung, Critical CSS und die Lazy-Load-Ausnahme.
• TBT — reagiert auf „Load JS Deferred".
• CLS — reagiert auf „Add Missing Sizes" und auf Font Display.

Mit turbometrics scannst du deine Seite vor und nach jeder Änderung und siehst die vier Werte nebeneinander im Verlauf — inklusive Alert, wenn ein Plugin-Update die Konfiguration wieder zunichtemacht. Wie sich Laborwerte und echte Besucherdaten dabei unterscheiden, steht in Core Web Vitals messen.

Fazit

LiteSpeed Cache ist kein Plugin, das man einmal aktiviert und danach vergisst. Die Kurzfassung:

1. Prüfen, ob ein LiteSpeed-Server läuft — davon hängt ab, welche Hälfte des Plugins überhaupt arbeitet.
2. Page-Cache und Browser-Cache aktivieren, eingeloggte Nutzer aussparen.
3. Minify ja, Combine nein.
4. UCSS und Critical CSS einschalten und die Ausnahmeliste pflegen.
5. Lazy Load aktivieren, das LCP-Bild ausnehmen.
6. Objekt-Cache anbinden, wenn Redis oder Memcached verfügbar ist.

Und nach jeder einzelnen Änderung messen, statt am Ende zu raten.

Jetzt kostenlos scannen →