CDN für WooCommerce richtig einrichten

Ein WooCommerce-Shop läuft problemlos hinter einem CDN, wenn der Edge statische Dateien und die Katalogseiten für Gäste ausliefert und alles Persönliche direkt an deinen Server durchreicht: Warenkorb, Kasse, Kundenkonto, Besucher mit gefülltem Warenkorb, AJAX- und API-Aufrufe sowie die Rückmeldungen der Zahlungsanbieter. Die eigentliche Arbeit steckt darin, diese Ausnahmen sauber zu setzen, Preise per gezieltem Cache-Leeren aktuell zu halten und vor dem Start eine echte Bestellung durchzuspielen. Um Caching-Plugins, Datenbank und Hintergrundprozesse geht es im Ratgeber WooCommerce schneller machen.

Zwei Wege, ein CDN einzubinden

• Asset-CDN. Ein Plugin schreibt die URLs von Bildern, CSS und JavaScript auf einen CDN-Hostnamen um. Die Seiten selbst kommen weiterhin bei jedem Aufruf von deinem Server. Das Risiko ist gering, denn keine Seite wird zwischen Kunden geteilt. Das Erzeugen des HTML, also den langsamsten Schritt, beschleunigt diese Variante aber nicht.
• Full-Site-Proxy. Hier läuft jede Anfrage über den Edge, auch das HTML. Eine gecachte Produktseite erreicht also weder PHP noch die Datenbank. Genau hier liegt der größere Gewinn, und genau hier braucht WooCommerce Sorgfalt. Der Edge ist nämlich ein gemeinsamer Cache: Eine falsche Regel reicht, und Kundin B sieht den Warenkorb von Kunde A.

Dieser Ratgeber behandelt die zweite Variante. Vergleichst du noch Anbieter, hilft dir der Ratgeber CDN für WordPress bei der Auswahl.

Was der Edge cachen darf

Entscheidend ist der Zusatz „nur für Gäste“. Dieselbe Produkt-URL sieht für eingeloggte Kunden oder Besucher mit vollem Warenkorb womöglich anders aus. Der Edge muss diese Anfragen also auseinanderhalten können.

URL-Parameter

Tracking-Parameter wie utm_source erzeugen für jede Variante einen eigenen Cache-Eintrag. So sinkt die Trefferquote während einer Kampagne, ohne dass du es merkst. Parameter, die den Inhalt verändern, etwa orderby oder Filter der Kategorieseiten, brauchen dagegen zu Recht eigene Einträge.

Was immer beim Server ankommen muss

Seiten

In der Anleitung zum Konfigurieren von Cache-Plugins (auf Englisch) nennt WooCommerce Warenkorb, Kasse und Mein Konto als Seiten, die nicht in den Cache gehören. Das gilt auch für alles darunter, etwa die Bestellbestätigung nach der Zahlung oder die Bestell- und Adressseiten im Kundenkonto. Bei einem deutschen Shop heißen die Pfade meist /warenkorb/, /kasse/ und /mein-konto/. Hast du sie umbenannt oder betreibst einen mehrsprachigen Shop, zählt jeder Slug und jede Sprachversion.

WooCommerce nimmt dir dabei etwas Arbeit ab: Auf Warenkorb, Kasse und Kundenkonto sendet es Cache-Control-Header, die das Cachen untersagen. Ein CDN, das die Header deines Servers respektiert, speichert diese Seiten also nicht. Prüf aber, ob ein Cache- oder Sicherheits-Plugin diese Header überschreibt.

Cookies

Die Header greifen nur auf diesen drei Seiten. Ruft jemand mit gefülltem Warenkorb eine Produktseite auf, kommt sie mit ganz normalen, cachebaren Headern, zeigt aber vielleicht seinen Mini-Warenkorb. Deshalb muss der Bypass auch an Cookies hängen. WooCommerce nennt diese:

• woocommerce_cart_hash und woocommerce_items_in_cart (gesetzt, sobald etwas im Warenkorb liegt)
• wp_woocommerce_session_* (die Kundensession)
• woocommerce_recently_viewed und store_notice[notice id] (nur relevant, wenn du das Widget für zuletzt angesehene Produkte oder den Shop-Hinweis nutzt)

Dazu kommt das WordPress-Login-Cookie wordpress_logged_in_*, damit eingeloggte Kunden und dein Team immer frische Seiten bekommen.

Endpunkte

• Anfragen mit ?wc-ajax=, etwa beim Hinzufügen zum Warenkorb, beim Einlösen von Gutscheinen und beim Aktualisieren der Kasse
• /wp-admin/, admin-ajax.php und wp-login.php
• Links mit ?add-to-cart=
• Die Store API unter /wp-json/wc/store/v1/. Auf ihr bauen die Blöcke für Warenkorb und Kasse auf, und ihre Antworten hängen von der Session des jeweiligen Kunden ab.
• Die authentifizierte REST API unter /wp-json/wc/v3/, über die Warenwirtschaft, Lagerverwaltung und Marktplätze angebunden sind
• Rückmeldungen der Zahlungsanbieter (dazu gleich mehr)

