Shopware 6 Performance optimieren: Best Practices für Entwickler & Agenturen (Caching, Datenbank, Plugins)

Shopware 6 Performance optimieren: Vorgehen, Prioritäten und Messbarkeit

Wenn ein Shopware-6-Shop „langsam“ ist, steckt selten nur eine Ursache dahinter. In Agenturprojekten sehen wir meist eine Kombination aus Cache-Fehlkonfiguration, zu vielen oder schlecht implementierten Plugins, suboptimalen Datenbank- und Suchindex-Setups sowie Deployments, die Caches/Indizes unnötig invalidieren. Dieser Guide zeigt ein praxiserprobtes Vorgehen, um Performance systematisch zu verbessern: erst messen, dann priorisiert optimieren, anschließend verifizieren.

Ziel ist nicht nur eine niedrigere Time to First Byte (TTFB), sondern messbar bessere Core Web Vitals (LCP, INP, CLS) und stabilere Response-Zeiten unter Last.

1) Baseline schaffen: Messen, bevor du optimierst

Ohne Baseline optimierst du ins Blaue. Lege zunächst fest, welche Seiten und Flows repräsentativ sind: Startseite, Kategorie, Produktdetail, Suche, Warenkorb, Checkout. Miss jeweils „cold“ (Cache leer) und „warm“ (Cache gefüllt).

Empfohlene Tools (praxisnah)

• Lighthouse (lokal oder CI): gut für Core Web Vitals und Frontend-Regressionen.
• WebPageTest: realistische Netzwerkprofile, Filmstrip, TTFB, LCP-Details.
• Serverseitiges Profiling (z. B. Blackfire oder XHProf): um PHP-Hotspots, Doctrine-Queries, Template-Overhead sichtbar zu machen.
• Logs & Monitoring: Nginx/Apache Access Logs, PHP-FPM slowlog, MySQL slow query log, OpenSearch/Elasticsearch slow logs, APM (z. B. New Relic/Datadog).

Minimaler Start: Shopware im Prod-Modus prüfen

Ein häufiger Fehler: Performance wird in einer Umgebung bewertet, die nicht prod-nah ist (Debug an, falscher Cache-Adapter, keine OpCache-Warmups). Stelle sicher, dass du im Produktivmodus misst.

bin/console system:info

2) Quick Wins mit hoher Wirkung: HTTP-Cache, Shopware-Cache, CDN

In Shopware 6 ist Caching kein „Nice-to-have“, sondern Grundvoraussetzung. Die größten Hebel liegen meist in (1) korrektem HTTP-Cache-Setup, (2) konsequenter Cache-Warmup-Strategie und (3) sauberer Invalidierung statt „Cache komplett leeren“.

2.1 HTTP-Cache richtig einordnen

Shopware kann mit HTTP-Cache (Reverse Proxy) arbeiten. In der Praxis sind typische Setups: Varnish, Nginx als Reverse Proxy oder ein CDN mit Cache (für statische Assets und ggf. HTML, wenn kompatibel). Wichtig: dynamische Inhalte (z. B. personalisierte Preise, Warenkorb) dürfen nicht falsch gecached werden.

• Prüfe Cache-Hits über Response-Header (je nach Setup) und Access Logs.
• Trenne statische Assets (CDN, lange Cache-Control) von HTML (kurzlebiger, invalidierungsgetrieben).
• Vermeide „no-store“ pauschal, wenn es nicht nötig ist.

2.2 Shopware-Cache gezielt managen (statt reflexartig leeren)

In vielen Projekten wird bei jeder Kleinigkeit der komplette Cache geleert. Das führt zu Lastspitzen, kalten Caches und schlechter TTFB. Besser: gezielte Invalidierung und planbarer Warmup nach Deployments.

bin/console cache:pool:clear cache.app

Wichtig: Cache-Pools unterscheiden sich je nach Konfiguration. In Agentur-Setups ist ein externer Cache (Redis) oft sinnvoll, aber nur, wenn er korrekt dimensioniert und stabil betrieben wird. Ein instabiler Redis kann Performance sogar verschlechtern (Timeouts, Retries).

2.3 CDN & Asset-Strategie

Core Web Vitals hängen stark am Frontend: Bildgrößen, Fonts, JS-Bundles, Third-Party-Skripte. Nutze ein CDN für statische Assets und achte auf:

• Bildoptimierung: moderne Formate, passende Größen, keine riesigen Hero-Bilder ohne Not.
• Cache-Control für versionierte Assets (lange TTL).
• Third-Party-Skripte minimieren: Tag Manager, Tracking, Chat-Widgets sind häufige INP/LCP-Killer.

3) Indexierung & Hintergrundprozesse: Wenn „schnell“ an Jobs hängt

Shopware 6 nutzt Indexer und Hintergrundjobs. Wenn diese nicht sauber laufen, entstehen Folgeprobleme: langsame Suche, inkonsistente Daten, hohe DB-Last und „mysteriöse“ Performance-Einbrüche nach Importen oder Plugin-Updates.

