Shopware Performance – Caching, Elasticsearch und Core Web Vitals optimieren
Shopware-Performance wirkt direkt auf SEO-Sichtbarkeit – LCP, INP und TTFB sind keine reinen Infrastrukturmetriken, sondern Rankingfaktoren. Den strategischen Rahmen dazu beschreibe ich unter Shopware SEO.
Diese drei Bausteine halten Shopware unter Last schnell – der stärkste Hebel für gute Core Web Vitals und stabile Rankings.
Kostenlos · ohne Anmeldung · Ergebnis sofort
Varnish als HTTP-Cache vor Shopware
Shopware 6 bringt einen eigenen HTTP-Cache mit – in der Praxis reicht er für mittelgroße Shops mit spürbarem Traffic oft nicht. Varnish wird als Reverse-Proxy vor den Webserver gestellt und liefert gecachte Seitenantworten aus, bevor eine einzige PHP-Zeile ausgeführt wird. Die Antwortzeit für gecachte Requests fällt damit auf einstellige Millisekunden.
Shopware 6 unterstützt Varnish nativ: Über den Header X-Shopware-Cache-Id kommuniziert die Anwendung, welche Caches beim Aktualisieren eines Produkts oder einer Kategorie gezielt invalidiert werden müssen. Das verhindert Stale-Content-Probleme, die entstehen, wenn Varnish nicht weiß, wann Inhalte veraltet sind. Die VCL-Konfiguration muss diese Cache-Invalidierungslogik abbilden – Shopware liefert eine Referenz-VCL, die als Ausgangspunkt taugt, aber auf den Stack angepasst werden muss.
Ein praktischer Engpass: Seiten mit personalisierten Elementen (Warenkorbzähler, Login-Status) können nicht vollständig gecacht werden. Shopware löst das mit ESI (Edge Side Includes) – der statische Seitenrahmen kommt aus dem Varnish-Cache, der dynamische Block wird separat nachgeladen. Fehlt diese ESI-Konfiguration, landen personalisierte Seiten komplett im Bypass und belasten den PHP-Stack dauerhaft.
Redis für Session- und Object-Cache
Shopware 6 nutzt standardmäßig das Dateisystem für Sessions und den Object-Cache – das skaliert nicht. Redis als In-Memory-Speicher reduziert die Cache-Zugriffslatenzen auf unter eine Millisekunde und entlastet gleichzeitig den Datenbankserver von Session-Abfragen.
In der config/packages/framework.yaml werden Session- und Cache-Adapter auf Redis umgestellt. Für Shops mit mehreren Instanzen (Load Balancer) ist Redis ohnehin Pflicht: Dateibasierte Sessions sind instanzgebunden und führen zu Login-Abbrüchen, wenn Requests zwischen Servern wechseln. Ein wiederkehrendes Muster: Shops skalieren horizontal, ohne den Session-Adapter zu migrieren – und sehen dann sporadische Logout-Events, die sich im Frontend nicht reproduzieren lassen.
Redis-Konfiguration trennt idealerweise zwei Datenbanken: eine für Sessions (persistenter Speicher ohne TTL-Druck), eine für den Object-Cache (volatile, mit Eviction-Policy allkeys-lru). Diese Trennung verhindert, dass Cache-Evictions unter Last Sessions verdrängen.
Elasticsearch für Produktsuche und Filterperformance
Ab ca. 5.000 Produkten ist die MySQL-basierte Shopware-Suche ein messbarer Performance-Bottleneck. Filteroperationen mit mehreren aktiven Facetten erzeugen komplexe JOIN-Abfragen, deren Laufzeit mit der Kataloggröße nicht linear, sondern überproportional steigt. Elasticsearch (oder sein kommerzieller Nachfolger OpenSearch) löst dieses Problem durch invertierte Indizes, die Facettenfilterung in konstanter Zeit ermöglichen.
Shopware 6 unterstützt Elasticsearch nativ über einen Adapter. Nach der Aktivierung wird der Index per bin/console es:index befüllt – dieser Schritt muss nach jedem SEO-Index-Rebuild und nach Produktmassenimporten explizit angestoßen werden, sonst laufen Suche und Datenbank asynchron. In der Praxis sehe ich regelmäßig Shops, die Elasticsearch konfiguriert haben, aber den Index-Sync nicht in den Deployment-Prozess integriert haben: Neue Produkte erscheinen stundenverzögert in der Suche.
Filterseiten mit langsamer Suchabfrage zeigen hohe TTFB-Werte, die LCP direkt nach oben ziehen – unabhängig von Bildoptimierungen. Wer LCP-Probleme auf Filterseiten untersucht, findet den Engpass oft in der Suchabfragezeit, nicht in den Assets. Mehr zur Bildoptimierung unter Shopware SEO.
Cache-Warmup: kalter Cache als SEO-Risiko
Nach einem Deployment, einem Varnish-Flush oder einem Shopware-Update ist der Cache kalt. Die ersten Crawler und Nutzer, die danach auf den Shop treffen, laden ungecachte Seiten – TTFB kann dabei auf mehrere Sekunden steigen. Für Googlebot ist das dieselbe Erfahrung wie für echte Nutzer: schlechte Core-Web-Vitals-Werte werden in diesem Fenster gemessen.
Nach Deploy/Rebuild leer – erste Aufrufe langsam, auch für den Googlebot.
Cache aktiv vorwärmen – sofort schnelle Auslieferung.
Ein kalter Cache nach Deploys ist ein stilles SEO-Risiko – ein Warmup hält die Seite auch direkt nach dem Rebuild schnell.
Cache-Warmup-Tools rufen alle Shop-URLs sequenziell, bevor Googlebot sie erstmals crawlt – so entstehen keine Cold-Cache-Strafen nach Deployments. In Shopware 6 eignet sich der cache:warmup-Konsolenbefehl oder ein externes Tool auf Basis der sitemap.xml; mehr dazu unter Shopware SEO.
Performance analysieren lassen
Ich bin Andrea Papa – im Erstgespräch analysiere ich konkret, wo Ihr Shopware-Shop Performance verliert: Varnish, ESI, Redis, Elasticsearch-Index-Sync und LCP-Engpässe. Das ist Teil einer vollständigen Shopware SEO-Strategie.
Kostenlos · ohne Anmeldung · Ergebnis sofort
Häufige Fragen zur Shopware-Performance
Warum ist Performance bei Shopware ein SEO-Thema?
Welche Rolle spielt Varnish in Shopware?
Wofür braucht Shopware Redis und Elasticsearch?
Was ist das Risiko eines kalten Caches?
Andrea Papa
Senior SEO-Spezialist mit 15+ Jahren E-Commerce-Erfahrung. Ich optimiere clusterbasiert nach Suchintention – für nachhaltige Sichtbarkeit bei Google und in der KI-Suche.