Shopware 6 mit CDN: Was in den Cache darf und was nicht

Ein CDN vor Shopware 6 bringt an zwei Stellen etwas: bei statischen Dateien wie Theme-CSS, JavaScript und Produktbildern, die lange am Edge liegen dürfen, und bei HTML-Seiten für Gäste im Standardzustand, die nur kurz gecacht werden sollten und einen Plan zum Leeren brauchen. Alles Persönliche dagegen, also Warenkorb, Checkout, Kundenkonto, eingeloggte Kunden und Gäste mit gewechselter Währung, muss direkt an deinen Shopware-Server gehen. Hier erfährst du, wo genau die Grenze verläuft, wie du den Cache gezielt leerst und wie du alles prüfst.

Wie du den Shop selbst beschleunigst (HTTP-Cache, Worker, OPcache, Importe), steht im Ratgeber Shopware 6 Performance optimieren. In diesem Artikel geht es um die Schicht davor.

Asset-CDN oder ganze Domain übers CDN

Asset-CDN. Shopware kann die URLs öffentlicher Dateien auf einem eigenen Hostnamen erzeugen. Dazu setzt du in der Filesystem-Konfiguration (auf Englisch) eine url für das Dateisystem public. Die Dateisysteme für Theme, Assets und Sitemap übernehmen diese Einstellung, solange du sie nicht eigens konfigurierst. Damit ändern sich nur die URLs in der Seite. Die Dateien holt sich das CDN weiterhin von deinem Server oder Bucket, und jede HTML-Anfrage landet nach wie vor bei Shopware.

Die ganze Domain über das CDN. Je nach Anbieter richtest du das über die Nameserver oder per DNS ein. Dann sieht der Edge jede Anfrage, auch das HTML, und kann schädlichen Traffic abfangen, bevor er deinen Server erreicht. Der Gewinn ist größer, die Verantwortung aber auch, denn jetzt muss das CDN genau wissen, welche Antworten es speichern darf.

Statische Dateien sind der einfache Teil

Kompilierte Theme-Dateien dürfen lange am Edge bleiben. Bei jedem Kompilieren schreibt Shopware CSS und JavaScript in einen neuen Ordner unter theme/, dessen Name ein frisch erzeugter Hash ist. Die URLs ändern sich also mit jedem Build. Produktbilder und Thumbnails ändern sich selten und machen oft den größten Teil der Datenmenge einer Seite aus. Wie du Bilder richtig aufbereitest, zeigt der Ratgeber Bilder für die Website optimieren.

Vorsicht nur bei Dateien, die unter derselben URL ausgetauscht werden, etwa ein CMS-Bild mit unverändertem Dateinamen. Diese URL leerst du nach dem Austausch gezielt.

Welche Shopware-Seiten in den Edge-Cache dürfen

Shopware cacht eine Seite nicht einfach einmal für alle. Laut der Dokumentation zum HTTP-Cache setzt Shopware das Cookie sw-cache-hash, sobald der Zustand eines Besuchers vom Standard abweicht. Standard heißt: kein eingeloggter Kunde, Standardwährung, leerer Warenkorb. Der Hash enthält Login-Status, Währung, Steuerzustand und die greifenden cache-relevanten Regeln, und Shopware legt für jeden Hash eine eigene Cache-Variante an. Alle Besucher im Standardzustand teilen sich eine Variante.

Ein CDN, das nur nach der URL cacht, weiß von diesen Varianten nichts. Für HTML gilt deshalb: Am Edge landet nur, was ein Gast im Standardzustand sieht, und jede Anfrage mit sw-cache-hash geht an Shopware.

Auch Kundengruppenpreise und andere regelbasierte Inhalte fließen in den Hash ein. Solche Besucher dürfen die gecachte Standardseite also nie zu sehen bekommen.

Cache-Control und Cookies beachten

Was cachebar ist, sollte der Edge nicht selbst raten, denn Shopware sagt es ihm. Ist der HTTP-Cache aktiv, tragen cachebare Storefront-Antworten eine Lebensdauer für gemeinsame Caches (s-maxage). Die Doku zum Reverse Proxy nennt als Beispiel Cache-Control: public, s-maxage=7200. Antworten für eingeloggte Kunden oder mit gefülltem Warenkorb bekommen diese Header nicht.

Egal, welches CDN du nutzt, zwei Regeln gelten immer:

1. Speichere nur, was Shopware als öffentlich markiert. Antworten mit private, no-cache oder no-store gehören nie in den Cache, ebenso wenig Antworten, die ein Cookie setzen. Eine pauschale Regel nach dem Motto „alles cachen“ hebelt Shopware aus, und genau so sieht plötzlich ein Kunde den Warenkorb eines anderen.
2. Reiche Anfragen mit sw-cache-hash am Cache vorbei, oder nimm das Cookie in den Cache-Schlüssel auf. Ignoriert das CDN es, bekommt ein Gast mit gewechselter Währung womöglich die Seite in Standardwährung. Schlimmer noch: Seine Variante könnte gespeichert und an alle anderen ausgeliefert werden.

Willst du die Lebensdauer ändern, stell sie in Shopware ein und nicht am Edge. Neuere Versionen bieten dafür HTTP-Caching-Policies mit Direktiven wie s_maxage und stale_while_revalidate je Bereich oder Route. Die Doku führt das noch als experimentell, ab Shopware 6.8 soll es Standard werden. Prüf also, was deine Version kann.

Varnish, Fastly und ein allgemeines CDN

Offiziell unterstützt Shopware zwei Reverse Proxies: Varnish mit dem XKey-Modul und Fastly. Beide hängen an der Invalidierung von Shopware. Gecachte Antworten tragen Tags (Surrogate Keys) für die Daten, aus denen sie entstanden sind, und änderst du ein Produkt, schickt Shopware dem Proxy eine Invalidierung für genau diese Tags. Seit Shopware 6.6 richtest du das unter shopware.http_cache.reverse_proxy ein. Alle Details stehen in der Doku zum Reverse HTTP Cache.

Ein allgemeines CDN ist in diesen Kreislauf nicht eingebunden. Die Tag-Invalidierung erreicht den eigenen Cache von Shopware und einen konfigurierten Reverse Proxy, aber kein Edge-Netz, von dem Shopware nichts weiß. Eine Kategorieseite bleibt am Edge also liegen, bis ihre Lebensdauer abläuft oder du sie leerst.

Ein Proxy mit Tags invalidiert punktgenau und passt gut zu großen Katalogen mit vielen Änderungen, ist aber ein weiteres System, das du betreiben musst. Ein allgemeines CDN für die ganze Domain ist schneller eingerichtet und bringt Auslieferung am Edge und Schutz mit. Wie aktuell das HTML ist, hängt dann aber von kurzen Lebensdauern und deinen eigenen Purges ab. Manche Shops kombinieren beides.

Cache leeren ohne Tags

Kurze Lebensdauer für HTML. Lass Gastseiten nur Minuten statt Stunden am Edge liegen, Theme-Dateien und Bilder dagegen deutlich länger. Eine veraltete Kopie verschwindet dann spätestens nach einer Lebensdauer, auch ohne Purge. Die zusätzlichen Cache-Misses fängt der eingebaute Shopware-Cache ab.

URLs nach größeren Änderungen leeren. Startet ein Sale, ändern sich Preise in einer ganzen Kategorie oder baust du die Navigation um, leerst du die betroffenen URLs. Bei Änderungen, die auf jeder Seite stecken, etwa Hauptmenü, Footer oder ein neu kompiliertes Theme, lohnt sich ein Purge der ganzen Domain, am besten außerhalb der Stoßzeiten.

Purges aus deinen eigenen Skripten. Die meisten CDNs, auch fast.site, bieten eine Purge-API. Lass deinen ERP- oder Preisimport mit einem Aufruf enden, der die berührten URLs leert, und lass deine Deployment-Pipeline nach theme:compile leeren.

Echte Besucher-IPs und Trusted Proxies

Hinter einem CDN kommt jede Anfrage von einem Edge-Server bei Shopware an. Die echte IP des Besuchers steckt in einem Header wie X-Forwarded-For, und Symfony liest ihn nur von Proxies, denen du vertraust. Die trägst du seit Shopware 6.6 in der .env unter SYMFONY_TRUSTED_PROXIES ein. Schaltest du CDN und Varnish hintereinander, müssen beide Stationen vertrauenswürdig sein.

Das betrifft nicht nur deine Logs. Zahlungs- und Betrugsprüfungs-Plugins werten oft die IP aus, und die Rate Limiter von Shopware für Login, Passwort-Reset und Kontaktformular arbeiten ungenauer, wenn scheinbar alle Anfragen von wenigen Adressen kommen.

So prüfst du dein Setup

1. Zwei Anfragen als Gast. Die zweite sollte vom Edge kommen:

curl -sI https://shop.example.com/kategorie/ | grep -iE 'cache-control|fs-cache|age|set-cookie'
curl -sI https://shop.example.com/kategorie/ | grep -iE 'cache-control|fs-cache|age|set-cookie'

Bei fast.site achtest du auf fs-cache: HIT und ein steigendes fs-cache-age (mehr dazu unter Cache prüfen). Andere CDNs senden meist einen Age-Header und einen eigenen Status-Header. Wird die Seite nie zum HIT, vergleich ihren Cache-Control-Header mit den Regeln oben.

