Shopware 6 Cache: HTTP-Cache Optimierung & Performance

Caching gehört zu den wichtigsten Performance-Faktoren in Shopware 6. Durch das Zwischenspeichern bereits berechneter Inhalte werden Datenbankabfragen, PHP-Prozesse und Serverlast deutlich reduziert. Im Rahmen einer ganzheitlichen Shopware 6 Performance-Optimierung verbessern sich dadurch Ladezeiten, Core Web Vitals und die Skalierbarkeit des Shops erheblich.

Einführung in die Shopware Cache Optimierung

Warum ist Caching für Shopware wichtig?

Caching gehört zu den wichtigsten Performance-Mechanismen in Shopware 6. Häufig angeforderte Inhalte werden zwischengespeichert, sodass Datenbankabfragen und PHP-Prozesse nicht bei jedem Seitenaufruf erneut ausgeführt werden müssen. Dadurch reagieren Seiten deutlich schneller und die Serverlast sinkt spürbar.

Gerade bei hohem Traffic verhindert ein sauber konfiguriertes Caching-System unnötige Lastspitzen und stabilisiert die gesamte Shop-Infrastruktur. Gleichzeitig profitieren Besucher von kürzeren Ladezeiten und einer insgesamt flüssigeren Nutzererfahrung.

Überblick über Cache-Strategien in Shopware

Shopware 6 nutzt mehrere Caching-Ebenen, die unterschiedliche Aufgaben übernehmen. Dazu zählen unter anderem der PHP-OPcache, der Symfony-basierte HTTP-Cache sowie externe Lösungen wie Redis oder Varnish.

Während OPcache kompilierte PHP-Dateien im Arbeitsspeicher hält, beschleunigt Redis datenbanknahe Prozesse und Sessions. Varnish wiederum kann vollständige HTTP-Antworten direkt ausliefern, ohne dass PHP oder MySQL erneut belastet werden.

Erst das Zusammenspiel dieser Ebenen ermöglicht eine skalierbare und performante Shopware-Architektur.

Auswirkungen auf die Performance

Eine durchdachte Cache-Strategie reduziert die Antwortzeiten eines Shopware-Shops oft erheblich. Inhalte können schneller ausgeliefert werden, während gleichzeitig CPU-Last, Datenbankzugriffe und Speicheroperationen sinken.

Besonders der Full-Page-Cache verbessert die Time to First Byte (TTFB) deutlich, da bereits vorberechnete Inhalte direkt ausgeliefert werden können. Das wirkt sich nicht nur positiv auf die Benutzererfahrung aus, sondern unterstützt auch bessere Core Web Vitals und stabilere Conversion Rates. 
Siehe auch unseren Ratgeber zur Shopware TTFB-Optimierung.

Shopware HTTP Cache

Funktionsweise des HTTP Caches

Der Shopware HTTP Cache, basierend auf dem Symfony Reverse Proxy, agiert als intelligenter Zwischenspeicher, der vollständige HTTP-Antworten für bestimmte Routen vorhält, bevor diese an den Browser des Clients gesendet werden. Der Cache wertet HTTP-Header wie „Cache-Control“ und „ETag“ (Edge Side Includes) aus, um zu entscheiden, ob eine Ressource neu vom Backend angefordert oder aus dem eigenen Storage ausgeliefert werden kann. Er entlastet das PHP-Backend bei wiederkehrenden Anfragen enorm, da der gesamte Shopware 6 Stack nicht erneut initialisiert werden muss.

Konfiguration des HTTP Caches

Die Konfiguration des HTTP Caches im Shopware 6 Shop erfolgt primär über die `shopware.yaml` oder `config/packages/framework.yaml` Datei, wo Entwickler die Gültigkeitsdauer (TTL – Time to Live) und die zu cachenden Routen präzise definieren. Eine korrekte Cache-Strategie beinhaltet das Setzen relevanter Cache-Tags für Produkte, Kategorien und Product Streams, um eine granulare Invalidation zu ermöglichen. Die Dokumentation von Shopware liefert hierfür detaillierte Anleitungen, wie dieses Feature für das gesamte System optimal eingerichtet wird.

Cache-Invalidierung und -Leeren

Die Cache-Invalidierung ist ein zentraler Bestandteil des Shopware HTTP-Caches, da sie sicherstellt, dass Kunden keine veralteten Produktdaten, Preise oder Lagerbestände sehen. Statt den gesamten Cache zu leeren, arbeitet Shopware 6 mit Cache-Tags, um betroffene Inhalte gezielt zu invalidieren.

Seit neueren Shopware-Versionen erfolgt die Invalidierung zudem verzögert über Scheduled Tasks und die Message Queue. Werden Produkte oder Kategorien aktualisiert, löscht Shopware die betroffenen Seiten nicht sofort aus dem Cache. Stattdessen werden diese zunächst als „invalid“ markiert und anschließend im Hintergrund neu generiert.

