Shopware 6 Performance optimieren: Schnellere Shops entwickeln

Warum Shopware-Performance messbar sein muss

Ein Shop kann sich auf dem Entwicklerrechner schnell anfühlen und unter realen Bedingungen trotzdem langsam reagieren. Mobile Geräte, schwankende Netzwerke, gefüllte Warenkörbe, eingeloggte Kunden und parallele Hintergrundprozesse verändern das Verhalten deutlich. Deshalb beginnt eine belastbare Optimierung nicht mit einem zufälligen Plugin oder einer einzelnen Servereinstellung, sondern mit reproduzierbaren Messungen.

Für die Nutzererfahrung sind die Core Web Vitals ein sinnvoller Ausgangspunkt. Largest Contentful Paint bewertet, wann der wichtigste sichtbare Inhalt geladen ist. Interaction to Next Paint misst die Reaktionsfähigkeit bei Interaktionen. Cumulative Layout Shift beschreibt unerwartete Verschiebungen während des Seitenaufbaus. Als gute Orientierungswerte gelten ein LCP bis 2,5 Sekunden, ein INP bis 200 Millisekunden und ein CLS bis 0,1 – jeweils auf Basis realer Felddaten am 75. Perzentil.

Diese Kennzahlen erklären jedoch nicht automatisch die Ursache. Ergänzend brauchen wir serverseitige Messwerte: Time to First Byte, Cache-Hit-Rate, PHP-Ausführungszeit, Datenbankabfragen, Queue-Rückstand und Fehlerquoten. Erst wenn Frontend- und Backend-Daten zusammen betrachtet werden, lässt sich erkennen, ob das Problem im Theme, in einer Erweiterung, im Cache oder in der Infrastruktur liegt.

Performance ist kein einmaliger Feinschliff vor dem Launch. Sie ist eine Qualitätsanforderung, die bei Architektur, Entwicklung und Betrieb mitgedacht werden muss.

PMMB Engineering

Storefront und Theme konsequent entschlacken

In Shopware 6 entsteht ein großer Teil der sichtbaren Ladezeit in der Storefront. Zusätzliche JavaScript-Bibliotheken, globale Stylesheets, große Webfonts und Komponenten, die auf jeder Seite initialisiert werden, erhöhen die Datenmenge und verlängern die Verarbeitung im Browser. Das gilt besonders auf mobilen Geräten, auf denen CPU-Leistung und verfügbare Bandbreite begrenzter sind.

Ein gutes Theme lädt nur das, was für die aktuelle Seite benötigt wird. JavaScript-Module sollten früh prüfen, ob das zugehörige DOM-Element überhaupt existiert. Große Bibliotheken gehören nicht pauschal in den globalen Einstiegspunkt. CSS sollte auf wiederverwendbaren Komponenten basieren, ohne dieselben Regeln in mehreren Seitendateien erneut zu definieren.

• Unbenutzte Bibliotheken und doppelte Abhängigkeiten entfernen.
• Seitenspezifische Komponenten nur bei tatsächlichem Bedarf initialisieren.
• Fonts lokal, reduziert und mit passenden Schriftschnitten ausliefern.
• Animationen auf transform und opacity beschränken, statt Layout-Eigenschaften permanent neu zu berechnen.
• Drittanbieter-Skripte erst nach Einwilligung oder Interaktion laden, wenn sie nicht für den ersten Seitenaufbau erforderlich sind.

Plugin-Code im Frontend kritisch prüfen

Ein Plugin kann fachlich korrekt funktionieren und trotzdem unnötige Ressourcen auf jeder Seite laden. Typische Beispiele sind Slider, Tracking-Integrationen, Variantenlogik oder Widgets, deren JavaScript und CSS global eingebunden werden. Bei einer Analyse sollte deshalb nicht nur die Dateigröße betrachtet werden. Entscheidend ist auch, wie viel Arbeit der Browser beim Parsen, Kompilieren und Ausführen leisten muss.

Bilder auf LCP und Layoutstabilität ausrichten

Produktbilder, Kategorievisuals und Hero-Medien sind häufig die größten sichtbaren Elemente einer Shopseite. Damit beeinflussen sie direkt den LCP. Ein modernes Format allein reicht nicht aus. Das Bild muss in einer passenden Auflösung ausgeliefert werden, feste Abmessungen besitzen und im Markup so eingebunden sein, dass der Browser den benötigten Platz vor dem Download reservieren kann.

Das wichtigste Hero- oder Produktbild darf nicht versehentlich lazy geladen werden. Für weiter unten liegende Medien ist Lazy Loading dagegen sinnvoll. Responsive Bildgrößen verhindern, dass ein Smartphone dieselbe Datei wie ein großer Desktop-Monitor laden muss. In Shopware sollten Thumbnail-Konfiguration, tatsächliche Darstellungsgröße und vorhandene Quelldateien gemeinsam geprüft werden.

HTTP-Cache richtig einsetzen

Der integrierte HTTP-Cache ist für produktive Shopware-Systeme zentral. Die offizielle Shopware-Dokumentation empfiehlt HTTP-Caching ausdrücklich, um mehr Requests pro Sekunde zu verarbeiten und Serverressourcen zu reduzieren. Bei mehreren Applikationsservern kann zusätzlich ein Reverse-Proxy-Cache wie Varnish sinnvoll sein.

APP_ENV=prod
APP_DEBUG=0
SHOPWARE_HTTP_CACHE_ENABLED=1

