Der definitive Leitfaden zur Shopware-Performance auf Shopware PaaS

Eine aktuelle Performance-Studie, in der Hunderte von echten Shopware-Projekten analysiert wurden, ergab einen 10-fachen Unterschied in den Ladezeiten zwischen ähnlichen Shops. Die Ladezeiten der Produktsuchseiten reichten von unter 200 ms bis zu weit über 2 Sekunden – gleiche Plattform, gleiche Seitentypen, sehr unterschiedliche Ergebnisse.

Diese massive Diskrepanz ist weder Glückssache noch liegt sie an der Plattform selbst. Der Betrieb eines leistungsstarken Shopware-Shops erfordert bewusste Infrastrukturentscheidungen, eine sorgfältige Konfiguration und definierte Entwicklungsverfahren. Ein einziges falsch konfiguriertes Plugin, eine nicht gebatchte ERP-Synchronisierung oder ein in der Produktivumgebung aktiviertes Debug-Logging können einen schnellen Shop in einen unbrauchbaren verwandeln.

Dieser Leitfaden vermittelt praktische Erkenntnisse aus monatelangen Lasttests über sieben Infrastruktur-Ebenen hinweg. Wir haben Szenarien mit 3.000 bis 73.000 Bestellungen pro Tag getestet, um herauszufinden, welche Konfigurationen die beste Shopware-Performance liefern.

Für wen ist dieser Leitfaden gedacht?

Wenn Sie Entwickler, Softwarearchitekt, DevOps-Ingenieur oder Produktmanager sind und mit Shopware arbeiten, ist dieser Leitfaden genau das Richtige für Sie. Wir gehen auf die häufigsten Performance-Probleme ein, denen wir in Dutzenden von Projekten begegnet sind, zeigen, was die Testdaten tatsächlich offenbaren, und erklären, wie Sie Ihre Shopware-Bereitstellung für echte Skalierbarkeit optimieren können.

The performance problem

Zwei Shopware-Websites, die identisch erscheinen, können sich unter Last sehr unterschiedlich verhalten. Hier ist, was wir bei Shopware-Projekten immer wieder erleben:

• Plugins sind oft die Schwachstelle. Erweiterungen von Drittanbietern und benutzerdefinierte Erweiterungen sind oft schlecht optimiert, schwer zu debuggen und unter Last schwer zu unterstützen.
• Die Ungültigkeitserklärung des Caches verursacht Probleme. ERP-Importe oder Änderungen durch Administratoren können massive Cache-Löschungen auslösen, was zu Backend-Spitzen und Latenzausbrüchen führt.
• Headless-Architekturen legen die Grenzen des Cachings offen. Die Store-API ist stark auf POST-Anfragen angewiesen, die mit HTTP-Caching-Tools wie Fastly oder Varnish nicht gut zusammenarbeiten.
• DevOps-Workflows sind inkonsistent. Teams verschwenden Zeit damit, Bereitstellungs-, Überwachungs- und Staging-Prozesse neu zu erfinden, anstatt sich auf die Produktentwicklung zu konzentrieren.

Diese Probleme sind nicht auf böse Absichten zurückzuführen, sondern resultieren aus der Komplexität. Shopware ist modular und leistungsfähig, aber ohne Disziplin und die richtigen Tools leidet die performance.

Was Shopware PaaS anders macht

Shopware PaaS basiert auf Upsun und bietet eine Infrastruktur der Enterprise-Klasse mit SLAs für Skalierbarkeit, Hochverfügbarkeit und performance. Es umfasst standardisierte Entwickler-Workflows mit Git-basierten Umgebungen, CI/CD und integrierte Rollback-Funktionen. Außerdem erhalten Sie Tools für die Diagnose und Leistungsoptimierung, einschließlich nativer Unterstützung für blackfire, sowie Best-Practice-Vorlagen und Architektur-Leitfäden.

How Shopware really performs in terms of performance

A recently conducted Shopware 6 performance benchmark by Tideways analyzed hundreds of real projects and found a 10-fold difference in the Time-to-First-Byte (TTFB) across similar page types. The product search pages ranged from under 200 ms to well over 2 seconds, depending on the project.

Diese Diskrepanz spiegelt wider, was wir in der Praxis beobachten: Die Software ist nicht von Natur aus langsam, sondern reagiert sehr empfindlich auf die Art und Weise, wie sie verwendet wird.