Der Mini-Warenkorb auf gecachten Seiten

Bei klassischen Themes füllt das Cart-Fragments-Skript die Anzahl im Mini-Warenkorb erst nach dem Laden der Seite. Es ruft dafür ?wc-ajax=get_refreshed_fragments auf und legt das Ergebnis im Session Storage des Browsers ab. Bei Block-Themes kommen die Warenkorbdaten über eigene Anfragen, die genauso ungecacht bleiben müssen. Die Seite darf also gerade deshalb in den Cache, weil der persönliche Teil über eine eigene, ungecachte Anfrage nachkommt. Landet diese Anfrage doch im Cache, sieht jeder Besucher dieselbe Anzahl. Ob du Cart Fragments überhaupt brauchst, klärt der Ratgeber WooCommerce schneller machen.

Preise, Währungen und Länder

Ein gemeinsamer Cache funktioniert nur, wenn alles, was eine Seite verändert, in der URL steckt oder einen Bypass auslöst. Ein Cache, der Seiten nach ihrer URL ablegt, sieht nämlich weder Cookies noch IP-Adressen.

• Geolokalisierung. Steht der Standard-Kundenstandort auf der normalen Geolokalisierung, berechnet der Server die Preise passend zum Land des Besuchers. Hinter einem gemeinsamen Cache bestimmt dann der erste Besucher, was alle anderen sehen. Für diesen Fall beschreibt WooCommerce in den allgemeinen Einstellungen (auf Englisch) eine Variante mit Unterstützung für Seiten-Caching, die den Standort per AJAX ermittelt und einen Parameter ?v= an die URLs hängt. Jede Variante bekommt so einen eigenen Cache-Eintrag, rechne also mit einer niedrigeren Trefferquote.
• Währungsumschalter. Viele speichern die gewählte Währung in einem Cookie. Löst dieses Cookie keinen Bypass aus, zeigt die gecachte Seite die Währung, in der sie zuerst erzeugt wurde. Besser ist ein Umschalter, der die Währung in die URL schreibt oder die Preise im Browser nachlädt. Prüf außerdem, was seine Doku zum Caching sagt.
• Kundenspezifische Preise. Händler- oder Rollenpreise sehen in der Regel nur eingeloggte Kunden, und die umgehen den Cache ohnehin. Stell sicher, dass die Preisanzeige wirklich am Login hängt und nicht an einem eigenen Cookie.

Bestand und Preise aktuell halten

Wie lange HTML im Cache bleiben darf, hängt davon ab, was dich eine veraltete Seite kostet. Eine Inhaltsseite darf ruhig stundenlang im Cache liegen. Bei Produkten mit schnell wechselndem Bestand wählst du eine kürzere Laufzeit oder leerst den Cache bei jeder Änderung.

• Einzelnes Produkt bearbeitet. Leere den Cache für die Produkt-URL, die Kategorieseiten, auf denen es erscheint, die Shopseite und die Startseite, falls das Produkt dort hervorgehoben ist.
• Importe und Warenwirtschaft. Lass den Import-Job über die API deines CDN genau die URLs leeren, die er geändert hat, statt zu warten, bis die Seiten ablaufen.
• Geplante Angebote. Ein Sonderpreis, der um Mitternacht startet, landet nicht von selbst auf einer gecachten Seite. Plane für diesen Zeitpunkt ein gezieltes Leeren ein.
• Änderungen am ganzen Shop. Nach einem Theme-Update oder einer shopweiten Aktion leerst du alles und wärmst danach Hauptkategorien und Bestseller vor.

Ob das Leeren automatisch passiert, hängt von deinem Setup ab. Prüf nach Änderungen in jedem Fall stichprobenartig die Response-Header.

Zahlungsanbieter und Firewall

Zahlungsanbieter bestätigen Zahlungen, indem ihre Server deinen Shop direkt aufrufen. Die Payment Gateway API (auf Englisch) von WooCommerce nutzt dafür wc-api-URLs in der Form /wc-api/<callback>/ oder /?wc-api=<callback>. Viele Zahlungs-Plugins registrieren zusätzlich eigene Webhook-Routen unter /wp-json/. Scheitert so ein Aufruf, bleibt die Bestellung auf „Zahlung ausstehend“, obwohl der Kunde längst bezahlt hat.

Diese Anfragen dürfen nie im Cache landen, und genauso wenig darf eine Regel sie blockieren.

• Länderregeln. Die Server eines Anbieters rufen womöglich aus einem Land an, das du blockierst oder mit einer Abfrage belegst.
• CAPTCHA-Abfragen. Ein Server löst kein CAPTCHA. Beschränke solche Regeln auf Pfade, die Menschen aufrufen.
• Rate Limits. Webhooks kommen oft gebündelt, zum Beispiel nach mehreren Erstattungen. Leg die Grenzen pro IP entsprechend großzügig an.
• Bot-Regeln. Zahlungsanbieter und Warenwirtschaft sind automatisierte Clients. Prüf, dass Bot-Regelsätze sie nicht erfassen.

Testplan für den Umstieg