Dieses Verfahren reduziert Lastspitzen deutlich und sorgt insbesondere bei größeren Shops für stabilere Cache-Hit-Raten sowie konstant niedrigere Serverlasten.

Das vollständige Leeren des Caches sollte nur in Ausnahmefällen erfolgen, beispielsweise nach Deployments, Plugin-Updates oder größeren Template-Änderungen. Der klassische CLI-Befehl lautet:

bash
php bin/console cache:clear

Anschließend kann der Cache wieder vorgewärmt werden:

bash
php bin/console cache:warmup

Ein automatisiertes tägliches Leeren des gesamten Caches per Cronjob ist bei größeren Shopware-Projekten allerdings meist nicht sinnvoll. Gerade bei umfangreichen Produktkatalogen kann der Neuaufbau des Full-Page-Caches sehr lange dauern und kurzfristig zu deutlich höheren Serverlasten führen.

Optimale Invalidierungs-Intervalle

Für mittelgroße Shops mit etwa 10.000 bis 50.000 Produkten und regelmäßigem Bestellaufkommen hat sich in vielen Projekten ein Invalidierungs-Intervall zwischen 3.600 Sekunden (1 Stunde) und 14.400 Sekunden (4 Stunden) bewährt.

Zu kurze Intervalle erzeugen unnötige Datenbanklast, während zu lange Intervalle dazu führen können, dass Preisänderungen oder Lagerbestände verspätet im Frontend erscheinen.

Die Anpassung erfolgt direkt über die Datenbank:

SQL
UPDATE scheduled_task 
SET run_interval = 3600 
WHERE name = 'shopware.invalidate_cache';

Cache-Invalidierung aus dem Request-Zyklus auslagern

Die eigentliche Cache-Invalidierung sollte grundsätzlich nicht innerhalb des normalen HTTP-Request-Zyklus verarbeitet werden. Erfolgt die Berechnung direkt während einer Benutzeranfrage, können insbesondere bei größeren Produktkatalogen deutliche Lastspitzen sowie erhöhte Antwortzeiten entstehen.

Stattdessen empfiehlt sich die Ausführung über dedizierte CLI-Worker und Scheduled Tasks im Hintergrund. Dadurch bleibt die Storefront auch bei hoher Parallelität stabil und die Cache-Neuberechnung wird asynchron verarbeitet.

Die Scheduled Tasks sollten daher über einen System-Cronjob und nicht über den Browser-Admin ausgeführt werden:

bash
bin/console scheduled-task:run --time-limit=240 --memory-limit=512M

Zusätzlich empfiehlt sich die Aktivierung der verzögerten Cache-Invalidierung (ab Shopware 6.7):

env
SHOPWARE_HTTP_CACHE_DELAYED_INVALIDATION=1

Dadurch werden Cache-Neuberechnungen asynchron verarbeitet, was die Antwortzeiten bei hoher Parallelität deutlich stabilisiert.

HTTP-Cache-Lebensdauer (TTL)

Die Standard-TTL des Shopware HTTP-Caches beträgt 7.200 Sekunden (2 Stunden). Nach Ablauf dieser Zeit muss die Seite beim nächsten Aufruf vollständig neu generiert werden.

Da Shopware bereits ein intelligentes Tagging- und Invalidierungs-System besitzt, empfiehlt es sich in Produktionsumgebungen häufig, die TTL deutlich höher anzusetzen.

Bis einschließlich Shopware 6.7 erfolgte die Konfiguration global über die .env:

env
Bis Shopware 6.7
# HTTP-Cache aktivieren
SHOPWARE_HTTP_CACHE_ENABLED=1
# Lebensdauer auf 24 Stunden erhöhen (86400 Sekunden)
SHOPWARE_HTTP_DEFAULT_TTL=86400

Neues Cache-System ab Shopware 6.8

Ab Shopware 6.8 wurde das HTTP-Caching grundlegend erweitert. Die Cache-Lebensdauer wird nicht mehr global über die .env gesteuert, sondern granular über Policies auf Route- und Bereichsebene definiert.

Zusätzlich führt Shopware ein neues Opt-out-Prinzip ein. Durch das sw-cache-hash-Cookie bleibt der Cache nun standardmäßig auch für eingeloggte Nutzer oder gefüllte Warenkörbe aktiv.

Wichtige neue Cache-Control-Direktiven sind:

• s_maxage: Definiert die maximale Lebensdauer im HTTP-Cache oder Reverse Proxy.
• stale_while_revalidate: Ermöglicht die Auslieferung veralteter Inhalte, während der Cache im Hintergrund neu aufgebaut wird.
• must_revalidate: Erzwingt eine erneute Validierung beim Browser-Cache.

