Shopware Caching: HTTP-Cache, Redis und Varnish

Shopware-Shops können blitzschnell laden. Ob sie es tun, hängt fast immer am Caching. Wer nur die Standard-Einstellungen nutzt, lässt erhebliches Potenzial liegen. Dieser Artikel erklärt, wie das Caching in Shopware 6 aufgebaut ist, was Redis und Varnish konkret leisten und welche Kombination für welche Shopgröße sinnvoll ist.

Warum Caching in Shopware so wichtig ist

Shopware-Seiten bestehen aus vielen Teilen: Produktdaten, Preise, Lagerbestände, Kundengruppen, Regeln aus dem Rule Builder. Jede dieser Informationen kommt aus der Datenbank oder wird berechnet. Ohne Cache landet bei jedem Seitenaufruf eine vollständige Datenbanklast auf dem Server. Das ist bei einem kleinen Testshop kein Problem. Bei echtem Traffic ist es das größte Performance-Risiko überhaupt.

Gut eingestelltes Caching kann die Time-to-First-Byte auf unter 100 ms drücken. Schlecht konfiguriertes Caching liefert veraltete Preise, bricht Warenkörbe oder verursacht Fehler bei Benutzeranmeldungen. Beides ist vermeidbar, wenn man versteht, was wie gecacht wird.

Die Cache-Schichten in Shopware 6

Shopware arbeitet mit mehreren unabhängigen Cache-Ebenen. Sie sind nicht austauschbar, sondern ergänzen sich.

HTTP-Cache (Full-Page-Cache): Die wichtigste Stufe. Shopware speichert die komplett gerenderte HTML-Antwort einer Seite. Beim nächsten Aufruf wird das gespeicherte HTML direkt ausgeliefert, Symfony und PHP werden dabei komplett übersprungen. Standardmäßig landet dieser Cache auf dem Dateisystem. Bei höherem Traffic ist das zu langsam.

Object-Cache / Symfony-Cache: Hier werden interne Berechnungen zwischengespeichert, unter anderem der Sales-Channel-Kontext, Übersetzungen, Theme-Kompilierungen und Konfigurationsdaten. Diese Ebene läuft immer, auch wenn der HTTP-Cache greift.

Session-Cache: Warenkorb, angemeldete Nutzer, laufende Checkout-Prozesse. Sessions müssen schnell lesbar und sicher sein. Bei mehreren App-Servern müssen sie zentral abgelegt werden, sonst verliert jeder zweite Request die Session.

DAL-Cache (Data Abstraction Layer): Shopware cached Datenbankabfragen auf Abstraktionsebene. Diese Schicht wird bei Entitätsänderungen automatisch invalidiert.

Redis: die sinnvolle Basis ab mittlerem Traffic

Redis ist ein In-Memory-Datenspeicher, der deutlich schneller antwortet als Dateisystem oder Datenbank. In Shopware übernimmt Redis typischerweise drei Aufgaben gleichzeitig: Object-Cache, Session-Storage und HTTP-Cache-Speicher.

Ab Shopware 6.6.8 kann man mehrere Redis-Verbindungen in der shopware.yaml benennen und dann je nach Cache-Typ zuweisen. Das ermöglicht zum Beispiel, Sessions in eine persistente Redis-Instanz zu legen und den kurzlebigen Object-Cache in eine flüchtige. Diese Trennung lohnt sich spätestens, wenn der Shop hochverfügbar sein muss.

Die Konfiguration in config/packages/shopware.yaml sieht vereinfacht so aus:

shopware:
  cache:
    redis_prefix: "sw_"
  http_cache:
    reverse_proxy:
      enabled: true
      hosts: ["http://varnish:80"]
      ban_method: "BAN"

Für Sessions kommt ein separater Block in framework.yaml. Wichtig: Der Cache-Key-Prefix verhindert Kollisionen, wenn mehrere Shopware-Instanzen auf dieselbe Redis-Instanz zugreifen.