2. Persönliche Routen. Prüf /checkout/cart und /account/login genauso. Dort darf nie ein HIT auftauchen.

3. Eine komplette Bestellung. Leg im privaten Fenster ein Produkt in den Warenkorb, achte darauf, dass sich der Zähler im Header aktualisiert, und schließ den Checkout mit einer Test-Zahlart ab. Die Testbestellung stornierst du danach.

4. Eingeloggter Kunde. Melde dich mit einem Testkonto an, am besten mit Kundengruppenpreisen. Die Seiten müssen die Preise dieses Kunden zeigen, und nach dem Logout muss wieder die Gastansicht erscheinen.

5. Währungswechsel. Wechsle als Gast in eine zweite Währung und klick dich durch ein paar Kategorien. Öffne dieselben Seiten dann in einem neuen privaten Fenster: Dort muss die Standardwährung stehen. Mach das Ganze auch in umgekehrter Reihenfolge. So erwischst du ein CDN, das sw-cache-hash ignoriert.

Hast du mehrere Verkaufskanäle oder Sprachen, wiederholst du Schritt 1 und 5 für jede Domain. Für die Ladezeit vergleichst du echte Nutzerdaten und einen Labortest auf corewebvitals.page vorher und nachher, so wie im Ratgeber Ladezeit einer Website richtig messen beschrieben.

So hilft dir fast.site

fast.site ist eine Edge-Schicht für die ganze Domain und sitzt vor deinem bestehenden Shopware-Hosting. Dein Hoster bleibt. Du fügst die Domain im Dashboard hinzu und stellst ihre Nameserver auf fast.site um. Wie das ohne Verlust von DNS-Einträgen und E-Mails klappt, zeigt die Checkliste Nameserver ändern.

Der Fast Edge Cache™ beachtet die Cache-Control-Header deines Shops. Private und dynamische Antworten wie Warenkorb, Checkout und eingeloggte Sitzungen zeigen fs-cache: BYPASS, die Tests oben kannst du also direkt durchspielen. Die Tag-Invalidierung von Shopware erreicht fast.site nicht. Stattdessen leerst du einzelne URLs oder die ganze Domain im Dashboard, mit Purge-Protokoll, oder per API aus deinen Import- und Deployment-Skripten. Ein Cache Warmer hält wichtige Seiten vorgewärmt.

Bilder werden für unterstützende Browser direkt in WebP umgewandelt (AVIF je nach Tarif), Textdateien per Brotli komprimiert, und Layer-7-DDoS-Erkennung, Rate Limits und Bot-Regelsätze filtern den Traffic am Edge. Mehr dazu findest du auf der Shopware-Seite.

Miss das Ergebnis in deinem eigenen Shop, mit denselben Seiten vorher und nachher. Starte dafür eine kostenlose 7-Tage-Testphase ohne Kreditkarte.

Häufige Fragen

Hat Shopware 6 ein eingebautes CDN?

Nein. Shopware bringt einen HTTP-Cache mit, der auf deinem Server läuft, und du kannst für öffentliche Dateien eine eigene URL hinterlegen, damit sie von einem CDN-Hostnamen laden. Als Reverse Proxies sind Varnish mit XKey und Fastly offiziell angebunden.

Kann ich HTML-Seiten von Shopware im CDN cachen?

Ja, für Gäste im Standardzustand: nicht eingeloggt, Standardwährung, leerer Warenkorb. Das CDN muss die Cache-Control-Header von Shopware beachten, Anfragen mit dem Cookie sw-cache-hash durchreichen und Warenkorb, Checkout und Kundenkonto nie cachen.

Warum stimmen Warenkorb oder Preise nach dem Umstieg aufs CDN nicht?

Meist cacht der Edge etwas Persönliches: eine Antwort, die ein Cookie setzt, eine Seite mit sw-cache-hash oder eine Checkout-Route, die eine Regel „alles cachen“ erwischt hat. Entferne die Regel, leere die Domain und wiederhole die Tests.

Brauche ich den HTTP-Cache von Shopware hinter einem CDN noch?

Ja. Jeder Cache-Miss am Edge und jede Anfrage mit sw-cache-hash landet auf deinem Server. Der eingebaute Cache hält diese Anfragen schnell, und kurze Lebensdauern am Edge funktionieren nur mit einem flotten Ursprungsserver gut.

Wie leere ich den CDN-Cache nach Änderungen in Shopware?

bin/console cache:clear und cache:clear:http erreichen kein allgemeines CDN. Leere die betroffenen URLs oder die ganze Domain im Dashboard des CDN, oder per API aus dem Skript, das die Änderung ausgelöst hat.