CDN und Cache: Setup für schnelle Shops

Seiten-Cache baut fertiges HTML auf dem Server, das CDN verteilt Dateien naeher zum Nutzer
Seiten cachst du für nicht eingeloggte Besucher, Warenkorb und Kasse bleiben frisch
ESI cacht den statischen Teil der Seite, der Mini-Warenkorb bleibt live
Object Cache mit Redis entlastet die Datenbank bei schweren WooCommerce-Abfragen
Der Purge muss Preis- und Bestandsaenderungen erfassen, sonst sieht der Kunde Altes
[/dwb_keytakeaways]

Seiten-Cache und CDN sind zwei verschiedene Dinge

Die meisten werfen Cache und CDN in einen Topf, dabei sind es zwei getrennte Schichten mit unterschiedlichen Aufgaben. Bevor du im Shop irgendetwas einstellst, lohnt es sich, diesen Unterschied zu verstehen, denn davon hängt die gesamte weitere Konfiguration ab.

• Seiten-Cache: Der Server speichert fertiges HTML einer Seite, damit es nicht bei jedem Aufruf neu gebaut wird. Ohne Cache startet WordPress bei jedem Besuch PHP, fragt die Datenbank und setzt die Seite zusammen. Mit Cache liefert er die fertige Datei in Sekundenbruchteilen.
• CDN (Content Delivery Network): Ein Netz aus Servern weltweit, das Kopien deiner statischen Dateien (Bilder, CSS, JavaScript) nahe beim Nutzer hält. Ein Kunde aus München lädt das Bild von einem Server in der Nähe und nicht vom anderen Ende Europas.
• Object Cache: Eine dritte Schicht, die Ergebnisse von Datenbankabfragen im Speicher hält. Dazu gleich mehr, denn im Shop spielt sie eine große Rolle.

In einem schnellen Shop arbeiten diese Schichten zusammen. Der Seiten-Cache verkürzt die Antwortzeit des Servers, das CDN verkürzt den Datenweg zum Nutzer, und der Object Cache entlastet die Datenbank. Werden sie verwechselt, aktiviert jemand meist zwei Dinge gleichzeitig, die sich gegenseitig stören.

Was du im Shop cachst und was nie

Das ist die wichtigste Entscheidung der gesamten Konfiguration und die Stelle, an der Fehler am leichtesten passieren. Ein Shop hat öffentliche Seiten, die für alle gleich aussehen, und private Seiten, die die Daten einer konkreten Person zeigen.

Öffentliche Seiten cachst du bedenkenlos für nicht eingeloggte Besucher: Startseite, Kategorien, Produktseiten, Blogbeiträge, Kontaktseite. Sie bringen den meisten Traffic und profitieren am stärksten vom Cache.

Private Seiten müssen immer frisch sein und landen nie im normalen Seiten-Cache: Warenkorb, Mein Konto, Kasse, Zahlungsseite. Sie zeigen die Daten einer eingeloggten Person, Preise nach Rabatt, den Inhalt des Warenkorbs. Landeten sie im Cache, sähe der Kunde fremde Daten, und das wäre ein Desaster.

ESI: eine Seite mit dynamischem Warenkorb cachen

Hier entsteht ein natürliches Problem. Eine Produktseite ist größtenteils statisch, aber im Header steckt ein Mini-Warenkorb, der die Anzahl der Produkte und den Betrag für eine konkrete Person zeigt. Wie cachst du die Seite, wenn ein Teil davon immer anders ist?

Die Lösung heißt ESI (Edge Side Includes). Dabei cachst du den statischen Teil der Seite, während kleine dynamische Fragmente (Mini-Warenkorb, Begrüßung des eingeloggten Kunden) live ausgeliefert werden. LiteSpeed Cache hat dafür einen eigenen WooCommerce-Bereich. So lädt die Produktseite blitzschnell aus dem Cache, und der Mini-Warenkorb im Header zeigt immer den aktuellen Stand.

Das ist ein wichtiger Unterschied zu einfachen Cache-Plugins, die Seiten mit veränderlichem Fragment entweder gar nicht cachen oder komplett cachen und dann den falschen Warenkorb-Stand zeigen. ESI liefert beides: die Geschwindigkeit des Caches und korrekte Daten.

Object Cache mit Redis: die Datenbank entlasten

WooCommerce fragt beim Aufbau einer einzigen Seite die Datenbank gern dutzende Male ab: Preise, Bestände, Attribute, Varianten, Optionen. Bei wenig Traffic schafft die Datenbank das problemlos. Bei großem Katalog und Traffic aus Werbung wird sie zum Engpass.

Object Cache speichert die Ergebnisse dieser Abfragen über Redis im RAM. Statt die Datenbank immer wieder nach denselben Daten zu fragen, holt der Shop sie in Mikrosekunden aus dem Speicher. Das Ergebnis: weniger Last auf der Datenbank, stabilere Antwortzeiten und weniger Einbrüche bei Lastspitzen.

• Kleiner Shop mit gutem Seiten-Cache: Redis ist nicht zwingend, der Seiten-Cache deckt den Grossteil des Traffics von nicht eingeloggten Besuchern ab.
• Großer Katalog, viele eingeloggte Kunden, Traffic aus Werbung: Hier hilft Object Cache spürbar, denn eingeloggte Nutzer umgehen den Seiten-Cache und jede ihrer Aufrufe belastet die Datenbank.
• B2B-Shop mit Preisen nach Login: Object Cache oft wichtiger als der Seiten-Cache, weil fast jeder Nutzer eingeloggt ist.