Ein häufiger Fehler in der Agenturpraxis: Redis wird zwar installiert, aber nur für den Object-Cache aktiviert. Der HTTP-Cache verbleibt auf dem Dateisystem. Das halbiert den Gewinn. Wer Redis einsetzt, sollte alle drei Schichten konsistent umstellen.

Die Auswirkungen auf Shopware Core Web Vitals sind direkt messbar: TTFB-Werte verbessern sich typischerweise um 60 bis 80 Prozent, wenn man von Dateisystem auf Redis wechselt.

Varnish: HTTP-Cache vor dem Webserver

Varnish ist ein Reverse-Proxy-Cache, der vor dem Webserver sitzt. Er fängt HTTP-Anfragen ab und beantwortet sie direkt aus dem Speicher, ohne dass PHP oder Symfony überhaupt gestartet wird. Das ist der schnellste Cache, den es gibt.

Shopware unterstützt Varnish mit einer mitgelieferten VCL-Konfiguration. Ab Shopware 6.6 ist die empfohlene Methode der Einsatz von Varnish mit XKey-Tags statt der älteren BAN-Methode per Redis. XKey erlaubt chirurgische Cache-Invalidierung: Ändert sich ein Produkt, werden nur die Seiten aus dem Cache entfernt, die dieses Produkt enthalten. Alles andere bleibt gecacht.

Wann lohnt sich Varnish? Faustformel aus der Praxis: Ab etwa 50.000 Seitenaufrufen pro Tag beginnt Varnish seinen Vorsprung gegenüber dem eingebauten HTTP-Cache spürbar zu zeigen. Darunter ist der Aufwand für Betrieb und Wartung oft größer als der Gewinn.

Zu beachten: Varnish und personalisierter Content vertragen sich nicht ohne weiteres. Angemeldete Nutzer, Warenkorb-Status und Preisgruppen dürfen nicht im Varnish-Cache landen. Shopware löst das über ESI (Edge Side Includes) und Cookie-Ausschlussregeln in der VCL. Wer das nicht sauber konfiguriert, riskiert, dass Nutzer gegenseitig ihre Warenkörbe sehen.

Cache-Invalidierung: der kritische Punkt

Caching funktioniert nur so gut wie seine Invalidierung. Shopware verwaltet Cache-Tags, die bei Datenänderungen automatisch gesetzt werden. Ändert sich ein Produkt, werden alle gecachten Seiten mit dem Tag dieses Produkts für ungültig erklärt.

Ab Shopware 6.7 läuft die Cache-Invalidierung standardmäßig über die Message Queue (asynchron). Das bedeutet: Eine Produktänderung im Backend führt nicht mehr zu einem sofortigen Cache-Bust, sondern der Worker-Prozess erledigt das im Hintergrund. Das schützt den Server vor Cache-Stampedes bei Massenimporten, erfordert aber laufende Worker-Prozesse. Wer seine Workers nicht überwacht, hat im schlechtesten Fall stundenlang veraltete Preise im Frontend.

Für den täglichen Betrieb heißt das: Shopware Wartung umfasst auch die Überwachung der Message-Queue-Länge und die Sicherstellung, dass Worker-Prozesse nach Updates neu gestartet werden.

Typische Setups nach Shopgröße

Diese Einordnung gibt Orientierung, ersetzt aber keine individuelle Architektur-Analyse:

• Einsteiger / kleiner Traffic: Dateibasierter HTTP-Cache, kein Redis. Funktioniert, aber nicht skalierbar. Gut für Staging-Umgebungen.
• Wachsender Mittelstand: Redis für Object-Cache und Sessions. Eingebauter HTTP-Cache in Redis. Kein Varnish. Deckt den größten Teil der Shopware-Shops in diesem Segment ab.
• Größere Shops mit viel Traffic: Redis für alle Cache-Schichten plus Varnish mit XKey-Integration davor. Message-Queue mit mehreren Workers. Separates Redis für Sessions (persistent) und Cache (flüchtig).
• Enterprise / Hochverfügbarkeit: Redis Cluster, Varnish als Cluster oder CDN-Integration, horizontale App-Server-Skalierung. In diesem Bereich sind Shopware-Editionen wie Evolve oder Beyond relevant. Dazu mehr in der Übersicht der Shopware Enterprise-Editionen.

