Shopware 6 Performance optimieren: HTTP-Cache, CDN und typische Fehler

Ein langsamer Shopware-6-Shop ist selten ein Rätsel. Meist ist der HTTP-Cache aus oder wird ständig geleert, Hintergrundaufgaben laufen an der falschen Stelle, oder der Server erledigt bei jedem Aufruf teure Arbeit, die er sich sparen könnte. Hier erfährst du, wie der HTTP-Cache von Shopware 6 arbeitet, wie du ihn prüfst, wo ein CDN hilft und welche Konfigurationsfehler am häufigsten bremsen.

So arbeitet der HTTP-Cache von Shopware 6

Shopware 6 bringt einen eigenen Full-Page-Cache für die Storefront mit. Ist er aktiv, rendert PHP eine Seite (etwa eine Kategorie oder eine Produktdetailseite) nur beim ersten Aufruf. Das Ergebnis wird gespeichert, und alle weiteren Besucher bekommen diese Kopie, ohne dass die komplette Anwendung erneut anläuft. Für die Ladezeit deiner Storefront ist das der mit Abstand größte Hebel.

Wie gut das funktioniert, hängt von ein paar Punkten ab:

• Er muss eingeschaltet sein. Gesteuert wird der Cache über die Umgebungsvariable SHOPWARE_HTTP_CACHE_ENABLED=1, die meist in der .env.local steht.
• Der Speicherort. Standardmäßig liegt der Cache im Dateisystem unter var/cache. Auf einem einzelnen Server reicht das. Betreibst du mehrere App-Server, empfiehlt die Shopware-Dokumentation zu Caches einen gemeinsamen Cache wie Redis.
• Varianten je Kontext. Eine Seite kann je nach Login-Status, Währung, Steuerzustand oder greifenden Preisregeln anders aussehen. Shopware fasst das im Cookie sw-cache-hash zusammen und legt pro Hash eine eigene Variante ab. So sieht kein Kunde die Preise eines anderen. Besucher im Standardzustand (nicht eingeloggt, Standardwährung, leerer Warenkorb) teilen sich dieselben gecachten Seiten.
• Invalidierung über Tags. Gecachte Antworten tragen Tags für die Daten, aus denen sie entstanden sind. Änderst du ein Produkt, verwirft Shopware gezielt die Seiten mit dem passenden Tag, statt den ganzen Cache zu leeren. Listen wie Produktlistings, Kategorielisten und Suchergebnisse sind allerdings nicht mit jedem enthaltenen Eintrag getaggt. Dort greift die Cache-Lebensdauer, deshalb kann eine Änderung etwas brauchen, bis sie auch in Listen auftaucht.

Eingebauter Cache oder Reverse Proxy?

Für größere Shops unterstützt Shopware einen externen Reverse Proxy, konkret Varnish mit dem XKey-Modul oder Fastly. Der Proxy speichert die Seiten, und Shopware schickt ihm bei Änderungen Invalidierungsanfragen mit den betroffenen Tags. Seit Shopware 6.6 richtest du das unter shopware.http_cache.reverse_proxy ein (ältere Versionen nutzen storefront.reverse_proxy), zusätzlich setzt du SYMFONY_TRUSTED_PROXIES, damit die Anwendung die echten Client-IPs sieht. Die komplette Anleitung steht in der Dokumentation zum Reverse HTTP Cache.

Bei Cache-Treffern bleibt PHP dann komplett außen vor, was sich vor allem in Stoßzeiten bemerkbar macht. Gleichzeitig ist der Proxy eine weitere Komponente, die du betreiben und überwachen musst. Für viele kleine und mittlere Shops genügt der eingebaute Cache mit Redis völlig.

Prüfen, ob der Cache greift

Bevor du irgendetwas umstellst, schau dir an, was tatsächlich passiert. Ruf eine Kategorieseite in einem privaten Fenster zweimal auf und vergleiche die Antwortzeiten im Netzwerk-Tab deines Browsers. Funktioniert der Cache, ist der zweite Aufruf deutlich schneller. Auf der Kommandozeile geht es so:

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://shop.example.com/kategorie/
curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://shop.example.com/kategorie/
curl -sI https://shop.example.com/kategorie/ | grep -i cache-control

Sind beide Aufrufe gleich langsam, ist der Cache entweder deaktiviert, wird durch ein Cookie umgangen oder zwischen den beiden Anfragen geleert. Wirf auch einen Blick auf den Cache-Control-Header. Er legt fest, ob ein Proxy oder CDN vor Shopware die Seite überhaupt speichern darf.

