Shopware Performance optimieren: Die Stellschrauben, die wirklich wirken

Ein langsamer Shop kostet Geld – das ist bekannt. Weniger bekannt ist, dass die meisten Optimierungsversuche an der falschen Stelle ansetzen. Es wird ein Bild-Plugin installiert, während die eigentliche Bremse eine Datenbankabfrage im Listing ist.

Deshalb hier die Reihenfolge, die sich in der Praxis bewährt hat.

Schritt 0: Messen, bevor du etwas änderst

Ohne Ausgangswert weißt du hinterher nicht, ob es besser geworden ist. Sinnvoll ist die Kombination aus Labordaten und echten Nutzerdaten:

• Lighthouse / PageSpeed Insights für den ersten Überblick
• Feldwerte aus der Search Console – die zählen für das Ranking, nicht die Laborwerte
• Server-seitiges Profiling (z. B. Blackfire, Tideways oder Symfony Profiler auf Staging)
• Slow-Query-Log der Datenbank einschalten

Schritt 1: Caching richtig aufsetzen

Das ist der Hebel mit dem besten Verhältnis von Aufwand zu Wirkung. Shopware bringt einen HTTP-Cache mit; im Produktivbetrieb gehört davor idealerweise ein Reverse Proxy.

• HTTP-Cache aktiviert und mit sinnvoller Lebensdauer konfiguriert
• Reverse Proxy (Varnish oder Fastly) für ausgelieferte Seiten
• Redis für Sessions, Warenkorb und Objekt-Cache statt Dateisystem
• OPcache in PHP korrekt dimensioniert – oft schlicht zu klein eingestellt

Der häufigste Fehler: Der Cache ist zwar aktiv, wird aber durch ein Plugin oder ein unbedachtes Cookie bei jedem Aufruf invalidiert. Prüf im Response-Header, ob du tatsächlich Treffer bekommst.

Schritt 2: Datenbank und Suche

Ab einigen tausend Artikeln wird die Produktsuche über MySQL zum Flaschenhals. Elasticsearch bzw. OpenSearch nimmt der Datenbank die Listing- und Suchabfragen komplett ab:

# Index aufbauen bzw. neu erstellen
bin/console es:index

# Status prüfen
bin/console es:status

# DAL-Index aktualisieren (nach größeren Datenänderungen)
bin/console dal:refresh:index

Zusätzlich lohnt ein Blick ins Slow-Query-Log. In fast jedem gewachsenen Shop findet sich dort ein Plugin, das pro Artikel eine eigene Abfrage absetzt – bei 48 Artikeln im Listing sind das 48 unnötige Roundtrips.

Schritt 3: Das Frontend

Bilder

Bilder sind fast immer der größte Einzelposten am Seitengewicht und meist auch das Element, das den Largest Contentful Paint bestimmt:

• Moderne Formate ausliefern (WebP, wo sinnvoll AVIF)
• Responsive Größen über srcset statt eines großen Bildes für alle
• loading="lazy" für alles unterhalb des sichtbaren Bereichs – aber nicht für das Hauptbild
• Feste width/height setzen, damit nichts nachträglich springt (CLS)

JavaScript und CSS

Jedes Plugin bringt eigene Assets mit. Nach zwei Jahren Shopbetrieb lädt die Startseite dann Skripte für Funktionen, die längst abgeschaltet sind. Ein Audit der geladenen Ressourcen bringt hier oft mehr als jede Mikrooptimierung.

Externe Skripte

Tracking, Chat-Widgets, Bewertungssterne, Consent-Banner: Das sind die üblichen Verdächtigen für einen schlechten INP-Wert. Alles, was nicht sofort gebraucht wird, gehört verzögert geladen – oder gestrichen.

Schritt 4: Infrastruktur

• Aktuelle PHP-Version – jede Minor-Version bringt messbare Verbesserungen
• Genug PHP-Worker für die tatsächliche Last, sonst entstehen Warteschlangen
• HTTP/2 oder HTTP/3, Brotli-Kompression
• CDN für statische Assets
• Message Queue als Worker laufen lassen, nicht per Browser-Trigger

Was das realistisch bringt

Aus Projekten mit gewachsenen Shopware-Shops, jeweils gemessen an derselben Kategorieseite:

Fazit

Performance ist selten ein einzelnes Problem. Es sind meist fünf bis zehn kleine Ursachen, die sich addieren. Wer in der richtigen Reihenfolge vorgeht – erst messen, dann Caching, dann Datenbank, dann Frontend – kommt mit überschaubarem Aufwand sehr weit. Wer beim Frontend anfängt, optimiert oft stundenlang an Symptomen.