Reales Beispiel: Debug-Protokollierung hätte beinahe einen Shop lahmgelegt

Ende 2024 erhielten wir ein Support-Ticket über einen Shopware-Shop, der unter starker Verlangsamung litt. Einige Seiten brauchten über 10 Sekunden zum Laden, in extremen Fällen sogar mehr als 3 Minuten.

Mithilfe der Profiling-Funktionen von blackfire konnten wir die Ursache schnell identifizieren: Das PayPal-Plugin wurde mit aktivierter DEBUG-Protokollierung ausgeführt. Bei hohem Datenverkehr überlastete dies die Festplatte mit Schreibvorgängen und verursachte I/O-Konflikte, da die Prozesse ihre eigenen Protokolle in die Queue stellten. Nachdem der Debug-Modus deaktiviert wurde, normalisierten sich die Antwortzeiten fast sofort.

Dieser Fall veranschaulicht ein immer wiederkehrendes Problem: Eine kleine Fehlkonfiguration in einer Erweiterung eines Drittanbieters kann den gesamten Stack destabilisieren.

Häufige Probleme der Performance

• ERP-Integrationen, die Cache-Invalidierungen auslösen: Bestands- und Produktaktualisierungen, insbesondere wenn sie nicht gebündelt sind, verursachen umfassende Cache-Invalidierungen, was zu Lastspitzen im Backend und Latenz im Frontend führt.
• Übermäßige Personalisierung: Die Bereitstellung einzigartiger Inhalte, wie kundenspezifische Preise oder Anpassungen auf Basis der Postleitzahl, verringert die Cache-Effizienz und erhöht die Auslastung der Infrastruktur.
• Fehlendes Leistungsbudget: Teams stellen Features oder Plugins bereit, ohne akzeptable Leistungsschwellen zu definieren, was im Laufe der Zeit zu einer langsamen Verschlechterung führt.

Erst Cache, dann alles andere

Egal wie effizient Ihr benutzerdefiniertes Programm ist, nichts geht über einen schnellen Cache. Ob am Rand (Fastly), auf der Anwendungsseite (Symfony HTTP-Cache) oder in der Datenbank-/Abfrageschicht (Redis, Doctrine-Metadaten) – Caching ist die wichtigste Strategie für nachhaltige Performance.

Studien korrelieren jede Sekunde zusätzlicher Ladezeit mit einem Rückgang der Konversionsrate. Für Shopware-Shops, die in umkämpften Einzelhandelsmärkten konkurrieren, ist performance nicht nur eine technische, sondern auch eine kommerzielle Frage.

Infrastrukturoptionen verstehen

Shopware PaaS bietet mehrere Infrastrukturstufen:

Grid-Pläne (XL, 2XL, 4XL)

Shared-Resource-Modell, bei dem Ihr Projekt in isolierten Containern auf VMs läuft, die mit anderen Kunden geteilt werden. Am besten geeignet für Einsteiger- und kleine bis mittlere Projekte, bietet kostengünstige Preise; allerdings ist die Vorhersagbarkeit der performance unter extremen Lastbedingungen eingeschränkt.

Dedicated Grid Hosts (DGH-16, DGH-32, DGH-64, DGH-128)

Containerbasiertes Modell, jedoch auf dedizierten VMs. Alle Ressourcen sind exklusiv für Ihr Projekt reserviert, was Burst-Kapazität und konsistente performance ermöglicht. Alle Container befinden sich auf demselben Host, wodurch Latenzen im Netzwerk zwischen den Diensten vermieden werden. DGH-Pläne bieten außerdem deutlich höhere Speichergrenzen als Standard-Grid-Pläne.

Am besten geeignet für mittelgroße bis stark frequentierte Storefronts, die einen vorhersehbaren CPU-Zugriff benötigen.

Dedizierte Tarife (D-12, D-24, D-48, D-96, D-192)

Drei vollständig dedizierte VMs, die für hohe Verfügbarkeit konfiguriert sind, mit MySQL in einer Multimaster-Cluster-Konfiguration, Redis mit Multimaster-Setup und redundanten Anwendungscontainern. Vollständig dedizierte Rechenleistung, Netzwerk und Speicher mit vertikaler Skalierung ohne Ausfallzeiten.