Für einen sauberen Vorher-nachher-Vergleich auf Serverseite ist die TTFB die richtige Kennzahl. Wie du sie auf Server und in der Anwendung senkst, erklärt unser Ratgeber TTFB verbessern.

Typische Konfigurationsfehler

Die folgenden Punkte stecken am häufigsten hinter einem trägen Shopware-6-Shop.

Der Shop läuft im Dev-Modus

Mit APP_ENV=dev sind Profiler und Debugging aktiv, und das verlangsamt jeden einzelnen Aufruf. Ein Live-Shop gehört auf APP_ENV=prod. Stell außerdem das Log-Level in Produktion auf error oder vergleichbar, denn ausführliches Logging schreibt bei jeder Anfrage mit.

Der Admin-Worker erledigt die Hintergrundjobs

Standardmäßig kann Shopware Nachrichten aus der Warteschlange (Indexierung, E-Mails, Importe) über die Administration abarbeiten, solange jemand das Backend geöffnet hat. In der Entwicklung ist das bequem, im Live-Betrieb aber unberechenbar, und es belastet den Webserver. Die Dokumentation zur Message Queue (auf Englisch) ist da eindeutig: Im Live-Betrieb gehört die Warteschlange auf die Kommandozeile. Setz dazu shopware.admin_worker.enable_admin_worker: false in der config/packages/shopware.yaml und lass bin/console messenger:consume async als Hintergrundprozess laufen, den systemd oder Supervisor am Leben hält. Für geplante Aufgaben kommt bin/console scheduled-task:run dazu.

Importe leeren ständig den Cache

ERP-Anbindungen, Bestandsabgleiche und Preisimporte fassen viele Produkte auf einmal an. Jede Änderung invalidiert gecachte Seiten, und ein Import, der alle paar Minuten läuft, hält deinen Cache so praktisch dauerhaft leer. Abhilfe schaffst du, indem du Importe bündelst, nur tatsächlich geänderte Felder schreibst und die verzögerte Invalidierung nutzt. Shopware sammelt die betroffenen Tags dann und arbeitet sie später in einem Hintergrundjob ab. Standardmäßig liegt diese Liste in der Datenbank, die Performance-Dokumentation (auf Englisch) empfiehlt aber Redis als Speicher, wo immer das möglich ist.

Erweiterungen hebeln den Cache aus

Plugins setzen mitunter Cookies, blenden personalisierte Blöcke ein oder verändern bei jedem Aufruf den Kontext. All das kann dazu führen, dass für jeden Besucher eine eigene Cache-Variante entsteht, und damit ist der Cache praktisch wirkungslos. Ist deine Trefferquote nach der Installation einer Erweiterung eingebrochen, teste auf einer Staging-Kopie ohne sie.

MySQL-Suche bei großem Sortiment

Bei umfangreichen Katalogen sind Produktsuche und gefilterte Listings für MySQL teuer. Shopware kann dafür Elasticsearch oder OpenSearch einsetzen. Suchergebnisse landen in der Regel nicht im Full-Page-Cache, eine schnelle Suche wirkt sich also direkt auf die Seiten aus, auf denen deine Kunden suchen und filtern.

PHP und OPcache

Sorg dafür, dass OPcache aktiv und groß genug für die Codebasis von Shopware ist. Mit opcache.validate_timestamps=0 entfällt in Produktion die Dateiprüfung bei jedem Aufruf. Dann musst du OPcache allerdings bei jedem Deployment zurücksetzen. Nutze außerdem eine aktuelle PHP-Version, die dein Shopware-Release unterstützt.

Schwere Bilder und Theme-Assets

Produktfotos direkt aus der Kamera, fehlende Thumbnails oder riesige Hero-Banner verschlechtern den Largest Contentful Paint. Lass Shopware Thumbnails erzeugen, lade Bilder in sinnvollen Abmessungen hoch und setz auf moderne Formate. Mehr dazu steht im Ratgeber Bilder für die Website optimieren.

Wo ein CDN hilft und wo nicht

Ein CDN steht zwischen deinen Besuchern und deinem Shopware-Server und liefert Inhalte von Standorten aus, die näher an den Besuchern liegen.

Was ein CDN nicht behebt, sind langsame ungecachte Anfragen. Braucht der Checkout wegen eines trägen Zahlungsplugins oder einer überlasteten Datenbank mehrere Sekunden, reicht das CDN diese Zeit einfach durch. Bring also zuerst den Ursprungsserver in Ordnung und setz dann die Edge-Schicht davor.