Die Konfiguration erfolgt über die shopware.yaml:

yaml
# config/packages/shopware.yaml
shopware:
  http_cache:
    # 1. Richtlinien definieren
    policies:
      # Beispiel für eine lange Lebensdauer (z.B. 24 Stunden)
      mein_shop_policy:
        headers:
          cache_control:
            public: true
            max_age: 0
            must_revalidate: true
            s_maxage: 86400           # Cache-Lebensdauer in Sekunden (hier 24 Std)
            stale_while_revalidate: 86400
            stale_if_error: 7200
    # 2. Die Richtlinie standardmäßig zuweisen
    default_policies:
      storefront:
        cacheable: mein_shop_policy

Varnish Cache und seine Rolle

Was bringt Varnish für Shopware? Varnish agiert als HTTP-Reverse-Proxy vor dem Webserver. Er liefert statische Inhalte und HTML-Seiten direkt aus dem RAM aus, ohne PHP oder MySQL zu belasten. Das senkt die TTFB drastisch und schützt das System vor Lastspitzen.

Einrichtung von Varnish für Shopware

Die Einrichtung von Varnish als Reverse Proxy vor Shopware 6 erfordert eine präzise Konfiguration der VCL (Varnish Configuration Language). Varnish verarbeitet eingehende HTTP-Anfragen bereits vor dem eigentlichen Shopware-Backend und entscheidet, ob Inhalte direkt aus dem Cache ausgeliefert oder an PHP und den Webserver weitergeleitet werden.

Typischerweise werden statische Assets sowie vollständige HTML-Seiten gecacht, während dynamische Bereiche wie Checkout, Kundenkonto oder Warenkorb vom Caching ausgeschlossen werden müssen. Zusätzlich spielen Cache-Tags, Purge-Requests und ESI-Blöcke eine wichtige Rolle für eine saubere Cache-Invalidierung.

Eine korrekt konfigurierte VCL reduziert die Backend-Last und somit die Speicherzugriffe und CPU erheblich und verbessert die Skalierbarkeit und die Ladezeit des Shops.

Beispiel einer einfachen Varnish-VCL

Die konkrete Varnish-Konfiguration hängt immer stark von der Infrastruktur, eingesetzten Plugins, individuellen Session-Logiken und dem Traffic-Profil des Shops ab. Dennoch zeigt das folgende Beispiel eine typische Grundkonfiguration für Shopware 6:

VCL
sub vcl_recv {
    # Kein Cache für Checkout und Kundenkonto
    if (req.url ~ "^/checkout" ||
        req.url ~ "^/account" ||
        req.url ~ "^/widgets") {
        return (pass);
    }
    # Nur GET und HEAD cachen
    if (req.method != "GET" &&
        req.method != "HEAD") {
        return (pass);
    }
    return (hash);
}
sub vcl_backend_response {
    # Standard TTL
    set beresp.ttl = 24h;
}

In produktiven Shopware-Umgebungen werden zusätzlich häufig individuelle Regeln für folgende Bereiche implementiert:

• Cache-Tags
• PURGE-Requests
• ESI-Blöcke
• Cookies
• Warenkorb-Handling
• GeoIP-Logiken
• personalisierte Inhalte
• Bot-Traffic
• CDN-Integration

Gerade bei größeren Shopware-Projekten sollte die VCL deshalb immer individuell auf Infrastruktur, Hosting-Setup und Plugin-Landschaft abgestimmt werden.

Reverse Proxy Cache: Vorteile und Herausforderungen

Gerade bei Shops mit hohem Traffic stößt der interne Shopware HTTP-Cache früher oder später an Grenzen. In solchen Szenarien wird Varnish besonders relevant, da Requests verarbeitet werden, bevor überhaupt PHP-Prozesse oder Datenbankabfragen entstehen.

Dadurch sinken sowohl die Serverlast als auch die Antwortzeiten deutlich. Besonders bei stark frequentierten Kategorie- oder Produktseiten lassen sich mit Varnish erheblich bessere Cache-Hit-Raten erzielen.

Die größte Herausforderung liegt allerdings in der Cache-Invalidierung. Änderungen an Produkten, Preisen oder CMS-Inhalten müssen gezielt per Purge-Requests oder über Cache-Tags an Varnish kommuniziert werden, damit keine veralteten Inhalte ausgeliefert werden.