Einen direkten Überblick darüber, wie Caching in das größere Bild der Shopware Performance-Optimierung eingebettet ist, liefert der entsprechende Wiki-Artikel.

Varnish oder CDN?

Eine Frage, die in der Praxis häufig auftaucht: Brauche ich Varnish, wenn ich sowieso ein CDN nutze?

Beides löst ähnliche Probleme, aber auf unterschiedlichen Ebenen. Ein CDN cached statische Assets wie Bilder, CSS und JS am Netzwerk-Edge. Varnish cached dynamisch gerenderte HTML-Seiten auf dem eigenen Server. Die meisten mittelgroßen Shops brauchen beides: CDN für Assets, Varnish oder eingebauten HTTP-Cache für HTML.

Manche CDN-Anbieter unterstützen auch HTML-Caching (Surrogate Keys, ähnlich XKey). Das kann Varnish ersetzen, erfordert aber sorgfältige Konfiguration und läuft bei personalisierten Shops schnell an Grenzen.

Für Shops, die neu konzipiert werden oder eine grundlegende Infrastruktur-Überprüfung brauchen, lohnt sich ein Blick auf unsere Leistungsseite zur Shopware-Performance.

Häufige Fragen

Muss ich Redis zwingend haben, um Shopware schnell zu machen?

Nein, zwingend nicht. Shopware läuft auch ohne Redis. Für kleine Shops mit wenig Traffic ist der dateibasierte Cache völlig ausreichend. Sobald der Shop aber mehrere tausend Besucher täglich hat oder auf mehreren App-Servern läuft, wird Redis praktisch notwendig. Ohne Redis entstehen bei parallelen Requests auf dasselbe Objekt Race Conditions, die zu Fehlern und unnötiger Datenbanklast führen.

Wird Varnish von Shopware offiziell unterstützt?

Ja. Shopware liefert eine offizielle VCL-Konfiguration mit. Ab Shopware 6.6 ist die XKey-basierte Variante der empfohlene Weg. Die ältere BAN-Methode über Redis funktioniert noch, ist aber für neue Setups nicht mehr die erste Wahl.

Was passiert, wenn ich den Cache nach einem Update nicht leere?

Dann werden möglicherweise veraltete Twig-Templates oder falsch kompilierte Themes ausgeliefert. Nach jedem Shopware-Update und nach Theme-Änderungen muss der Cache vollständig geleert werden. Das passiert über bin/console cache:clear oder über die Admin-Oberfläche. Bei Varnish muss zusätzlich der externe Cache per BAN oder PURGE geleert werden.

Kann Redis zu viel werden, wenn zu viele Daten gecacht werden?

Ja. Redis speichert alles im Arbeitsspeicher. Wenn der Speicher voll ist, beginnt Redis nach der konfigurierten Eviction-Strategie Daten zu verwerfen. Für einen Shopware-Cache ist allkeys-lru (zuletzt am wenigsten genutztes zuerst) eine gute Wahl. Wer Redis ohne Speicherlimit betreibt, riskiert im schlimmsten Fall einen Out-of-Memory-Fehler des gesamten Servers. Klare Limits und Monitoring sind Pflicht.

---

Wenn du dir nicht sicher bist, welches Cache-Setup zu deinem Shop und deiner Infrastruktur passt, oder wenn du Verdacht hast, dass euer Caching gerade nicht richtig greift: Ein konkreter Blick auf euren Stack lohnt sich fast immer. Auf unserer Betreuungsseite für Shopware findest du, wie wir solche Themen im Rahmen der laufenden Shop-Pflege angehen.