3.1 Message Queue / Worker stabil betreiben

Stelle sicher, dass Worker dauerhaft laufen und nicht nur sporadisch via Cron. Unterdimensionierte Worker führen zu Backlogs, die sich in Peaks entladen (z. B. nach Deployments oder großen Produktimporten).

bin/console messenger:consume -vv

Caveat: In produktiven Umgebungen solltest du Worker über einen Prozessmanager (z. B. systemd, Supervisor, Kubernetes) betreiben und Logging/Restart-Strategien definieren. Achte außerdem darauf, dass Deployments Worker sauber neu starten, damit sie neuen Code laden.

3.2 Indexer-Strategie bei Imports und Massenänderungen

Typischer Bottleneck: Massenimporte triggern Indexer in einer Weise, die DB und Search-Cluster überlastet. Best Practices:

• Batching: Änderungen in sinnvollen Paketen statt „alles auf einmal“.
• Off-Peak: große Reindex-Läufe außerhalb der Peak-Zeiten.
• Monitoring: Queue-Länge, Job-Dauer, Fehlerraten.

4) Datenbank-Optimierung (MySQL/MariaDB): Queries, Indizes, Connection Handling

Viele Shopware-Performance-Probleme sind letztlich Datenbankprobleme: zu viele Queries pro Request, fehlende Indizes, Locking, zu kleine Buffer, falsche Isolation/Timeouts oder „Chatty“ Plugins.

4.1 Slow Query Log & Query-Analyse als Standard

Aktiviere den Slow Query Log (prod-nah, mit sinnvollem Threshold) und analysiere regelmäßig. Achte auf:

• N+1 Queries (häufig durch Plugins oder falsche DAL-Nutzung).
• Fehlende Indizes auf Filter-/Join-Spalten.
• Sortierungen ohne Index (filesort) und große temporäre Tabellen.

4.2 Doctrine/DAL: typische Fallen

Shopware nutzt Doctrine und die DAL. Häufige Performance-Fallen in Custom-Code:

• Zu große Criteria mit vielen Associations, die mehr laden als nötig.
• Ungezielte Aggregationen auf großen Tabellen.
• Mehrfaches Laden derselben Entitäten innerhalb eines Requests.

Praxis-Tipp: Profiling mit Blackfire/XHProf zeigt dir nicht nur „langsame Funktionen“, sondern auch Query-Anzahl und Zeitanteile. Setze dir Zielwerte pro Seitentyp (z. B. Kategorie-Seite: Query-Anzahl und DB-Zeit budgetieren).

4.3 DB-Konfiguration & Infrastruktur

Ohne in „Tuning um des Tunings willen“ zu verfallen: Stelle sicher, dass die DB nicht am Limit läuft. Prüfe CPU, RAM, I/O, Connection Limits, Buffer Pool/Cache-Hit-Rates. Häufige Agentur-Realität: DB läuft auf zu kleinem Host, während PHP skaliert wurde. Das verschiebt den Engpass nur.

5) Elasticsearch/OpenSearch Tuning: Suche ist oft der versteckte Performance-Treiber

Suche, Filter, Facetten und Sortierungen können massiv Last erzeugen. Wenn OpenSearch/Elasticsearch nicht sauber dimensioniert oder falsch konfiguriert ist, leidet nicht nur die Suche, sondern auch das Gesamtsystem (Timeouts, Retries, blockierende Requests).

5.1 Typische Bottlenecks

• Zu kleine Cluster (RAM/Heap), hohe GC-Zeiten, Swap aktiv.
• Zu viele Shards für kleine Indizes oder zu große Shards für große Indizes.
• Teure Queries durch komplexe Facetten/Filter-Kombinationen.
• Reindex zur falschen Zeit (Peak) oder zu häufige Voll-Reindex-Läufe.

5.2 Praktische Maßnahmen

• Monitoring: Query-Latenzen, CPU, Heap, GC, Threadpools, Queue-Rejections.
• Slow Logs aktivieren, um teure Queries zu identifizieren.
• Index-Lifecycle: Reindex planbar machen, nicht „bei jedem Deploy“.

Caveat: „Mehr RAM“ hilft nicht, wenn die Query-Struktur oder Shard-Strategie falsch ist. Umgekehrt bringt perfektes Tuning wenig, wenn Plugins bei jeder Seitenansicht unnötige Suchanfragen auslösen.

6) Plugin Performance Audit: Der häufigste Hebel in Bestandsprojekten

In bestehenden Shops ist die Plugin-Landschaft oft der größte Unsicherheitsfaktor. Ein einzelnes Plugin kann TTFB verdoppeln, Query-Anzahl vervielfachen oder Caches permanent invalidieren.

6.1 Audit-Checkliste (konkret)