Die richtige Reihenfolge

1. APP_ENV=prod setzen, Logging reduzieren, OPcache prüfen.
2. HTTP-Cache aktivieren und kontrollieren, dass er für Gäste greift.
3. Hintergrundjobs auf CLI-Worker verlegen, Admin-Worker abschalten.
4. Importe so gestalten, dass sie nicht ständig den Cache leeren.
5. Redis und bei großen Shops OpenSearch einsetzen, wo die Last es erfordert.
6. Bilder und Theme-Assets optimieren.
7. Eine Edge-Schicht für statische Dateien, Gastseiten und Schutz davorschalten.

Miss nach jedem Schritt, am besten mit denselben Seiten und Tools, damit du weißt, was tatsächlich etwas gebracht hat. Betreibst du zusätzlich einen WooCommerce-Shop, gelten ähnliche Prinzipien: Lies dazu WooCommerce schneller machen, ohne Warenkorb und Checkout zu gefährden.

So hilft dir fast.site

fast.site sitzt vor deinem bestehenden Shopware-Hosting. Hoster und Shopware-Installation bleiben, wie sie sind. Du fügst die Domain im Dashboard hinzu und stellst die Nameserver deiner Domain auf fast.site um.

Der Fast Edge Cache™ speichert öffentliche Antworten am Edge. Wie lange, richtet sich nach den Cache-Control-Headern deines Shops oder nach eigenen Regeln, und über den Header fs-cache (HIT, MISS oder BYPASS) siehst du bei jeder Antwort, was passiert ist. Warenkorb, Checkout, Kundenkonto und andere sitzungsbasierte Seiten umgehen den Cache, Bestellungen laufen also wie gewohnt. Nach größeren Katalogänderungen leerst du einzelne URLs im Dashboard oder per API, und der Cache Warmer hält wichtige Seiten vorgewärmt.

Außerdem werden Bilder 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, bevor er deinen Server erreicht. Die Einrichtung im Detail zeigen die Shopware-Seite und der Support-Artikel zur Shopware-Integration.

Den ehrlichsten Test liefert dein eigener Shop: Starte eine kostenlose 7-Tage-Testphase ohne Kreditkarte und vergleiche TTFB und Core Web Vitals vorher und nachher.

Häufige Fragen

Wie aktiviere ich den HTTP-Cache in Shopware 6?

Setz SHOPWARE_HTTP_CACHE_ENABLED=1 in deiner .env.local und leere danach den Cache. Achte darauf, dass der Shop mit APP_ENV=prod läuft. Ruf anschließend eine Kategorieseite zweimal als Gast auf und prüfe, ob der zweite Aufruf spürbar schneller ist.

Warum ist mein Shopware-Shop trotz HTTP-Cache langsam?

Häufige Gründe sind Importe, die den Cache ständig invalidieren, Erweiterungen, die Cookies setzen oder Seiten personalisieren, und langsame ungecachte Seiten wie Suche, Warenkorb und Checkout. Prüfe zuerst, ob Gastseiten wirklich aus dem Cache kommen, und schau dir dann an, was bei den ungecachten Anfragen passiert.

Brauche ich Varnish für Shopware 6?

Nicht unbedingt. Für viele Shops reicht der eingebaute Cache, vor allem mit Redis als Speicher. Varnish oder ein anderer Reverse Proxy lohnt sich bei mehreren App-Servern oder viel Traffic, bedeutet aber zusätzliche Infrastruktur, die du betreiben musst.

Kann ich Shopware 6 mit einem CDN betreiben?

Ja. Statische Dateien und Bilder lassen sich problemlos über ein CDN ausliefern. Auch HTML-Seiten für Gäste kannst du cachen, solange das CDN die Cache-Header von Shopware beachtet, Warenkorb, Checkout und Kundenkonto durchreicht und du Änderungen gezielt leeren kannst.

Wie leere ich den Cache in Shopware?

In selbst gehosteten Shops öffnest du in der Administration Einstellungen > System > Caches & Indizes und leerst dort den Cache. Auf der Kommandozeile geht es mit bin/console cache:clear. Nutzt du einen Reverse Proxy, leert bin/console cache:clear:http (verfügbar seit Shopware 6.6.10) dessen Cache. Nach einem kompletten Leeren treffen die nächsten Besucher auf einen kalten Cache, mach das also besser außerhalb der Stoßzeiten.