Ein aktivierter Cache ist aber nur dann hilfreich, wenn die Hit-Rate stimmt. Personalisierte Inhalte, Sessions, Warenkörbe und eingeloggte Kunden verändern die Cache-Fähigkeit. Ebenso wichtig ist eine saubere Invalidierung: Produktänderungen, Preise, Verfügbarkeiten und Navigation dürfen nicht dauerhaft veraltet ausgeliefert werden. Deshalb sollten Cache-Header und Cache-Status an typischen Seiten geprüft werden – Startseite, Kategorie, Produktdetail und Suche.

Plugins, DAL und Datenbankabfragen analysieren

Langsame Requests entstehen häufig nicht durch Shopware selbst, sondern durch Erweiterungen, die zu viele Daten laden oder dieselbe Abfrage mehrfach ausführen. Ein Event-Subscriber, der bei jeder Produktseite zusätzliche Associations nachlädt, kann unter Last stärker ins Gewicht fallen als eine große Bilddatei. Besonders kritisch sind Abfragen in Schleifen, unnötig breite Criteria-Objekte und synchrone externe API-Aufrufe.

• Abfragen mit dem Symfony Profiler oder einem Application-Performance-Monitor sichtbar machen.
• Nur benötigte Felder, Associations und Datensätze laden.
• Berechnete Ergebnisse mit einer passenden Lebensdauer zwischenspeichern.
• Externe Dienste nicht ungeprüft in den kritischen Request-Pfad einbauen.
• Neue Indizes nur auf Basis realer Abfragen und Ausführungspläne ergänzen.

Bei der Datenbank gilt: Ein höherer Serverwert heilt keine ineffiziente Abfrage. Zuerst muss klar sein, welche Queries langsam sind, wie häufig sie auftreten und welche Datenmenge verarbeitet wird. Danach lässt sich entscheiden, ob ein Index, eine reduzierte Abfrage oder eine andere fachliche Struktur die richtige Lösung ist.

Queues und geplante Aufgaben aus dem Request lösen

E-Mails, Importe, Exporte, Indexierungen und andere aufwendige Prozesse gehören nicht in den direkten Seitenaufruf, wenn das Ergebnis nicht sofort benötigt wird. Shopware stellt dafür Message Queues und Scheduled Tasks bereit. Entscheidend ist jedoch, dass Worker dauerhaft und zuverlässig laufen. Eine konfigurierte Queue ohne überwachten Consumer verschiebt das Problem lediglich.

Im Betrieb sollten Queue-Länge, Fehlermeldungen, Laufzeit und Speicherverbrauch beobachtet werden. Große Jobs sollten in überschaubare Einheiten zerlegt werden, damit einzelne Fehler nicht einen kompletten Import oder eine lange Transaktion blockieren. Wiederholungen müssen idempotent sein: Ein erneut ausgeführter Job darf keine doppelten Datensätze oder inkonsistenten Zustände erzeugen.

PHP, OPcache und Redis passend konfigurieren

Auf Anwendungsebene sollte OPcache aktiv und ausreichend dimensioniert sein. Laut PHP-Handbuch speichert OPcache vorkompilierten Bytecode im gemeinsamen Speicher. PHP muss die Skripte dadurch nicht bei jedem Request erneut laden und parsen. In Shopware-Projekten mit vielen Klassen ist insbesondere eine ausreichende Zahl beschleunigter Dateien wichtig.

Redis eignet sich für Cache-, Session- oder Lock-Anwendungsfälle, sollte aber nicht als undifferenzierte Universal-Lösung betrachtet werden. Speicherlimit, Datenbanktrennung, Persistenz und Eviction Policy müssen zum Einsatzzweck passen. Die aktuelle Shopware-Dokumentation zu Caches weist zudem auf Cache-Tags ohne TTL hin, die bei Redis beobachtet und regelmäßig bereinigt werden müssen.

Monitoring statt einmaliger Optimierung

Ein Shop verändert sich kontinuierlich: neue Produkte, neue Kampagnen, zusätzliche Plugins, Tracking-Skripte und wachsende Datenbestände. Deshalb kann ein einmaliger Lighthouse-Score keine dauerhafte Performance garantieren. Sinnvoll ist ein kleines, verbindliches Monitoring-Set, das technische und reale Nutzerdaten verbindet.

1. Core Web Vitals über Felddaten beobachten.
2. Serverseitige Antwortzeiten und Fehlerquoten messen.
3. Cache-Hit-Rate und Redis-Speicherentwicklung kontrollieren.
4. Queue-Rückstände und fehlgeschlagene Nachrichten alarmieren.
5. Performance-Budgets für JavaScript, CSS, Bilder und Drittanbieter definieren.
6. Änderungen vor dem Livegang gegen repräsentative Seiten testen.

Praxis-Checkliste für Shopware 6

Fazit

Eine schnelle Shopware-Storefront entsteht nicht durch einen einzelnen Schalter. Theme, Medien, Cache, Erweiterungen, Datenbank, Queue und Infrastruktur müssen als gemeinsames System betrachtet werden. Die beste Reihenfolge lautet deshalb: messen, Engpass isolieren, gezielt ändern und anschließend erneut unter vergleichbaren Bedingungen prüfen.

Wer Performance als fortlaufende Qualitätsanforderung behandelt, reduziert nicht nur Ladezeiten. Das System wird nachvollziehbarer, stabiler und leichter weiterzuentwickeln. Genau darin liegt der langfristige Wert einer strukturierten Optimierung.