Shopware Cache-Rework: Caching für eingeloggte Kunden

Mit Shopware 6.7.6.0 vom 13. Januar 2026 (Shopware Release Notes 6.7.6.0) startet der folgenreichste Umbau der Storefront-Performance seit Jahren: Das Cache-Rework bringt den HTTP-Cache auch dann zum Einsatz, wenn Kundinnen und Kunden eingeloggt sind oder etwas im Warenkorb liegt. Möglich macht das der neue sw-cache-hash, der Login-Status, Steuerstatus, Währung und Kundengruppe zu einem einzigen Kontextschlüssel bündelt. Dieser Beitrag erklärt das Konzept, die verzögerte Invalidierung, die Breaking Changes für eigene Erweiterungen und einen belastbaren Rollout-Plan für Ihren Shopware-Shop.

Warum der Full-Page-Cache bisher beim Login aussetzt

Die klassische Storefront rendert jede Seite serverseitig mit Twig. Davor sitzt der HTTP-Cache als Full-Page-Cache: Er legt die fertige HTML-Antwort ab und liefert sie beim nächsten Aufruf aus, ohne dass PHP, Datenbank und Suchindex erneut arbeiten müssen. Bisher signalisierten zwei Cookies dieser Schicht, dass eine Antwort nicht mehr allgemeingültig ist: sw-states mit den Zuständen logged-in und cart-filled sowie sw-currency für die gewählte Währung. Sobald einer dieser Zustände auftrat, wurde die Anfrage am Full-Page-Cache vorbeigereicht. Beide Mechanismen sind mit dem Cache-Rework als veraltet markiert und verlieren im nächsten Major-Release ihre Wirkung (Shopware Release Notes 6.7.6.0).

Wirtschaftlich ist das ein Problem an genau der falschen Stelle. Ohne Full-Page-Cache laufen ausgerechnet die Seiten ungebremst durch die Applikation, auf denen Menschen mit Kaufabsicht unterwegs sind: die Kategorieseite nach dem Login, die Produktdetailseite mit Kundengruppenpreis, der Katalogaufruf mit gefülltem Warenkorb. Shopware beziffert den Unterschied zwischen ungecachter und gecachter Auslieferung mit 500 Millisekunden gegenüber 50 Millisekunden (Shopware News) - also etwa dem Zehnfachen. Wie stark solche Zehntelsekunden wirken, zeigt die gemeinsame Untersuchung von Deloitte und Google über 37 Marken: Eine Verbesserung der mobilen Seitengeschwindigkeit um 0,1 Sekunden hob die Conversions im Handel um 8,4 % und den durchschnittlichen Bestellwert um 9,2 % (Deloitte).

Der zweite Grund für den Umbau ist die Schlüsselexplosion. Bisher flossen alle zutreffenden Regeln aus dem Rule Builder in die Cache-Berechnung ein. Shopware rechnet vor, dass allein 50 aktive Regeln in Kombination mit Sprache, Währung und Steuerstatus rechnerisch 1.125.899.906.842.624 mögliche Kombinationen ergeben (Shopware News). Ein Cache, der derart viele Varianten vorhalten müsste, erreicht praktisch keine brauchbare Trefferquote mehr - jede Anfrage wäre ein Cache-Miss. Wer viele Preisregeln und Promotions über den Rule Builder pflegt, kennt den Effekt aus dem Monitoring: hohe Last trotz vermeintlich aktivem Cache.

sw-cache-hash: Der Kontext wird zum Cache-Schlüssel

Das Herzstück des Reworks ist ein einziger Wert. Der sw-cache-hash enthält den Hash aller cache-relevanten Informationen einer Sitzung und wird sowohl als Cookie als auch als HTTP-Header gesetzt; zusätzlich nimmt Shopware den Header-Namen in den Vary-Header der Antwort auf (Shopware Developer Documentation). Damit versteht jeder standardkonforme Cache - der Symfony-Cache genauso wie ein vorgelagerter Reverse-Proxy - dass dieselbe URL je nach Kontext unterschiedliche Antworten hat.