Cloudflare als CDN: Bilder und statische Dateien naeher zum Kunden

Cloudflare ist das beliebteste CDN und im Shop ideal, um statische Dateien zu verteilen: Produktbilder, CSS, JavaScript und Schriften. Der Kunde lädt sie von einem Server in seiner Nähe statt von deinem Hosting, was die Ladezeit verkürzt, besonders bei vielen Produktfotos.

Cloudflare verbindest du mit LiteSpeed Cache über einen API-Token mit der Berechtigung zum Leeren des Zonen-Caches. So leert Cloudflare seine Kopie mit, wenn LiteSpeed nach einer Inhaltsaenderung den Cache leert, und es bleibt keine alte Version stehen. Das ist entscheidend, denn ein CDN ohne synchronisierten Purge liefert eine veraltete Datei sonst monatelang aus.

Eine Bedingung wird leicht übersehen: Aktiviere den Seiten-Cache nicht gleichzeitig in Cloudflare und LiteSpeed. Diese beiden Seiten-Cache-Schichten kommen sich in die Quere, und das Ergebnis sind veraltete Seiten und schwer zu findende Fehler. Den Seiten-Cache überlässt du LiteSpeed, Cloudflare übernimmt statische Dateien und das Netzwerk. Bilder kannst du zusätzlich über ein Bild-CDN mit WebP-Konvertierung ausliefern, was ihre Größe weiter senkt.

Purge: wann und was leeren

Ein Cache ist nur so gut wie sein Auffrischen. Leert er sich nach einer Inhaltsaenderung nicht, sieht der Kunde ein altes Angebot. Leert er sich zu oft, verlierst du den Nutzen des Caches. Die Kunst ist, genau das zu leeren, was sich geändert hat.

1. Preisaenderung eines Produkts: Leere den Cache dieser Produktseite. Den Preis selbst holst du auf der Seite am besten frisch per AJAX, um nicht die ganze Seite zu leeren.
2. Bestandsaenderung: Leere die Produktseite und frische Kategorien nur auf, wenn sich der Lagerstatus ändert (von verfügbar auf nicht verfügbar und umgekehrt).
3. Neuer Beitrag oder Inhaltsbearbeitung: Leere die Seite selbst plus verbundene Seiten (Startseite, Beitragsliste).
4. Globale Änderung (Theme, Menü): Leere den gesamten Cache, denn die Änderung betrifft alle Seiten.

LiteSpeed Cache hat dafür fertige Regeln im WooCommerce-Bereich. Du kannst einstellen, dass es das Produkt bei einer Bestands- oder Mengenaenderung leert und Kategorien nur bei einer Änderung des Lagerstatus auffrischt. Genau diese Präzision unterscheidet einen gut eingestellten Shop von einem, in dem der Cache entweder alte Preise zeigt oder sich so oft leert, dass er nichts bringt.

Wirkung auf die Core Web Vitals

Cache und CDN verbessern vor allem das LCP, also die Zeit, bis der Hauptinhalt der Seite erscheint. Denn sie packen die zwei größten Ursachen für ein langsames LCP an: die langsame Serverantwort und weit entfernte Dateien.

• LCP: Der Seiten-Cache verkürzt die Serverantwort, das CDN beschleunigt das Laden des Hauptbilds. Das ist meist der größte Gewinn.
• CLS: Indirekt, denn schneller geladene Bilder mit festen Groessenangaben verursachen seltener Layout-Spruenge.
• INP: Cache behebt kein schweres JavaScript, aber ein entlasteter Server verarbeitet Aufgaben schneller, die Reaktion auf einen Klick wird also flüssiger.

In der Praxis schafft ein Shop, der ohne Cache eine Seite in zwei oder drei Sekunden aufbaut, mit Seiten-Cache und CDN oft deutlich unter einer Sekunde bis zum ersten Inhalt. Den größten Sprung sieht man auf Handys bei schwachem Empfang, also genau dort, wo Google die Felddaten misst.

Konfiguration Schritt für Schritt und häufige Fehler

Die Reihenfolge, die am meisten bringt und die wenigsten Probleme macht, sieht so aus:

Die häufigsten Fehler, die ich bei Shop-Audits sehe, sind immer dieselben. Erstens ein gecachter Warenkorb oder Konto, weil jemand aggressiven Cache ohne Ausschlüsse aktiviert hat. Zweitens der Seiten-Cache gleichzeitig in Cloudflare und LiteSpeed, was veraltete Seiten erzeugt. Drittens ein fehlender Purge-Sync mit dem CDN, sodass der Kunde einen alten Preis sieht, obwohl im Shop längst ein neuer steht. Viertens ein aktivierter Object Cache ohne laufendes Redis auf dem Hosting, also eine Einstellung, die nichts bewirkt.

Wenn du einen Shop neu aufsetzt oder einen bestehenden beschleunigen willst, mache ich das bei DawidWeb regelmäßig: Konfiguration von LiteSpeed Cache für WooCommerce, Object Cache mit Redis, Anbindung von Cloudflare mit korrektem Purge und Messung der Core Web Vitals vor und nach dem Setup. Webseiten und Shops baue ich ab 600 Euro, mit über 120 umgesetzten Projekten, und ein Angebot für dein konkretes Vorhaben bekommst du innerhalb von 24 Stunden.