Um diese Herausforderungen bei der Cache-Invalidierung im Live-Betrieb abzufangen, ist ein perfekt abgestimmtes Webserver-Setup unabdingbar. Eine dedizierte Shopware Hosting Optimierung stellt sicher, dass Varnish-Purges ohne Verzögerung verarbeitet werden. Besonders bei stark frequentierten Kategorie- oder Produktseiten lassen sich mit Varnish erheblich bessere Cache-Hit-Raten erzielen. Die korrekte Umsetzung der komplexen Invalidierungs-Logik erfordert jedoch tiefe Systemkenntnisse. Als zertifizierte Shopware Agentur übernehmen unsere Entwickler die fehlerfreie VCL-Anpassung. Wenn Sie unsicher sind, wo Ihr System aktuell Ladezeit verliert, decken wir im Zuge einer strategischen Analyse und Beratung alle versteckten Caching-Bremser auf.

Cache-Statistiken und Monitoring

Ein effektives Monitoring der Varnish-Cache-Statistiken ist unerlässlich, um die Effizienz des Caching zu bewerten und potenzielle Engpässe zu identifizieren. Tools wie `varnishstat` oder Integrationen in Monitoring-Lösungen wie Prometheus liefern detaillierte Einblicke in Cache-Hits, Misses und Evictions, was Aufschluss über die tatsächliche Optimierung gibt. Diese Daten ermöglichen es Shop-Betreibern und Entwicklern, die VCL-Konfiguration kontinuierlich zu optimieren und die Cache-Strategie an die spezifischen Anforderungen des Shopware-Shops anzupassen.

Wichtiger Hinweis zu den Shopware 6 Versionen in Verbindung mit Varnish

• Shopware 6.5 (Die Legacy-Architektur): In dieser Version agiert Varnish primär als nachträglicher Aufsatz. Cache-Invalidierungen erfolgen ressourcenintensiv über BAN-Requests mittels regulärer Ausdrücke (RegEx) über Redis oder die Datenbank. Dies führt bei großen Produkt-Updates zu messbaren CPU-Lastspitzen auf dem Varnish-Server.
• Shopware 6.7 (Der Performance-Quantensprung): Mit Version 6.7 wurde die Architektur komplett umgestellt. Das Varnish-Modul xkey ist nun zwingend erforderlich und löst Artikel-Tags in Mikrosekunden auf. Zusammen mit nativ erzwungenen Edge Side Includes (ESI) werden statische Inhalte und dynamische Fragmente (wie der Warenkorb) sauber getrennt.
  – Die Folge: Offizielle Benchmarks zeigen bei simulierten Flash-Sales bis zu 108 % mehr verarbeitete Bestellungen pro Sekunde und eine Senkung der Server-Latenz (p99) um bis zu 58 %.
• Shopware 6.8 (Die Enterprise-Stabilisierung): Während 6.7 das neue System einführte, bringt 6.8 den finalen Feinschliff. Das mit dem CACHE_REWORK-Feature-Flag in 6.7 begonnene System wird hier zum Standard. Version 6.8 minimiert die gefürchtete „Over-Invalidation“ (das unbeabsichtigte Leeren des gesamten Caches bei einfachen Backend-Konfigurationsänderungen) und stabilisiert die Cache-Hit-Rate im Live-Betrieb nachhaltig.

Durch diese Verbesserungen ändern sich auch die für Shopware notwendigen Konfigurationen in Varnish. Die vcl muss daher zwingend vorher entsprechend angepasst werden.

Redis als Objekt-Cache

Redis lagert als In-Memory-Datenbank flüchtige Cache-Daten und PHP-Sessions aus dem langsamen Dateisystem in den RAM aus. Das verhindert I/O-Engpässe und beschleunigt Shopware-Systeme ab 10.000 Produkten massiv

Konfiguration von Redis in Shopware 6

In vielen großen Shopware-Projekten wird Redis genutzt, um Datenbankabfragen und Session-Locks deutlich zu reduzieren. Vor allem bei hoher Parallelität stößt das Dateisystem-basierte Session-Handling schnell an Grenzen. Die Konfiguration erfolgt über die `config/packages/shopware.yaml`, wo der Redis-Adapter für das Caching und Sessions definiert wird, typischerweise mit einem DSN wie `redis://localhost:6379`. Ein sauber implementiertes Redis erhöht die Geschwindigkeit des Shopware-Shops erheblich.

Beispiel einer Redis-Konfiguration für Shopware 6

Für Shopware 6 wird Redis häufig sowohl als Objekt-Cache als auch für Sessions genutzt. Eine typische Redis-Anbindung in der shopware.yaml kann beispielsweise so aussehen:

yaml
shopware:
  cache:
    invalidation:
      delay: 3600
framework:
  cache:
    app: cache.adapter.redis
    default_redis_provider: 'redis://127.0.0.1:6379'
  session:
    handler_id: Redis
    save_path: "tcp://127.0.0.1:6379"