• Event Subscriber: Welche Subscriber laufen auf jedem Request? Sind sie notwendig?
• DAL/Doctrine: Erzeugt das Plugin N+1 Queries oder lädt es zu viele Associations?
• Cache-Invalidierung: Invalidiert das Plugin zu breit (z. B. komplette Navigation/Listing-Caches)?
• External Calls: Ruft es APIs synchron im Request auf (Payment, ERP, Tracking)? Timeouts?
• Template/Storefront: Zusätzliche JS/CSS-Bundles, Render-Overhead, Third-Party Tags.
• Admin/API: Verlangsamt es Backoffice-Workflows (Indexing, Imports)?

6.2 Vorgehen in Agenturprojekten

Bewährt hat sich ein „Plugin-Budget“: Für kritische Seiten (Kategorie/PDP/Checkout) definierst du Zielwerte (TTFB, DB-Zeit, Query-Anzahl). Dann testest du Plugins einzeln oder in Gruppen (Staging) und misst die Differenz. Das ist oft schneller als monatelanges „Optimieren überall“.

7) Deployment-Strategien: Performance nicht bei jedem Release verlieren

Viele Performance-Probleme entstehen nicht durch Code, sondern durch Deployments: kalte Caches, fehlende Warmups, lange Migrationsläufe zur Peak-Zeit, Worker mit altem Code.

7.1 Best Practices für stabile Releases

• Blue/Green oder Rolling Deployments, um Downtime und Cache-Kälte zu reduzieren.
• Cache-Warmup nach Deploy: wichtige Seiten/Routes gezielt anwärmen.
• DB-Migrationen planen: große Migrationen off-peak, ggf. in mehrere Releases splitten.
• Worker-Restarts kontrolliert: neue Version muss überall aktiv sein.

7.2 Konfigurations- und Runtime-Fallen

• PHP OpCache nicht korrekt konfiguriert oder zu klein: führt zu häufigen Cache-Evictions.
• PHP-FPM falsch dimensioniert: zu wenige Worker erzeugen Queueing, zu viele erzeugen RAM-Druck.
• Container/VM Limits: CPU throttling und I/O Limits sind häufige „unsichtbare“ Ursachen.

8) Priorisierte Checkliste: Von „sofort“ bis „fortgeschritten“

Phase 1 (1–2 Tage): Sichtbarkeit & Quick Wins

• Prod-nah messen (Lighthouse/WebPageTest) und Baseline dokumentieren.
• Serverseitiges Profiling für 2–3 kritische Seiten (PDP, Kategorie, Checkout).
• HTTP-Cache prüfen: Hit-Rate, Header, falsche No-Cache-Regeln.
• Cache-Strategie: keine pauschalen Cache-Clears, Warmup definieren.
• Third-Party-Skripte inventarisieren und reduzieren.

Phase 2 (1–2 Wochen): Engpässe nachhaltig beheben

• DB Slow Queries analysieren, Indizes ergänzen, N+1 eliminieren.
• Plugin Audit: Subscriber, Queries, External Calls, Cache-Invalidierung.
• OpenSearch/Elasticsearch Monitoring + Slow Logs, Shards/Heap prüfen.
• Worker/Queue stabilisieren, Backlogs verhindern.

Phase 3 (laufend): Performance als Prozess

• Performance Budgets in CI (Lighthouse) und Regression Alerts.
• APM/Monitoring mit SLOs (z. B. 95p TTFB, Error Rate).
• Release-Playbook mit Warmup, Worker-Restart, Reindex-Plan.

9) Typische Bottlenecks aus der Praxis (und wie du sie erkennst)

Symptom: TTFB schwankt stark, besonders nach Deployments. Ursache: kalte Caches, fehlender Warmup, zu aggressive Invalidierung. Nachweis: Cache-Hit-Rate in Logs, Vergleich cold vs. warm.

Symptom: Kategorie- und Suchseiten werden mit wachsendem Katalog exponentiell langsamer. Ursache: teure Facetten/Sortierungen, zu viele Suchanfragen, OpenSearch/ES unterdimensioniert. Nachweis: Slow Logs, Heap/GC, Query-Latenzen.

Symptom: Checkout sporadisch langsam, Timeouts bei Payment/ERP. Ursache: synchrone API-Calls im Request, fehlende Timeouts/Retry-Strategien. Nachweis: Traces im APM, externe Latenzen, Error Logs.

10) Abschluss: So machst du Verbesserungen nachweisbar

Jede Optimierung sollte mit einem Vorher/Nachher belegt werden: gleiche URL, gleiche Bedingungen, dokumentierte Metriken (TTFB, LCP, INP, DB-Zeit, Query-Anzahl, Cache-Hit-Rate). In der Praxis hat sich ein kleines Performance-Dashboard bewährt, das die wichtigsten Seiten regelmäßig testet und Regressionen sichtbar macht.

Wenn du konsequent nach dem Prinzip „messen → priorisieren → optimieren → verifizieren“ vorgehst, lassen sich Ladezeiten in Shopware 6 oft deutlich reduzieren, ohne riskante „Big Bang“-Umbauten. Der größte Hebel liegt meist in sauberem Caching, einem disziplinierten Plugin-Ökosystem und einer Infrastruktur, die Indexierung, Datenbank und Suche stabil trägt.