CDN und Cache: Setup fuer schnelle Shops

Seiten-Cache baut fertiges HTML auf dem Server, das CDN verteilt Dateien naeher zum Nutzer
Seiten cachst du fuer 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 haengt 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 haelt. Ein Kunde aus Muenchen laedt das Bild von einem Server in der Naehe und nicht vom anderen Ende Europas.
• Object Cache: Eine dritte Schicht, die Ergebnisse von Datenbankabfragen im Speicher haelt. Dazu gleich mehr, denn im Shop spielt sie eine grosse Rolle.

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

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 oeffentliche Seiten, die fuer alle gleich aussehen, und private Seiten, die die Daten einer konkreten Person zeigen.

Oeffentliche Seiten cachst du bedenkenlos fuer nicht eingeloggte Besucher: Startseite, Kategorien, Produktseiten, Blogbeitraege, Kontaktseite. Sie bringen den meisten Traffic und profitieren am staerksten vom Cache.

Private Seiten muessen 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, saehe der Kunde fremde Daten, und das waere ein Desaster.

ESI: eine Seite mit dynamischem Warenkorb cachen

Hier entsteht ein natuerliches Problem. Eine Produktseite ist groesstenteils statisch, aber im Header steckt ein Mini-Warenkorb, der die Anzahl der Produkte und den Betrag fuer eine konkrete Person zeigt. Wie cachst du die Seite, wenn ein Teil davon immer anders ist?

Die Loesung heisst ESI (Edge Side Includes). Dabei cachst du den statischen Teil der Seite, waehrend kleine dynamische Fragmente (Mini-Warenkorb, Begruessung des eingeloggten Kunden) live ausgeliefert werden. LiteSpeed Cache hat dafuer einen eigenen WooCommerce-Bereich. So laedt 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 veraenderlichem 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, Bestaende, Attribute, Varianten, Optionen. Bei wenig Traffic schafft die Datenbank das problemlos. Bei grossem Katalog und Traffic aus Werbung wird sie zum Engpass.

Object Cache speichert die Ergebnisse dieser Abfragen ueber 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 Einbrueche 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.
• Grosser Katalog, viele eingeloggte Kunden, Traffic aus Werbung: Hier hilft Object Cache spuerbar, 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 laedt sie von einem Server in seiner Naehe statt von deinem Hosting, was die Ladezeit verkuerzt, besonders bei vielen Produktfotos.

Cloudflare verbindest du mit LiteSpeed Cache ueber 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 uebersehen: 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 ueberlaesst du LiteSpeed, Cloudflare uebernimmt statische Dateien und das Netzwerk. Bilder kannst du zusaetzlich ueber ein Bild-CDN mit WebP-Konvertierung ausliefern, was ihre Groesse 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 geaendert 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 aendert (von verfuegbar auf nicht verfuegbar und umgekehrt).
3. Neuer Beitrag oder Inhaltsbearbeitung: Leere die Seite selbst plus verbundene Seiten (Startseite, Beitragsliste).
4. Globale Aenderung (Theme, Menue): Leere den gesamten Cache, denn die Aenderung betrifft alle Seiten.

LiteSpeed Cache hat dafuer fertige Regeln im WooCommerce-Bereich. Du kannst einstellen, dass es das Produkt bei einer Bestands- oder Mengenaenderung leert und Kategorien nur bei einer Aenderung des Lagerstatus auffrischt. Genau diese Praezision 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 groessten Ursachen fuer ein langsames LCP an: die langsame Serverantwort und weit entfernte Dateien.

• LCP: Der Seiten-Cache verkuerzt die Serverantwort, das CDN beschleunigt das Laden des Hauptbilds. Das ist meist der groesste 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 fluessiger.

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 groessten Sprung sieht man auf Handys bei schwachem Empfang, also genau dort, wo Google die Felddaten misst.

Konfiguration Schritt fuer Schritt und haeufige Fehler

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

Die haeufigsten Fehler, die ich bei Shop-Audits sehe, sind immer dieselben. Erstens ein gecachter Warenkorb oder Konto, weil jemand aggressiven Cache ohne Ausschluesse 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 laengst 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 regelmaessig: Konfiguration von LiteSpeed Cache fuer 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 ueber 120 umgesetzten Projekten, und ein Angebot fuer dein konkretes Vorhaben bekommst du innerhalb von 24 Stunden.