Wichtig ist dabei, Redis in Produktionsumgebungen niemals ohne Speicherbegrenzung zu betreiben. Ohne ein definiertes maxmemory kann Redis bei hoher Last oder fehlerhaften Cache-Invalidierungen den gesamten verfügbaren Arbeitsspeicher des Servers belegen.

Eine typische Basis-Konfiguration in der redis.conf sieht beispielsweise so aus:

INI
maxmemory 2gb
maxmemory-policy allkeys-lru

Die allkeys-lru-Strategie sorgt dafür, dass ältere Cache-Einträge automatisch entfernt werden, sobald das definierte Speicherlimit erreicht wird.

Die optimale Speichergröße hängt stark von der Shopgröße sowie von folgenden Faktoren ab:

• Produktanzahl
• gleichzeitige Nutzer
• Session-Aufkommen
• eingesetzte Plugins
• HTTP-Cache-Hit-Rate
• Anzahl der Sales Channels

Gerade bei größeren Shopware-Projekten sollte die Redis-Konfiguration daher regelmäßig überwacht und an die tatsächliche Last angepasst werden.

Redis Sessions und deren Optimierung

Die Auslagerung von PHP-Sessions in Redis entlastet das Dateisystem des Servers und beschleunigt die Verarbeitung von Benutzeranfragen, insbesondere bei hohem Traffic, was die Skalierbarkeit des Systems massiv verbessert. Standardmäßig speichert PHP Sessions auf der Festplatte, was bei vielen gleichzeitigen Nutzern zu I/O-Engpässen führt; Redis bietet hier schnelle Zugriffszeiten. Diese Optimierung ist entscheidend für Shops mit 10.000 oder mehr gleichzeitigen Besuchern.

Vergleich zwischen Redis und Varnish

Während Redis als Objekt-Cache und für Sessions auf der Anwendungsebene agiert und datenbanknahe Abfragen beschleunigt, fungiert Varnish als Reverse Proxy HTTP Cache auf Netzwerkebene, der vollständige Seiten liefert. Redis beschleunigt die Backend-Verarbeitung von Shopware, während Varnish die Anzahl der Anfragen an das Backend minimiert. Beide Technologien ergänzen sich; Varnish bedient den „schnellen“ Cache für statische Inhalte und Redis den „dynamischen“ für zwischengespeicherte Daten.

Full Page Cache und Cache Warmup

Implementierung des Full Page Cache

Der Full Page Cache in Shopware 6, oft in Kombination mit Varnish oder dem Symfony HTTP Cache realisiert, speichert die vollständig gerenderten HTML-Seiten für spezifische Routen, um bei wiederkehrenden Anfragen eine extrem schnelle Auslieferung ohne erneute PHP-Verarbeitung zu ermöglichen. Diese intensive Caching-Strategie ist besonders effektiv für nicht-personalisierte Inhalte wie Produktlisten oder Kategorieseiten. Die Konfiguration erfolgt über HTTP-Header sowie die in Shopware integrierten ESI- und Cache-Tags.

Effekte auf Core Web Vitals

Eine effektive Full Page Cache-Implementierung und präzise Cache Warmup Strategien wirken sich direkt und signifikant auf die Core Web Vitals aus, indem sie die Largest Contentful Paint (LCP) und First Input Delay (FID) Werte drastisch verbessern.

Durch die Bereitstellung von vorgenerierten Inhalten werden die Antwortzeiten des Servers minimiert und die Rendering-Geschwindigkeit erhöht, was zu einer besseren User Experience und einer positiven Bewertung durch Suchmaschinen führt.

Skalierung großer Shops

Datenbankentlastung durch Caching

Caching entlastet die Datenbank in großen Shopware-Shops erheblich, indem es die Notwendigkeit wiederholter, ressourcenintensiver Datenbankabfragen eliminiert, da häufig angeforderte Daten aus dem schnelleren Cache bereitgestellt werden. Objekt-Caches wie Redis halten Produkt-, Kategorie- und Konfigurationsdaten im Arbeitsspeicher vor, was die Anzahl der SQL-Abfragen reduziert. Das ist entscheidend für Shops mit hohen Datenmengen und komplexen Beziehungen, da es die Geschwindigkeit und Stabilität sichert.

Optimierung der Serverlast

Durch den umfassenden Einsatz von HTTP-Caches, Reverse Proxys wie Varnish und Objekt-Caches wie Redis wird die PHP-Auslastung und die allgemeine Serverlast in Shopware 6 Umgebungen erheblich reduziert. Zwischengespeicherte Inhalte minimieren die Anzahl der Anfragen, die das PHP-Backend erreichen, wodurch weniger CPU-Zyklen und Arbeitsspeicher alloziert werden müssen. Diese Optimierung erlaubt es dem Shop, hohem Traffic standzuhalten und gleichzeitig schnelle Ladezeiten zu garantieren.