• Login-Status: ob eine Kundin oder ein Kunde angemeldet ist
• Steuerstatus: Brutto- oder Nettodarstellung, entscheidend im B2B
• Währung: ersetzt das bisherige sw-currency-Cookie
• Kundengruppe: unterschiedliche Preise und Sichtbarkeiten
• Cache-relevante Regeln: standardmäßig nur Regeln aus dem Produktbereich, während Checkout-nahe Regeln wie Zahlarten oder Promotions bewusst ausgeklammert bleiben (Shopware Developer Documentation)

Entscheidend für die Trefferquote ist eine kleine, oft übersehene Regel: Das Cookie wird erst gesetzt, sobald der Zustand vom Standard abweicht. Der Standard ist definiert als: kein eingeloggter Kunde, Standardwährung, leerer Warenkorb (Shopware Developer Documentation). Anonyme Besucher teilen sich also weiterhin einen gemeinsamen Cache-Eintrag - der mit Abstand größte Trafficanteil in den meisten Shops bleibt damit so günstig wie zuvor. Erst wer sich anmeldet, die Währung wechselt oder etwas in den Warenkorb legt, bekommt einen eigenen Hash und damit eine eigene Cache-Variante.

HTTP/1.1 200 OK
cache-control: public, s-maxage=3600, stale-while-revalidate=60
vary: sw-cache-hash
sw-cache-hash: 9f2c41ab7d3e
set-cookie: sw-cache-hash=9f2c41ab7d3e; path=/; secure; samesite=lax

<!doctype html> ...