Am besten geeignet für Produktionsumgebungen mit hohen Anforderungen an Parallelität und Verfügbarkeit.

Dedizierte Split-Cluster

Trennt die Aufgaben explizit: Drei Kernknoten verarbeiten Backend-Dienste (DB, Cache, queues), während drei oder mehr Webknoten den Anwendungsdatenverkehr bedienen. Kernknoten skalieren vertikal, Webknoten skalieren sowohl vertikal als auch horizontal für eine nahtlose dynamische automatische Skalierung.

Am besten geeignet für Unternehmensumgebungen mit hoher Frontend-Parallelität oder Traffic-Spitzen.

Best Practices für hohe Performance

Infrastruktur- und Laufzeitkonfiguration

Lassen Sie die Speicherzuweisung und die CPU-Ressourcen nicht auf den Standardwerten. Legen Sie die erwartete Speichernutzung explizit in „.upsun/config.yaml“ fest, damit die Plattform die PHP-FPM-Parallelitätseinstellungen entsprechend optimieren kann.

Halten Sie die CPU-Auslastung unter Last unter 70 %, um bei Spitzenauslastungen Spielraum zu bewahren. Die Infrastruktur-Ebenen sollten unter Berücksichtigung der saisonalen Schwankungen des Geschäfts sowohl auf der Grundlage der durchschnittlichen Auslastung als auch der Burst-Kapazität ausgewählt werden.

Caching-Strategie

HTTP-Caching, anwendungsseitiges Caching (Symfony HTTP-Cache) und Objekt-Caching (Redis) müssen zusammenarbeiten. Wenn möglich, sollten Inhalte von vornherein cachefähig gestaltet werden – indem gegebenenfalls GET- statt POST-Methoden verwendet werden, konsistente Cache-Header sichergestellt werden und Muster vermieden werden, die zu einer Fragmentierung des Caches führen.

Wärmen Sie den Fastly-Cache kritischer Seiten nach Bereitstellungen oder Inhaltsimporten vor, um sicherzustellen, dass der Datenverkehr nicht kalt bedient wird.

Überprüfen Sie die Funktion des Caches, indem Sie die HTTP-Antwort-Header, insbesondere den X-Cache-Header, überprüfen. Ein HIT-Wert zeigt an, dass die Antwort aus dem Cache bereitgestellt wurde; MISS deutet auf eine Cache-Umgehung oder einen Ablauf hin.

Verwalten Sie die Cache-Ungültigkeitserklärung verantwortungsbewusst. Nicht gebündelte Produktaktualisierungen oder schlecht geplante ERP-Synchronisierungen können zu umfangreichen Cache-Löschungen führen. Techniken wie Soft-Purges und verzögerte Löschintervalle können helfen, deren Auswirkungen zu mildern.

Erweiterte Cache-Features

ESI (Edge Side Includes) (Shopware ≥ 6.6.10.0) ermöglicht es Entwicklern, die Seitenrendering in unabhängig voneinander zwischenspeicherbare Fragmente aufzuteilen. Dies ist ideal, wenn nur Teile einer Seite häufig aktualisiert werden müssen.

Soft Purge (Shopware ≥ 6.4.15.0) markiert Einträge als veraltet, stellt sie aber bis zur Aktualisierung weiterhin bereit. Die erste Anfrage löst eine Regenerierung im Hintergrund aus, sodass Benutzer funktionale Inhalte ohne Backend-Spitzen erhalten.

Erweiterungs- und Plugin-Verwaltung

Performance-Rückgänge sind meist auf Plugins von Drittanbietern oder benutzerdefinierte Plugins zurückzuführen. Diese können kostspielige Hooks einführen, redundante Dienste registrieren oder blockierende Logik während der Template-Rendering- oder Checkout-Abläufe ausführen.

Eine performance-orientierte Entwicklung muss eine Bewertung der Auswirkungen von Plugins umfassen – sowohl bei der Installation als auch bei Updates. Selbst ungenutzte Plugins können Ressourcen verbrauchen. Überprüfen Sie regelmäßig den gesamten Plugin-Stack und entfernen Sie veraltete Pakete.

Admin-Konfiguration und Anwendungslogik