Beispielhafter Aufbau eines Shopware-Clusters für hohe Verfügbarkeit und maximale Performance

• 2 Loadbalancer
• 2 Varnish-Server
• 2 Elasticsearch/Redis-Server
• 2 Webserver
• 2 MySQL-Server (z. B. Galera Cluster oder Primary/Primary-Replikation)
• separates Backupsystem
• Optional: Fileserver/NAS für den gemeinsamen Media-Ordner
• Optional: Backend/Administration-Server

Wichtig ist, dass sämtliche produktiven Systeme — mit Ausnahme des Backupservers — über interne Netzwerkverbindungen kommunizieren. Idealerweise erfolgt dies über ein separates internes Netzwerk oder eine zweite Netzwerkkarte. Alternativ sollten sich alle Systeme mindestens im selben lokalen Netzwerksegment befinden, damit die Kommunikation ohne zusätzliche Router-Hops erfolgt. Dadurch werden Latenzen reduziert und die Gesamtperformance verbessert.

Backup-Strategie

Die optimale Backup-Strategie hängt stark vom Bestellvolumen und der Änderungsfrequenz der Artikeldaten ab.

Für mittlere Shopware-Shops haben sich folgende Intervalle bewährt:

• Datenbank-Backups: tagsüber alle 2 Stunden, nachts alle 6 Stunden (Aufbewahrung: 7 Tage)
• Dateien/Webroot/Media: 2× täglich (Aufbewahrung: 30 Tage)
• Infrastruktur-Konfigurationen (z. B. Loadbalancer/Varnish): nach Änderungen, zusätzlich monatliche Sicherung.

In der Praxis reicht meist ein konsistentes Backup von Datenbank und Web-/Media-Daten vollständig aus. Dienste wie Redis, Varnish oder Elasticsearch müssen normalerweise nicht separat gesichert werden, da ihre Daten nach einem Neustart automatisiert neu aufgebaut beziehungsweise synchronisiert werden.

Hosting-Optionen: Shopware Cloud vs. eigener Server

Die Wahl zwischen Shopware Cloud und einem eigenen Server beeinflusst maßgeblich die Skalierbarkeit und Cache-Optimierung eines Shopware-Shops. Die Cloud bietet vorkonfigurierte, oft automatisch skalierende Caching-Lösungen, während ein eigener Server volle Kontrolle über jede Cache-Ebene und Infrastruktur ermöglicht. Shopware Cloud managt die Infrastruktur und das Caching automatisch, was den Administrationsaufwand reduziert. Ein eigener Server jedoch bietet die Flexibilität, Redis, Varnish und OPCache präzise an spezifische Anforderungen anzupassen, was für eine maximale Optimierung unerlässlich ist.

Best Practices für die Cache-Optimierung

Für eine effektive Cache-Optimierung in Shopware 6 empfiehlt es sich, eine mehrstufige Cache-Strategie zu implementieren, die Redis als Objekt-Cache, Varnish als Full Page Cache und den Shopware HTTP Cache kombiniert. Das Setzen präziser Cache-Tags für eine granulare Invalidierung, die Automatisierung von Cache-Warmup-Prozessen via Cronjobs und das regelmäßige Monitoring der Cache-Statistiken sichern eine dauerhaft hohe Geschwindigkeit. Reduzieren Sie PHP-Prozessierungen und Datenbankabfragen durch konsistentes Caching.

Monitoring und Analyse

Tools zur Überwachung der Cache-Performance

Die kontinuierliche Überwachung der Cache-Performance ist essenziell, um Engpässe frühzeitig zu erkennen und die Stabilität eines Shopware-Systems dauerhaft sicherzustellen. Gerade bei größeren Shops mit hoher Parallelität entscheidet ein sauberes Monitoring oft darüber, ob ein Shop auch unter Last stabil performant bleibt.

Abhängig von der eingesetzten Infrastruktur kommen dabei unterschiedliche Werkzeuge zum Einsatz.

Varnish Monitoring mit varnishstat

Das wichtigste Analysewerkzeug für Varnish ist varnishstat. Es liefert in Echtzeit Informationen über Cache-Hits, Misses, Backend-Requests, Speicherverbrauch und Queue-Auslastungen.

Besonders relevante Kennzahlen sind:

Ein typischer Aufruf:

bash
varnishstat -1

Für produktive Shopware-Systeme gelten dauerhaft niedrige Cache-Hit-Raten meist als Warnsignal. Liegt die Hit-Rate dauerhaft unter 50% (bis Shopware 6.6.x) / 70 % (ab Shopware 6.7), deutet dies häufig auf folgende Probleme hin:

• Falsch konfigurierte Cookies
• Unnötige return(pass)-Regeln
• Zu aggressive Cache-Invalidierungen
• Fehlende xkey-Softpurges
• Plugins mit personalisierten Inhalten