Spiel die Tests nach Möglichkeit erst auf einer Staging-Kopie durch und direkt nach dem Wechsel der Nameserver noch einmal im Live-Shop (siehe Nameserver ändern ohne Ausfall).

1. Produktseite als Gast. Ruf sie zweimal auf. Die zweite Antwort sollte ein Cache-Treffer sein.
2. Warenkorb und Kasse. Als Gast zeigen sie BYPASS oder MISS, niemals HIT.
3. Gefüllter Warenkorb. Leg ein Produkt in den Warenkorb und lade eine Produktseite neu. Das darf kein HIT sein, und der Mini-Warenkorb muss deinen Artikel zeigen.
4. Zwei Browser. Füll den Warenkorb in Browser A. Browser B muss weiterhin einen leeren Warenkorb sehen.
5. Eingeloggter Kunde. Klick dich durch Shop und Kundenkonto. Nichts davon darf aus dem gemeinsamen Cache kommen.
6. Testzahlung. Schließ eine Bestellung im Sandbox- oder Testmodus des Zahlungsanbieters ab und prüf, ob der Status „Zahlung ausstehend“ verlässt. Dann ist die Rückmeldung angekommen.
7. Cache leeren. Ändere einen Preis, leere die URL und kontrolliere, ob der neue Preis erscheint.

Für die Header-Prüfung schickst du die Anfrage einmal ohne und einmal mit Warenkorb-Cookie:

curl -sI https://shop.example.com/produkt/beispiel/ | grep -i -E "cache|age"
curl -sI -H "Cookie: woocommerce_items_in_cart=1" https://shop.example.com/produkt/beispiel/ | grep -i cache

Die zweite Anfrage darf kein HIT sein. Laufen alle Funktionstests sauber, vergleichst du die Ladezeit vorher und nachher, zum Beispiel mit corewebvitals.page. Das Tool zeigt echte Nutzerdaten und einen Labortest für Mobil und Desktop.

So hilft dir fast.site

fast.site arbeitet als Full-Site-Proxy vor deinem bestehenden WooCommerce-Hosting. Du behältst deinen Hoster, legst die Domain im Dashboard an und stellst die Nameserver auf fast.site um. Danach verwaltet fast.site dein DNS. Alle bisherigen Einträge müssen deshalb in der DNS-Zone bei fast.site stehen, auch die MX-Einträge für die E-Mails deines Shops.

Der Fast Edge Cache™ liefert Produkt-, Kategorie- und Inhaltsseiten für Gäste direkt vom Edge aus, in den Regionen, die dein Tarif umfasst. Ein Cache-HIT erreicht deinen Server gar nicht erst. fast.site respektiert die Cache-Control-Header deines Servers, und private oder dynamische Antworten wie Warenkorb, Kasse und eingeloggte Sessions zeigen fs-cache: BYPASS. So kannst du jeden Schritt des Testplans selbst nachprüfen (siehe Cache prüfen). Nach Importen oder Preisänderungen leerst du einzelne URLs oder die ganze Domain im Dashboard, inklusive Protokoll, oder per API aus deinen eigenen Skripten.

Außerdem wandelt fast.site Produktbilder für passende Browser direkt in WebP um (AVIF je nach Tarif) und fängt HTTP-Floods und schädliche Bots schon am Edge ab, mit Firewall-Regeln, die du selbst steuerst. Mehr dazu findest du auf der WooCommerce-Seite.

Miss deinen Shop vorher und nachher auf deinen eigenen Seiten, eine komplette Testbestellung eingeschlossen. Starten kannst du mit einer kostenlosen 7-Tage-Testphase.

Häufige Fragen

Braucht ein WooCommerce-Shop ein CDN?

Nicht jeder. Sitzen die meisten Kunden in der Nähe deines Servers und laden die Seiten schon flott, reichen oft besseres Hosting oder ein Asset-CDN. Ein Full-Site-CDN lohnt sich vor allem bei Besuchern aus mehreren Regionen, Traffic-Spitzen durch Kampagnen oder einem Server, der in Stoßzeiten an seine Grenzen kommt.

Kann ein CDN WooCommerce-Produktseiten cachen?

Ja, für Gäste. Produkt-, Kategorie- und Shopseiten dürfen in den Cache, solange Anfragen mit WooCommerce-Warenkorb- oder Session-Cookies und eingeloggte Nutzer ihn umgehen. Ändern sich Preis oder Bestand, leerst du die betroffenen Produkt-URLs.

Macht ein CDN die Kasse in WooCommerce kaputt?

Nicht, wenn Warenkorb, Kasse, Kundenkonto, wc-ajax-Anfragen, die Store API und die Rückmeldungen der Zahlungsanbieter am Cache vorbeigehen und keine Firewall-Regel sie blockiert. Teste nach jeder Änderung an der Konfiguration eine komplette Bestellung mit Testzahlung.

Brauche ich mit CDN noch ein Caching-Plugin?

Oft ja. Ein Plugin für Seiten-Caching beschleunigt alle Anfragen, die trotzdem bei deinem Server ankommen, etwa bei einem MISS. Achte darauf, dass Plugin und CDN dieselben Ausnahmen kennen, und leere nach Änderungen beide.