Fehlkonfigurationen auf Admin-Ebene können die Performance erheblich beeinträchtigen. Wenn beispielsweise Kategorieseiten so konfiguriert sind, dass sie zu viele Produkte anzeigen, führt dies zu einer ineffizienten Ausführung von Abfragen. Dynamische Regelbedingungen und Werbeaktionen müssen unter Berücksichtigung der Komplexität der Abfragen gestaltet werden.

Vermeiden Sie nach Möglichkeit die Verwendung von rohem SQL-basiertem Suchverhalten. Shopware PaaS unterstützt die Integration mit skalierbaren Suchmaschinen wie OpenSearch, die die Suchlogik aus der Datenbank auslagern.

Externe API-Aufrufe sollten niemals die Antworten der Storefront blockieren. APIs sind von Natur aus anfällig – Verlangsamungen oder Ausfälle können sich auf Ihr gesamtes System auswirken. Externe Kommunikationen sollten nach Möglichkeit asynchron abgewickelt werden.

Die Protokollierungsstufen müssen in der Produktivumgebung entsprechend angepasst werden. Die Aktivierung von ausführlichen oder Debug-Protokollen in Live-Shopfronts kann die Festplatten-I/O-Leistung überlasten und zu Verzögerungen bei den Anwendungsantworten führen.

Performance als Disziplin

Erfolgreiche Shopware-Implementierungen haben ein definiertes Budget für die Performance: messbare Ziele für TTFB-Schwellenwerte, akzeptable CPU-Auslastung unter Spitzenlast, Speicherbeschränkungen und Obergrenzen für Ausfallraten. Diese Metriken sollten als Leitfaden für die Entwicklung dienen und kontinuierlich validiert werden.

Die Performance-Erwartungen müssen sich auch im Entwicklungslebenszyklus widerspiegeln: Git-basierte CI/CD-Workflows, Konsistenz der Umgebung (Entwicklung, Staging, Produktion) und kontinuierliche Beobachtbarkeit.

Methodik für Lasttests

Wir haben Grafana K6 als Lasttest-Framework verwendet und dabei auf Shopware-spezifischen K6-Szenarien aufgebaut, die vier wichtige Verkehrsmuster umfassen:

• browse_only: Simuliert gelegentliche Nutzer oder Bots (Homepage-Besuche, Suche, Durchsuchen von Kategorien, Produktansichten)
• browse_and_buy: Emuliert eine vollständige Customer Journey (Browsen, Kontoerstellung, Warenkorb-Operationen, Checkout)
• logged_in_fast_buy: Modelliert Stammkunden (schnelle Anmeldung und direkter Checkout)
• api_import: Repräsentiert Systemintegrationen (Produktimporte, Bestandsaktualisierungen, Preisänderungen)

Wir haben die Tests so abgestimmt, dass sie das Produktionsverhalten widerspiegeln, indem wir für alle Tests einen festen Datensatz und eine feste Codebasis verwendet haben, mit Crawlee einen konsistenten Cache-Zustand aufrechterhalten haben, um den HTTP-Cache von Fastly vorzuwärmen, und die Datenbank vor jedem Durchlauf zurückgesetzt haben.

Wir haben virtuelle Benutzer (VUs) und Pausen zwischen den Aktionen angepasst, um eine natürliche Nutzung statt einer reinen Parallelität zu simulieren. Ohne diese Pausen sind kleinere Pläne fast sofort ausgelastet, was zu Stresstestergebnissen statt zu Lasttestergebnissen führt.

Zielmetriken

Wir haben jeden Test so kalibriert, dass er mit folgenden Werten übereinstimmt:

• Konversionsrate von ~3 % (Besucher zu Käufern)
• API-Anfragen machen zwischen 5 % und 10 % des gesamten Datenverkehrs aus
• Ziel für die Antwortzeit: p95 TTFB unter 600 ms
• Obergrenze für die CPU-Auslastung: nahe, aber unter 70 %
• Fehlerquote: unter 0,05 % fehlgeschlagene Anfragen

Die Tests liefen 5 Minuten pro Konfiguration und wurden für sechs Plan-Typen wiederholt.

Performance results

Die Tests ergaben Folgendes:

Wichtige Beobachtungen