Gerade bei stark frequentierten Kategorie-Seiten sollten Cache-Hit-Raten von deutlich über 90 % erreichbar sein.

Analyse von HTTP-Headern

Sehr viele Cache-Probleme lassen sich bereits direkt im Browser analysieren. Über die Developer-Tools (F12) können HTTP-Header geprüft werden.

Wichtige Header in Shopware-/Varnish-Umgebungen:

Ein typisches Beispiel:

html
x-cache: HIT
cache-control: public, s-maxage=86400
age: 5321

Dies bedeutet:

• Seite wurde erfolgreich aus dem Varnish ausgeliefert
• TTL beträgt 24 Stunden
• Objekt liegt bereits seit 5321 Sekunden im Cache
• Durch eine kleine Anpassung in der Varnish default.vcl lassen sich zusätzlich auch die Anzahl der Hits mit anzeigen

vcl
sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
        set resp.http.X-Cache-Hits = obj.hits;
    } else {
        set resp.http.X-Cache = "MISS";
    }
}

Taucht dagegen permanent MISS auf, obwohl die Seite cachebar sein sollte, liegt meist ein Cookie-, Session- oder Proxy-Problem vor.

Redis-Monitoring und Speicheranalyse

Redis sollte regelmäßig hinsichtlich Speicherverbrauch, Evictions und Antwortzeiten überwacht werden.

Wichtige Befehle:

bash
redis-cli info memory

zeigt unter anderem:

• aktuellen RAM-Verbrauch
• maxmemory-Limits
• Fragmentierung
• ausgelagerte Keys

Ebenso wichtig:

bash
redis-cli info stats

Hier lassen sich unter anderem folgende kritische Werte erkennen:

Steigende evicted_keys sind meist ein klares Zeichen dafür, dass:

• das maxmemory zu klein gewählt wurde
• Sessions und Cache gemeinsam betrieben werden
• die falsche Eviction-Policy aktiv ist

Gerade bei Shopware sollte Redis niemals unbegrenzt wachsen dürfen.

PHP OPcache überwachen

Auch der PHP-OPcache gehört zu den wichtigsten Performance-Faktoren in Shopware 6.

Der aktuelle Status lässt sich beispielsweise über:

bash
php -i | grep opcache

oder über kleine Status-Skripte auslesen.

Kritische Kennzahlen:

Gerade bei großen Shopware-Installationen mit vielen Plugins kommt es häufig vor, dass:

• opcache.max_accelerated_files zu klein ist
• Scripts permanent neu geladen werden
• die Hit-Rate stark sinkt

In produktiven Umgebungen sollte die OPcache-Hit-Rate dauerhaft nahe 100 % liegen.

Langfristiges Monitoring mit Prometheus & Grafana

Bei größeren Shopware-Clustern empfiehlt sich zusätzlich ein zentrales Monitoring über:

• Prometheus
• Grafana
• Netdata
• Zabbix
• Datadog
• New Relic
• check_mk

Dadurch lassen sich unter anderem folgende Werte dauerhaft visualisieren:

• Cache-Hit-Raten
• Redis-RAM-Auslastung
• MySQL-Query-Zeiten
• PHP-FPM-Auslastung
• Queue-Laufzeiten
• TTFB
• Varnish Backend Fetches
• CPU-Load der Webserver

Besonders hilfreich sind historische Vergleiche nach:

• Deployments
• Plugin-Updates
• Shopware-Updates
• Marketing-Kampagnen
• Black-Friday-Lastspitzen

So lassen sich Performance-Probleme oft bereits erkennen, bevor Kunden sie bemerken.

Typische Praxisprobleme im Monitoring

In realen Shopware-Projekten zeigen sich häufig wiederkehrende Muster:

Plötzlich sinkende Cache-Hit-Rate

Oft verursacht durch:

• neue Plugins
• Tracking-Skripte
• falsch gesetzte Cookies
• Session-Starts auf jeder Seite

Hohe Redis-Evictions

Häufig verursacht durch:

• fehlendes maxmemory
• gemeinsame Nutzung für Sessions und Cache
• die falsche Eviction-Policy

Varnish Backend Fetch Spikes

Typische Ursachen:

• fehlendes Cache-Warming
• harte Purges statt Softpurges
• zu kurze TTLs
• fehlerhafte Invalidierung

Hohe TTFB trotz Varnish

Meist verursacht durch:

• uncached AJAX-Requests
• langsame Elasticsearch-Abfragen
• blockierende Plugins
• überlastete MySQL-Server

Ein professionelles Monitoring ermöglicht es, solche Probleme frühzeitig zu identifizieren und gezielt gegenzusteuern, bevor die Performance oder Stabilität des Shops leidet.