Parallel wird der Cache-Schlüssel selbst radikal entschlackt. Im Entwurf zum Rework ist festgehalten, dass er nur noch fünf Kontextwerte enthalten soll: Sales-Channel-ID, Sprach-ID, Währungs-ID, Steuerstatus und Kundengruppen-ID (shopware/shopware GitHub Discussion #3299). Aus Milliarden theoretischer Permutationen wird damit eine überschaubare, planbare Menge an Varianten. Gleichzeitig wandern viele bisherige Object-Caches der Store-API-Schicht in den HTTP-Cache; im Object-Cache verbleiben vor allem Daten, die praktisch jede Anfrage braucht, etwa der Basis-Kontext des Sales Channels (shopware/shopware GitHub Discussion #3299).

Verzögerte Invalidierung: höhere Trefferquote, neue Erwartung an Redaktionsprozesse

Die zweite große Änderung betrifft nicht das Füllen, sondern das Leeren des Caches. Seit Shopware 6.7 ist die verzögerte Invalidierung der Standard: Änderungen führen nicht mehr sofort zum Verwerfen betroffener Einträge, sondern werden gesammelt und in regelmäßigen Intervallen abgearbeitet. Das Standardintervall liegt bei 5 Minuten und lässt sich über die Laufintervall-Einstellung der geplanten Aufgabe shopware.invalidate_cache anpassen (Shopware Developer Documentation). Die frühere Konfigurationsoption für die Verzögerung ist entfallen, weil das Verhalten nun ohnehin aktiv ist.

Der Gewinn ist erheblich. Wer 400 Produkte importiert, löste früher 400 einzelne Invalidierungswellen aus; jede davon riss Kategorieseiten, Listings und Navigationsfragmente aus dem Cache und erzwang teure Neuberechnungen. Gesammelte Invalidierung fasst diese Ereignisse zusammen, entfernt Dubletten und führt sie in einem Durchlauf aus. Das Ergebnis sind deutlich höhere Trefferquoten und eine spürbar ruhigere Systemlast bei Importen - erfahrungsgemäß der Unterschied zwischen einem Shop, der während des nächtlichen Imports einbricht, und einem, der ihn kaum bemerkt (Projekterfahrung). Ergänzend gilt: Listen-Routen werden nicht mit sämtlichen zurückgegebenen Entitäten verschlagwortet, sondern laufen bewusst über eine TTL, weil vollständige Tags zu teuer wären (Shopware Developer Documentation).

• Preispflege: Korrekturen im Katalog sichtbar machen heißt künftig, das Intervall abzuwarten oder gezielt zu leeren
• Kampagnenstart: Aktionsseiten und Startzeiten großzügig planen, statt auf die Sekunde zu takten
• Bestandsanzeige: knappe Lagerbestände über clientseitig nachgeladene Fragmente ausspielen, wenn Minutengenauigkeit gefragt ist
• Rabattaktionen: Ablaufzeiten so wählen, dass ein Intervall Puffer bleibt
• Freigabeprozesse: Vorschau im Admin und Livestand können vorübergehend auseinanderlaufen - das gehört in die Arbeitsanweisung

Technisch hängt die Zuverlässigkeit des Intervalls direkt an den Hintergrundprozessen. Läuft der Scheduled-Task-Worker nicht dauerhaft, bleiben gesammelte Invalidierungen liegen und veraltete Inhalte bleiben länger sichtbar als geplant. Ein sauber überwachter Worker-Betrieb ist damit keine Kür mehr, sondern Voraussetzung für ein korrektes Cache-Verhalten; wie ein solcher Aufbau produktiv aussieht, beschreibt unser Beitrag zum Betrieb von Message Queue und Workern.

Ein Cache, der bei jeder Kleinigkeit vollständig geleert wird, ist kein Cache, sondern eine Warteschlange vor der Datenbank.

XICTRON Entwicklungsteam

Breaking Change: Erweiterungen müssen mit aktivem Cache funktionieren

Für Betreiber ist das der wichtigste Punkt des gesamten Reworks. Bisher konnten sich Plugins und Themes darauf verlassen, dass für eingeloggte Kunden kein Full-Page-Cache greift - kundenspezifische Inhalte durften also bedenkenlos direkt ins Template gerendert werden. Diese Annahme fällt weg. Die Konstanten CacheStateSubscriber::STATE_LOGGED_IN und CacheStateSubscriber::STATE_CART_FILLED sind als veraltet markiert und werden nicht mehr verwendet; Erweiterungen müssen so umgebaut werden, dass sie mit aktivem Cache für eingeloggte Kunden und gefüllten Warenkorb korrekt arbeiten (Shopware Release Notes 6.7.6.0).

Das Fehlerbild ist unangenehm konkret: Rendert eine Erweiterung den Namen der angemeldeten Person, individuelle Merklisten, offene Angebote oder Loyalty-Punkte direkt in die gecachte Seite, landen diese Daten im gemeinsamen Cache-Eintrag der jeweiligen Variante. Der nächste Nutzer mit demselben Hash sieht dann fremde oder veraltete Zustände. Wer eigene Erweiterungen betreibt oder gerade eine Plugin-Migration auf Shopware 6.7 hinter sich hat, sollte diesen Punkt vor der Aktivierung des Flags prüfen - nicht danach.

Statt harter Codeverdrahtung stellt Shopware konfigurierbare Caching-Policies bereit. Sie erlauben Standardwerte je Bereich, Unterscheidung nach Anwendungsfall und Überschreibungen auf Routenebene (Shopware Developer Documentation). Damit lässt sich sehr genau steuern, welche Seite wie lange öffentlich zwischengespeichert wird und welche grundsätzlich privat bleibt.

shopware:
  http_cache:
    policies:
      katalog_lang:
        headers:
          cache_control:
            public: true
            max_age: 600
            s_maxage: 3600
            stale_while_revalidate: 60
      konto_privat:
        headers:
          cache_control:
            private: true
            no_store: true

Gleichzeitig verlieren vertraute Stellschrauben ihre Wirkung: Die Umgebungsvariable SHOPWARE_HTTP_DEFAULT_TTL sowie der Parameter shopware.http.cache.default_ttl sind mit aktivem Rework wirkungslos und für die Entfernung in 6.8.0.0 vorgesehen (Shopware Release Notes 6.7.6.0). Wer diese Werte in seiner Konfiguration pflegt, sollte sie durch Policies ersetzen, statt sich auf ein stilles Weiterlaufen zu verlassen. Für die Fehlersuche lässt sich ab 6.7.7.0 zusätzlich ein Protokoll der Tag-Invalidierungen über tag_invalidation_log_enabled einschalten, das standardmäßig deaktiviert ist (Shopware Developer Documentation).

Test-Checkliste fürs Staging

Die entscheidende Frage vor dem Rollout lautet nicht „Wird der Shop schneller?", sondern „Sieht jeder Nutzer noch das, was er sehen soll?". Diese Prüfung gehört ins Staging mit aktiviertem CACHE_REWORK-Flag, produktionsnahen Daten und einem vorgeschalteten Reverse-Proxy - denn erst dort zeigt sich, ob Varianten sauber getrennt werden. Die folgende Checkliste hat sich in Projekten bewährt und deckt die Stellen ab, an denen Vermischungen typischerweise auftreten (Projekterfahrung).

• Zwei Konten parallel: zwei getrennte Browserprofile, zwei Kunden aus unterschiedlichen Kundengruppen, dieselben URLs in wechselnder Reihenfolge aufrufen
• Gast danach: nach beiden Sitzungen dieselben Seiten im privaten Fenster prüfen - es darf kein Name, kein Merkzettel und kein Sonderpreis auftauchen
• Warenkorb-Zustände: leer, ein Artikel, viele Artikel, Artikel entfernt - Warenkorbzähler und Mini-Cart in jedem Zustand kontrollieren
• Kundengruppenpreise: identisches Produkt in Handels- und Endkundengruppe vergleichen, inklusive Staffelpreisen und durchgestrichenen Vergleichspreisen
• B2B-Nettoansicht: Umschaltung zwischen Netto und Brutto, danach Rückkehr auf zuvor besuchte Seiten
• Währungswechsel: Fremdwährung wählen, Katalog durchklicken, zurückwechseln und Preise erneut prüfen
• Sprachwechsel: dieselbe Seite in allen aktiven Sprachen, besonders bei geteilten Domains
• Regelbasierte Blöcke: Inhalte prüfen, die an Regeln hängen, etwa Versandhinweise oder Aktionsbanner
• Login und Logout: Abmelden, dieselbe Seite erneut laden, danach mit einem anderen Konto anmelden
• Kundenspezifische Sichtbarkeiten: ausgeblendete Kategorien oder gesperrte Produkte je Kundengruppe
• Formulare und Tokens: Kontaktformular, Bewertungsformular und andere Seiten mit CSRF-Schutz absenden
• Redaktionsfluss: Preis im Admin ändern, Zeitpunkt notieren, Sichtbarkeit in der Storefront gegen das Invalidierungsintervall messen

Der Zwei-Konten-Test ist dabei der wirksamste Einzelschritt. Legen Sie zwei Testkunden an, die sich in Kundengruppe und Steuerstatus unterscheiden, und arbeiten Sie eine feste Liste von zwanzig bis dreißig URLs ab: Startseite, drei Kategorien, fünf Produkte, Suchergebnis, Merkzettel, Kontoübersicht. Anschließend dieselbe Liste mit vertauschter Reihenfolge und zum Schluss als Gast. Jede Abweichung, die sich nur durch die Reihenfolge erklären lässt, ist ein Cache-Fehler und kein Zufall. Für Shops mit ausgeprägten Preisstrukturen lohnt sich zusätzlich ein Blick auf die B2B-Anforderungen an Preise und Sichtbarkeiten.

Zusammenspiel mit Reverse-Proxy- und Edge-Ebenen

Ein wesentliches Ziel des Reworks war es, die Reverse-Proxy-Konfiguration zu vereinfachen. Statt mehrerer Shopware-eigener Header und komplexer Sonderlogik genügt künftig der sw-cache-hash als Header und Cookie: Der Proxy nutzt diesen Wert als Bestandteil seines Cache-Schlüssels und kann Einträge derselben URL nach Anwendungszustand unterscheiden (Shopware Developer Documentation). Weil der Wert zusätzlich im Vary-Header angekündigt wird, funktioniert der Mechanismus grundsätzlich mit jedem standardkonformen Cache.

Für global ausgelieferte Shops greift dieselbe Logik eine Ebene höher: Auch Edge-Knoten können Varianten anhand des Hashes trennen, sofern der Header konsequent durchgereicht wird. Wie sich das mit geografisch verteilten Standorten kombinieren lässt, beschreibt unser Beitrag zum Edge-Caching für Shopware. Wichtig bleibt die saubere Abstimmung mit der Serverumgebung: Wer Proxy, Worker und Speicher nicht gemeinsam plant, verschiebt Engpässe nur - deshalb gehört das Thema in die Hosting- und Betriebsplanung.

Cache-Poisoning verhindern: Kontext-Hash serverseitig validieren

Sobald personalisierte Antworten in einem gemeinsamen Cache liegen, wird die Integrität des Kontextschlüssels sicherheitsrelevant. Genau das beschreibt ein öffentlich dokumentierter Befund in Shopwares Tracker: Löscht eine angemeldete Person die Cookies sw-states und sw-cache-hash und ruft anschließend eine cachebare Seite auf, rendert die Anwendung die Seite mit den Sitzungsdaten dieser Person - und legt sie mangels Kennzeichnung als allgemeingültigen Eintrag ab. Ursache war, dass die Schlüsselerzeugung den Cookies der Anfrage vertraute statt den vom Server gesetzten Antwortwerten (shopware/shopware GitHub Issue #12756).

Die Gegenmaßnahme ist konzeptionell einfach und in der Umsetzung entscheidend: Der Server berechnet den Kontext-Hash selbst, vergleicht ihn mit dem mitgelieferten Wert und verwendet für den Cache-Schlüssel die korrigierte, serverseitige Angabe. Client-gelieferte Werte sind ein Hinweis, keine Wahrheit. Für Betreiber heißt das vor allem: aktuellen Patchstand fahren und die Proxy-Ebene so konfigurieren, dass sie diese Annahme nicht unterläuft.

• Patchstand halten: Sicherheitsrelevante Korrekturen am Cache-Schlüssel gehören zu den Updates, die zeitnah eingespielt werden sollten
• Cookies normalisieren: Der Proxy sollte unbekannte oder manipulierte Cookie-Werte verwerfen, statt sie in den Schlüssel zu übernehmen
• Set-Cookie in öffentlichen Antworten prüfen: Antworten, die Sitzungscookies setzen, dürfen nicht als öffentlich zwischengespeichert markiert sein
• Kontounabhängige Marker überwachen: Automatisierte Abrufe, die auf Anrede oder Kundennummer im HTML prüfen, erkennen Vermischungen früh
• Store-API getrennt betrachten: Für Headless-Aufbauten gelten eigene Schutzmaßnahmen, die wir in Store-API absichern beschreiben

Abgrenzung: Object-Cache, CDN und Store-API

In Gesprächen werden vier Caching-Ebenen regelmäßig vermischt. Sie lösen unterschiedliche Probleme und lassen sich nicht gegeneinander austauschen:

Die vierte Ebene ist die Store-API. Sie liefert Daten an entkoppelte Frontends und folgt mit GET-Routen, eigenen Cache-Control-Headern und Stale-While-Revalidate einer eigenen Logik. Wenn Ihr Shop ein Headless-Frontend nutzt, ist der Beitrag zum Caching der Store-API-Schicht der passende Einstieg; für die klassische Twig-Storefront bleibt der hier beschriebene Full-Page-Cache maßgeblich. Wer beides betreibt, plant beide Ebenen getrennt und misst sie getrennt.

Rollout-Plan: Flag im Staging aktivieren und Wirkung belegen

Das Rework lässt sich kontrolliert einführen. Der Feature-Schalter CACHE_REWORK aktiviert ausschließlich die cache-bezogenen Änderungen; alternativ lassen sich PERFORMANCE_TWEAKS für alle performancebezogenen Umstellungen oder v6.8.0.0 für sämtliche kommenden Breaking Changes setzen (Shopware Release Notes 6.7.6.0). Für einen produktiven Shop ist der schmale Schalter die richtige Wahl: Er begrenzt die Änderungsmenge und macht Ursachen bei Abweichungen nachvollziehbar.

1. Bestandsaufnahme: Erweiterungen, Themes und eigene Controller auf personalisierte Ausgaben und eigene Cache-Logik durchsehen
2. Basiswerte messen: Trefferquote, Time to First Byte und Origin-Anfragen über mindestens eine volle Woche erfassen, inklusive Lastspitzen
3. Staging aktivieren:CACHE_REWORK im Staging setzen, Caches leeren, Reverse-Proxy identisch zur Produktion konfigurieren
4. Checkliste abarbeiten: Zwei-Konten-Test, Warenkorb-Zustände, Kundengruppenpreise und B2B-Nettoansicht wie oben beschrieben prüfen
5. Vergleich messen: dieselben Kennzahlen erneut erheben und den Unterschied dokumentieren, statt ihn zu schätzen
6. Kontrolliert ausrollen: Aktivierung in einem ruhigen Zeitfenster, danach engmaschige Beobachtung von Fehlerraten, Bestellabschlüssen und Supportanfragen

Bei den Messgrößen zählen drei Werte. Erstens die Trefferquote des Caches, getrennt nach anonymen und angemeldeten Anfragen - hier zeigt sich der eigentliche Effekt des Reworks. Zweitens die Time to First Byte: Als guter Wert gelten 0,8 Sekunden oder weniger, gemessen am 75. Perzentil der Nutzer (web.dev). Drittens die Anfragen am Origin, also die Last, die tatsächlich noch bis zur Applikation durchdringt. Alle drei Werte gehören in ein dauerhaftes Monitoring von Verfügbarkeit und Performance, damit Regressionen nach künftigen Updates auffallen. Ergänzend lohnt der Blick auf die Core Web Vitals, weil eine schnellere Serverantwort auch auf die wahrgenommene Ladezeit durchschlägt.

Caching für eingeloggte Kunden als Umsatzhebel nutzen

Das Cache-Rework verschiebt die Performance-Diskussion an die Stelle, an der Geld verdient wird. Bisher profitierten vor allem anonyme Besucher vom Full-Page-Cache, während Stammkunden, B2B-Einkäufer und Menschen mit gefülltem Warenkorb die langsamsten Antworten bekamen. Mit dem sw-cache-hash verschwindet dieser Bruch. Der Preis dafür sind eine ehrliche Prüfung der eigenen Erweiterungen, eine angepasste Erwartung an die Sichtbarkeit von Änderungen und ein sauber aufgesetzter Reverse-Proxy.

Als Shopware-Agentur begleiten wir diesen Schritt in klar abgegrenzten Etappen, damit der Shop durchgehend verkaufsfähig bleibt:

1. Tauglichkeitsprüfung: Wir untersuchen Shop, Theme und Erweiterungen daraufhin, ob sie mit aktivem Cache für eingeloggte Kunden korrekt arbeiten, und dokumentieren jeden Fundort nachvollziehbar.
2. Anpassung: Personalisierte Fragmente werden auf nachgeladene Bausteine umgestellt, Cache-Policies je Route gesetzt und veraltete Konfigurationswerte ersetzt.
3. Testlauf: Im Staging fahren wir den Zwei-Konten-Test, prüfen Warenkorb-Zustände, Kundengruppenpreise und die B2B-Nettoansicht und automatisieren die Vergleiche.
4. Kontrollierte Aktivierung: Der Feature-Schalter wird in einem abgestimmten Zeitfenster gesetzt, mit definiertem Rückfallweg und enger Beobachtung.
5. Nachweis: Trefferquote, Time to First Byte und Origin-Last werden vorher und nachher gemessen, sodass die Wirkung mit Zahlen belegt ist statt mit Behauptungen.

Wenn Sie wissen möchten, wie Ihr Shop im Cache-Rework dasteht, beginnen wir üblicherweise mit einer kompakten Bestandsaufnahme von Erweiterungen und Messwerten. Sprechen Sie uns über das Kontaktformular an - wir ordnen Ihren aktuellen Stand ein und benennen die Schritte, die in Ihrem Fall den größten Unterschied machen.