• Performance skaliert vorhersehbar mit den Ressourcen. Selbst bescheidene Pläne wie XL waren in der Lage, unter optimalen Bedingungen über 3.000 Bestellungen pro Tag zu verarbeiten.
• Die p95-Reaktionszeit blieb stabil. Die p95-TTFB blieb bei allen Plänen unter oder nahe dem Zielwert von 600 ms. Um dieses Ziel zu erreichen, mussten wir jedoch die API-Import-VUs auf maximal 5 begrenzen. Bei Überschreitung von fünf stieg die TTFB und die RPS wurde eingeschränkt, selbst bei den größten Plänen.
• Die API-Auslastung ist kostspielig. API-Anfragen, insbesondere solche, die Produkte erstellen oder aktualisieren, machen mehrere Cache-Ebenen ungültig und belasten sowohl die Datenbank als auch Fastly Edge. Selbst bei nur 5–10 % des gesamten Datenverkehrs machen sie einen überproportionalen Anteil der Ressourcennutzung aus.
• Geringe Ausfallraten über alle Ebenen hinweg. Alle Tarife wiesen Ausfallraten von unter 0,05 % auf, was die Ausfallsicherheit von Shopware PaaS unter konstanter Last belegt.

Verwendung von blackfire zur Identifizierung von Engpässen

Shopware PaaS enthält standardmäßig blackfire und bietet Ihnen leistungsstarke Tools zum Profiling, Beobachten und kontinuierlichen Optimieren Ihrer Storefronts.

Warum Profiling wichtig ist

Profiling hilft bei der Beantwortung von Fragen wie:

• Warum verursacht diese Kategorieseite einen Anstieg der CPU-Auslastung?
• Was steckt hinter diesem plötzlichen I/O-Konflikt?
• Ist meine ERP-Update-Logik ineffizient?
• Warum beeinträchtigt dieses Plugin die Performance in der Staging-Umgebung, aber nicht lokal?

So profilieren Sie eine Shopware-Seite

Sie können ein Profil über die blackfire-Browsererweiterung, die blackfire-CLI in der Staging- oder Entwicklungsumgebung oder Ihre CI-Pipeline für automatisierte testbasierte Profilerstellung erstellen.

Jedes Profil liefert ein Flammendiagramm des gesamten Anforderungslebenszyklus, einschließlich der Ausführungszeit pro Funktion oder Dienst, I/O- und Speicherauslastungs-Hotspots sowie der Zeit, die für Vorlagen, Doctrine-Abfragen, Redis-Aufrufe und Plugins aufgewendet wurde.

Shopware-spezifische Einblicke

Blackfire bietet Shopware-spezifische Instrumentierung, die Performance-Metriken bereitstellt, die auf die Architektur der Plattform abgestimmt sind, einschließlich präziser Zeitangaben für ProductListingRoute, Template-Rendering-Leistung und Plugin-Listener-Overhead.

Häufige Engpässe

• Plugins mit ineffizienten Hooks: Das Profiling deckt Plugins auf, die sich in jede Anfrage einklinken und aufwändige Logik ausführen, wie z. B. redundante Datenbankabfragen oder externe API-Aufrufe.
• Überladene Produktlisten: Seiten, die zu viele Produkte rendern oder keine Paginierung haben, lösen massive SQL-Abfragen und kostspieliges Rendering aus.
• Nicht gebündelte ERP-Updates: Häufige Produktaktualisierungen ohne Batching oder Verzögerung sättigen die I/O, machen Caches ungültig und blockieren PHP-Worker.
• Ausführliche Protokollierung in der Produktivumgebung: Wie im Fall der PayPal-Fehlerbehebung zu sehen ist, kann dies die Festplatten-I/O-Raten überlasten und zu Verzögerungen bei den Antworten führen.

Beispiel aus der Praxis: Analytics-Erweiterung

Vor drei Jahren kam es bei einem Shopware-PaaS-Pilotkunden zu erheblichen Einbußen bei der Performance, die gelegentlich zu Ausfallzeiten von mehreren Minuten führten und mehrmals im Monat auftraten. Durch den Einsatz von blackfire konnte sofort erkannt werden, dass ein Statistikmodul außergewöhnlich große Abfragen ausführte, wodurch die MySQL-Datenbank für bis zu 16 Minuten effektiv gesperrt wurde.

Blackfire ermöglichte die schnelle Identifizierung der Ursache innerhalb weniger Minuten und verwandelte langwierige spekulative Analysen in schnelle Diagnosen.

Erfahrungen aus der Praxis

Die Konfiguration muss bewusst erfolgen