FAQ Typische Cache-Probleme und Cache Optimierung

Zu den häufigsten Fragen rund um Cache-Strategien in Shopware 6 gehören Aspekte wie „Welche Caches sind für meinen Shop relevant?“, „Wie verhindere ich veraltete Inhalte?“ und „Wie skaliere ich das Caching bei hohem Traffic?“. Shop-Betreiber und Developer suchen oft nach Best Practices für die Konfiguration von Redis, Varnish und dem HTTP Cache, sowie nach Methoden zur effektiven Invalidierung und zum Cache Warmup. Diese Fragen fokussieren auf die Optimierung der Ladezeiten und die Entlastung der Server.

ini
# RDB-Snapshots deaktivieren
save ""
# Append Only File deaktivieren
appendonly no

 env # Lokaler Varnish TRUSTED_PROXIES=127.0.0.1,::1 # Separater Varnish-Server TRUSTED_PROXIES=192.168.1.50 # Docker-/dynamische Netzwerke TRUSTED_PROXIES=127.0.0.1,REMOTE_ADDR 

YAML
shopware:
  http_cache:
    reverse_proxy:
      use_varnish_xkey: true

opcache.memory_consumption=512

opcache.max_accelerated_files=60000

opcache.validate_timestamps=0

opcache.interned_strings_buffer=32

bash
# Beispiel für 64 GB RAM
-Xms30g
-Xmx30g

bash
# Varnish: Echtzeit-Statistiken anzeigen
varnishstat

# Nur wichtige Cache-Metriken filtern
varnishstat -f MAIN.cache_hit,MAIN.cache_miss,MAIN.backend_fail

# Cache-Hit-Rate live beobachten
watch -n1 "varnishstat -f MAIN.cache_hit,MAIN.cache_miss"

# Backend-Fehler analysieren
varnishstat -f MAIN.fetch_failed,MAIN.backend_busy

# Varnish: HTTP-Requests und Cache-Verhalten analysieren
varnishlog

# Nur Cache-Hits anzeigen
varnishlog -g request -q "RespHeader:x-cache ~ hit"

# Nur Cache-Misses anzeigen
varnishlog -g request -q "RespHeader:x-cache ~ miss"

# Fehlerhafte Backend-Requests filtern
varnishlog -g request -q "BerespStatus >= 500"

# Requests einer bestimmten URL analysieren
varnishlog -g request -q 'ReqURL ~ "/kategorie/"'

bash
# Redis: Allgemeine Server- und Cache-Informationen
redis-cli INFO

# Nur Speicherinformationen anzeigen
redis-cli INFO memory

# Cache-Hit-Rate prüfen
redis-cli INFO stats

# Speicherbelegung live überwachen
watch -n1 'redis-cli INFO memory | grep used_memory_human'

# Aktuelle Eviction-Policy prüfen
redis-cli CONFIG GET maxmemory-policy

# Anzahl gelöschter Keys durch Speicherknappheit prüfen
redis-cli INFO stats | grep evicted_keys

# Alle aktiven Keys zählen
redis-cli DBSIZE

# Langsame Redis-Operationen anzeigen
redis-cli SLOWLOG GET 10

conf
maxmemory 2gb
maxmemory-policy volatile-lru
appendonly no
save ""

ini
opcache.memory_consumption=512
opcache.max_accelerated_files=60000
opcache.interned_strings_buffer=32
opcache.validate_timestamps=0

bash
varnishstat -1 | grep cache_hit
varnishlog -g request -q "ReqUrl ~ /"

conf
maxmemory 4gb
maxmemory-policy volatile-lru
appendonly no
save ""

Mathias Goldhan

Founder, Geschäftsführer & IT-Consultant

SaaS-Pionier, Enterprise-Architektur & Cluster-Experte

Mathias Goldhan legte 1995 das Fundament für die heutige Digitalagentur und führt die HQ GmbH seit 2005 strategisch und operativ. Mit über drei Jahrzehnten Erfahrung in der Softwareentwicklung und Systemarchitektur berät er den Mittelstand und Marken bei der Digitalisierung geschäftskritischer Prozesse. Er ist der strategische Kopf hinter der Positionierung der HQ GmbH unter den Top 100 Digitalagenturen (BVDW).

Als anerkannter SaaS-Pionier und Spezialist für High-Performance-Hosting konzipiert er hochverfügbare Cluster-Infrastrukturen und leitet die technische Rettung festgefahrener E-Commerce-Großprojekte. Seine Expertise für ausfallsichere Systeme und API-basierte B2B-Automatisierungen steuert er international zwischen dem Hauptsitz in Thüringen und der Niederlassung in Spanien.

Vollständiges Autorenprofil & E-Commerce-Expertise ansehen