Standardmäßige oder unüberlegte Konfigurationsentscheidungen sind eine der häufigsten Ursachen für Leistungseinbußen. Kategorieseiten, die zu viele Produkte anzeigen, Protokollierungsstufen, die in der Produktivumgebung auf Debug gesetzt bleiben, oder Paginierungseinstellungen, die im Standardzustand belassen werden, tragen alle zu einer schlechten Leistung bei.

Projekte, die eine gute Performance erzielen, zeichnen sich durch eine bewusste Konfiguration aus: Paginierung, Protokollierungsdetailliertheit, Cache-Invalidierungsverhalten und Plugin-Konfigurationen werden explizit abgestimmt.

Die Verwendung von Plugins erfordert Wachsamkeit

Plugins von Drittanbietern und benutzerdefinierte Plugins sind häufig für den Großteil des Laufzeit-Overheads in schlecht performenden Storefronts verantwortlich. Ein Plugin kann Hooks einführen, die bei jeder Anfrage ausgelöst werden, redundante Datenbankoperationen durchführen oder die Cache-Fähigkeit beeinträchtigen.

Hochleistungsfähige Projekte behandeln Plugins als Laufzeitkomponenten, die evaluiert und bei Bedarf ersetzt oder deaktiviert werden müssen, und nicht nur installiert werden.

Caching ist von zentraler Bedeutung, wird jedoch oft unterschätzt.

Der Erfolg des Cachings hängt von einer bewussten Implementierung ab: Verwendung von GET-Methoden anstelle von POST, korrekte Cache-Header und URL-Strukturen, die unnötige Abweichungen vermeiden.

In vielen Fällen sind Leistungsprobleme nicht auf fehlendes Caching zurückzuführen, sondern auf Cache-Invalidierungsprozesse, die durch nicht gebündelte ERP-Aktualisierungen oder administrative Änderungen ausgelöst werden. Projekte, die die Leistung unter Last aufrechterhalten, verwalten die Invalidierung sorgfältig und setzen Soft-Purge-Strategien ein.

Performance-Tests müssen realistisch sein

Effektive Tests erfordern repräsentative Traffic-Mischungen, realistische Konversionsraten, angemessene Verzögerungen zwischen Aktionen und eine genaue Nachbildung des Backend-Verhaltens. Dazu gehört auch Ihr CDN. Die Einbeziehung von Fastly in Lasttests mag umstritten erscheinen, ist jedoch unerlässlich, da Fastly eine Schlüsselkomponente der Laufzeitumgebung ist.

Tests, bei denen API-Importe, Bot-Traffic oder gleichzeitige Checkout-Prozesse ausgelassen werden, können Skalierbarkeitsengpässe möglicherweise erst dann aufdecken, wenn sie sich in der Produktivumgebung manifestieren.

Operative Disziplin fördert die Ausfallsicherheit

Erfolgreiche Shopware-Projekte zeichnen sich durch operative Disziplin aus, einschließlich CI/CD-Pipelines, Staging-Umgebungen, die die Produktivumgebung widerspiegeln, Überwachung und Alarmierung sowie gut getestete Rollback-Verfahren.

Dies erstreckt sich auch auf die Kampagnenvorbereitung; Ereignisse mit hohem Datenverkehr werden als technische Meilensteine behandelt. Leistungsstarke Teams proben im Voraus Verkehrsszenarien, wärmen Caches vor, überwachen durchgehend die Systemmetriken und stellen die Rollback-Bereitschaft sicher.

Checkliste für die Bereitschaft vor dem Start

Bevor Sie live gehen oder eine große Kampagne starten, überprüfen Sie Folgendes:

• [ ] Produkt- und Kategorielisten sind paginiert und für effiziente SQL-Abfragen optimiert.
• [ ] Die Performance von Plugins und Erweiterungen wurde profiliert; unnötige Plugins sind deaktiviert.
• [ ] Die Protokollierungsstufen sind in der Produktivumgebung korrekt eingestellt (keine Debug-Protokolle, sofern nicht vorübergehend erforderlich).
• [ ] ERP- und externe Synchronisierungen werden gebündelt und außerhalb der Spitzenzeiten geplant.
• [ ] API-gesteuerte Cache-Ungültigkeitserklärungen werden verzögert, gebündelt oder gedrosselt (Shopware ≥ 6.7).
• [ ] Für wichtige Landingpages und Navigationsabläufe ist ein Cache-Prewarming eingerichtet.
• [ ] Der HTTP-Cache funktioniert: X-Cache-Header geben für erwartete Routen „HIT” zurück.
• [ ] Das Volumen der Cache-Invalidierungen pro Tag bleibt innerhalb der erwarteten Grenzen.
• [ ] Die Infrastrukturkapazität wurde für eine realistische Spitzenauslastung dimensioniert (CPU-Auslastung bleibt unter ~70 %).
• [ ] Lasttests wurden mit realistischen Traffic-Mixes und Sitzungsverhalten durchgeführt.
• [ ] CI/CD-Pipelines wurden getestet und erzeugen deterministische Builds.
• [ ] Überwachung und Warnmeldungen sind für anwendungs-, system- und geschäftskritische Metriken aktiviert.
• [ ] Die Bereitstellungsprotokolle werden auf nicht abgefangene Ausnahmen oder fehlgeschlagene Hooks überprüft.
• [ ] Integrationen von Drittanbietern werden auf Verfügbarkeit und Latenz überwacht.
• [ ] Sicherheitsheader und HTTPS-Durchsetzung wurden getestet.
• [ ] SEO-kritische Seiten sind crawlbar und haben eine gute performance unter PageSpeed Insights.

Fazit

The results of our tests and field experiences show that Shopware can achieve exceptional performance, but only when supported by conscious infrastructure decisions, thoughtful architectural patterns, and disciplined operational practices.

Die wichtigste Erkenntnis: Die performance von Shopware ist eine gemeinsame, kontinuierliche Verantwortung. Sie wird nicht nur von der Größe der Infrastruktur oder dem Programmcode bestimmt, sondern auch davon, wie durchdacht ein Projekt konfiguriert, erweitert, beobachtet und betrieben wird.

Dies wird durch reale Implementierungen bestätigt. Ein falsch konfiguriertes Zahlungs-Plugin, das in einem Projekt auf Debug-Ebene protokollierte, verursachte übermäßige I/O-Vorgänge auf der Festplatte, wodurch die Website erheblich verlangsamt wurde. Ein anderes Projekt erfuhr regelmäßige Einfrierungen aufgrund eines Analysemoduls, das lang laufende SQL-Abfragen ausgab, die die Datenbank sperrten. Ein Kunde generierte durch nicht gebatchte ERP-Updates über 500 Millionen Cache-Invalidierungen pro Tag, was dazu führte, dass der Cache ständig kalt blieb.

Im Gegensatz dazu hatten Projekte, die stabile, schnelle Antwortzeiten erzielten, bestimmte Gemeinsamkeiten: Sie setzten Tools wie blackfire ein, um Engpässe zu lokalisieren, verwendeten verzögerte oder sanfte Bereinigungen, um Cache-Invalidierungen intelligent zu verwalten, und sorgten für eine enge Abstimmung zwischen ERP-Updates und Cache-Regenerierungsstrategien. Sie warteten nicht darauf, dass die performance nachließ, sondern planten dies von vornherein ein.

Was Sie als Nächstes tun können

• Überprüfen Sie Ihre Caching-Strategie
• Überprüfen Sie Ihren Plugin-Stack
• Validieren Sie die Konfiguration
• Replizieren Sie den Datenverkehr
• Standardisieren Sie die Bereitstellung
• Verwenden Sie Umgebungsvariablen für die Konfiguration
• Schützen Sie Ihre Infrastruktur (fragen Sie nach Fastly Next-Generation WAF)
• Zentralisieren Sie Ihre Protokolle und überprüfen Sie sie

Hervorragende Performance ist nicht nur großen Teams oder Unternehmen mit großem Budget vorbehalten, sondern das Ergebnis der konsequenten Anwendung technischer Disziplin.

Empfohlene Tools und Ressourcen

• Blackfire-Dokumentation: https://docs.blackfire.io
• Shopware PaaS blackfire-Integration: https://developer.shopware.com/docs/products/paas/blackfire.html
• Grafana K6 (open source): https://k6.io
• Shopware K6-Szenario-Repository: https://github.com/shopware/k6-shopware
• Crawlee (für Cache-Vorwärmung): https://crawlee.dev
• PHP-FPM-Laufzeitoptimierung (Upsun): https://fixed.docs.upsun.com/languages/php/fpm.html