1. Warum Performance bei Shopware Geld ist
Bei E-Commerce-Shops zahlt sich jede Sekunde Ladezeit direkt aus. Der Zusammenhang zwischen Mobile-LCP und Conversion-Rate ist bei Shopware-Shops in jedem Mandat reproduzierbar: zwischen 1,5 s und 3 s LCP gehen typischerweise 30–50 % der mobilen Conversion verloren. Über 3 s gehen viele Besucher gar nicht erst in den Funnel.
Konkrete Zahlen aus einem dokumentierten Mandat (D2C-Hersteller-Shop, mehrsprachig): nach Fix eines kritischen CSS-Bugs unter Firefox 121+ und einer Buy-Box-Überarbeitung stieg die Ø-Verweildauer auf Produktseiten in den ersten Wochen um rund 49 %, die Bounce-Rate fiel um etwa 4 %, der bereinigte Umsatz pro Tag um rund 60 %. Kein Magie-Tool — Diagnose, Reparatur, Live.
Faustregel
Jede Sekunde, die Sie an LCP einsparen, ist im Mittel 5–10 % mehr Mobile-Conversion. Bei großen Shops sind das fünf- bis sechsstellige Beträge pro Jahr.
2. Diagnose: Wo klemmt es wirklich?
Bevor Sie eine Zeile Code anfassen, brauchen Sie eine ehrliche Diagnose. Lab-Tools (Lighthouse, PageSpeed Insights) zeigen Ihnen, was theoretisch möglich ist. Field-Daten (Chrome UX Report, RUM) zeigen, was Ihre echten Kunden auf echten Geräten erleben. Beides nutzen, Field als finalen Maßstab.
Typische Befunde im Initial-Audit eines Shopware-Shops:
- Bilder unoptimiert — JPG statt AVIF/WebP, keine responsive srcsets, kein Lazy-Loading
- Theme-JS-Bundle zu groß — alle Module sync geladen, kein Code-Splitting
- Datenbank-Queries pro Listing-Item — N+1-Patterns in Produktlisten
- Kein HTTP-Cache für anonyme Besucher
- Third-Party-Tracker im kritischen Pfad — Tag Manager blockt das Rendering
Der Shop-Audit (990 €) liefert genau diese Liste mit Priorisierung und groben Aufwand-Schätzungen pro Maßnahme.
3. Bilder — der größte Hebel
Bilder machen typischerweise 60–80 % des Above-the-Fold-Payloads aus. Eine konsequente Bild-Pipeline ist der Hebel mit dem besten Aufwand-Effekt-Verhältnis bei Shopware-Performance.
Was funktioniert
- AVIF + WebP als Hauptformat, JPG als Fallback. Shopware 6 unterstützt das nativ über die Thumbnail-Konfiguration.
- Responsive srcsets mit echten Image-Breitpoints — 320, 640, 768, 1024, 1280, 1920 als Standard-Set.
- Hero-Bild mit `priority` bzw. `loading="eager"` und `fetchpriority="high"` — alle anderen Bilder mit `loading="lazy"`.
- Width + Height immer setzen, um CLS zu vermeiden. Aspect-Ratio-Boxen für variable Bildgrößen.
Anti-Patterns
Verbreitete Fehler, die ich in fast jedem Audit sehe: ein 4 MB Hero-JPG ungeskaliert ausgespielt; alle Galerie-Bilder eager geladen; Hero-Bild als Background-Image ohne Browser-Hint; CDN ohne korrekte Cache-Header.
4. Caching-Schichten richtig setzen
Caching bei Shopware funktioniert in mehreren Schichten. Jede Schicht spart Last und Latenz an einer anderen Stelle. Wer eine Schicht weglässt, holt sich Last in eine andere.
HTTP-Cache (Reverse Proxy / CDN)
Anonyme Besucher bekommen gecachte HTML-Seiten ausgeliefert. Bei Shopware via Symfony HTTP Cache oder einem vorgelagerten Reverse-Proxy (Nginx, Varnish). Die meisten Hosting-Provider haben das vorkonfiguriert — Konfiguration im hosting-Panel oder per `.htaccess` prüfen.
Application-Cache (Redis)
DAL-Queries, Konfigurations-Werte, Berechnungen und Sessions landen im Redis. Wichtig: Cache-Keys versionieren, damit Updates keine stale Daten ausliefern. Bei Shopware 6 ist Redis-Setup über die `.env` und `cache.yaml` Standard.
Asset-Cache (Browser)
CSS, JS, Bilder mit langer Browser-Cache-Lifetime (1 Jahr) und Hash-basierten Filenames. Shopware 6 macht das mit dem `theme:compile` automatisch — nur sicherstellen, dass die Cache-Header von CDN/Hosting korrekt durchgereicht werden.
Optional: Varnish
Bei hohem Traffic mit vielen ähnlichen Page-Views (Kategorie-Pages, Produktdetail-Seiten) lohnt sich Varnish vor Shopware. Konfigurations- und Wartungs-intensiv, aber kann Server-Last halbieren bis dritteln.
5. Datenbank-Queries und DAL-Patterns
Bei Shopware 6 läuft fast alles über die DAL (Data Abstraction Layer). Sauber genutzt ist sie schnell — falsch genutzt kann sie der Bottleneck werden.
Was funktioniert
- Associations explizit laden mit `addAssociation()`. Sonst werden sie pro Item nachgeladen (N+1).
- Listing-Endpoints schlank halten — nur Felder laden, die die Card zeigt (slug, Titel, Preis-Bracket, Listing-Bild).
- Elasticsearch für Filter und Suche ab ~50.000 Artikeln Pflicht. Filter-Counts werden mit dem Listing geliefert, nicht in separaten Queries.
- Kundengruppen-Preise cachen in Redis pro Gruppen-Hash. Die ändern sich selten und sind deterministisch.
In einem dokumentierten B2B-Mandat (250.000 Artikel) wurde die Kategorie-Ladezeit von 6,2 s auf 1,3 s gedrückt — primär durch Listing-Endpoint-Schlankheit und Elasticsearch-Aggregations. Details unter /werk/b2b-katalog-performance/.
6. Theme-Refactor und JavaScript-Diät
Das Standard-Shopware-Theme ist breit, weil es alle Use-Cases abdecken muss. In den meisten Shops braucht es nur einen Bruchteil der Module — die anderen blockieren das Rendering ohne Gegenwert.
Was zu tun ist
- JavaScript-Diät — Module, die nicht gebraucht werden, aus dem Bundle nehmen. Above-the-Fold-irrelevante Module lazy laden.
- Critical CSS für Above-the-Fold inline, Rest asynchron laden.
- Third-Party-Tracker aus dem kritischen Pfad. Tag Manager mit `async` laden, idealerweise erst nach `load`.
- Web Fonts mit `font-display: swap` und Preload für die kritischen.
7. Wann Headless mit Next.js
Headless wird im E-Commerce viel diskutiert. Die Wahrheit: für die meisten Shopware-Shops macht es keinen Sinn — ein gut sanierter klassischer Storefront ist wirtschaftlicher.
Headless lohnt sich konkret, wenn:
- Sie ein eigenes Markenerlebnis mit komplexer UI bauen wollen, das das Twig-Theme nicht hergibt.
- Sie Lighthouse 90+ Mobile als Geschäfts-KPI verfolgen — bei sehr starkem Mobile-Anteil.
- Sie ein unabhängiges Storefront-Team haben, das deployen will, ohne auf das Shop-Backend zu warten.
In einem dokumentierten Mandat (Textil-Marke, 7-stelliger Umsatz, 78 % Mobile) wurde die Lighthouse Performance Mobile durch Headless-Refactor von 44 auf 92 gehoben. Mobile-Conversion stieg von 1,1 % auf 2,4 %. Details unter /werk/performance-headless-textil/.
Warnung
Headless verdoppelt die Wartungslast — Sie haben ab dann zwei Codebases (Shopware + Frontend). Wenn Ihr Team nicht für laufende Frontend-Pflege aufgestellt ist, ist klassisches Storefront sicherer.
8. Die richtige Reihenfolge
Performance-Optimierung in der falschen Reihenfolge verbrennt Budget. Aus Erfahrung die wirtschaftlichste Sequenz:
- Diagnose-Audit — wo klemmt es wirklich? Lab + Field-Daten. (~5 Werktage, 990 €)
- Bild-Pipeline — AVIF/WebP, responsive srcsets, Lazy-Loading. (~1–2 Tage Arbeit, 30–50 % LCP-Gewinn)
- HTTP-Cache + Redis — Hosting-Konfiguration und Application-Cache. (~1 Tag, halbiert Server-Last)
- Theme-JS-Diät — unbenutzte Module raus, Code-Splitting. (~2–3 Tage)
- DB-Patterns — N+1-Killer, Listing-Endpoints schlank, ggf. Elasticsearch. (~3–5 Tage)
- Optional Headless — wenn nach Schritten 1–5 immer noch nicht genug.
In den meisten Shops bringen die Schritte 2–4 schon 70–80 % des erreichbaren Performance-Gewinns. Schritt 5 ist der Feinschliff, Schritt 6 die strategische Investition.
9. Häufige Fragen
Welche LCP-Werte sind für Shopware-Shops realistisch?
Mobile p75 unter 2,5 Sekunden ist gut, unter 1,5 Sekunden ist hervorragend. In dokumentierten Mandaten habe ich klassische Shopware-Storefronts auf 1,6 s und Headless-Storefronts auf 1,4 s gebracht. Wer mit 3 s oder mehr lebt, lässt typischerweise 30–50 % der mobilen Conversion liegen.
Lohnt sich Varnish vor Shopware?
Bei hohem Traffic mit vielen ähnlichen Page-Views ja, vor allem für Kategorie-Pages und Produktdetail-Seiten. Bei kleineren Shops reicht oft HTTP-Caching im Hosting plus aggressiver Redis-Cache im Anwendungsstack. Varnish ist mächtig, aber Konfigurations- und Wartungs-intensiv — nicht für jeden Shop wirtschaftlich.
Wann ist Headless mit Next.js sinnvoll, wann nicht?
Headless lohnt sich, wenn (1) Sie ein eigenes Markenerlebnis mit komplexer UI bauen, (2) Lighthouse 90+ Mobile als Geschäfts-KPI haben, oder (3) Storefront-Team unabhängig vom Shop-Backend deployen können soll. Bei kleineren Shops ist ein gut sanierter klassischer Shopware-Storefront wirtschaftlicher.
Was bringt eine reine Bild-Optimierung?
Bei nicht-optimierten Produktbildern kann die Umstellung auf AVIF/WebP mit responsive srcsets allein 1,5–2 Sekunden LCP einsparen. Im Schnitt machen Produktbilder 60–80 % des kritischen Above-the-Fold-Payloads aus.
Welche Caching-Strategien sind Standard bei Shopware 6?
(1) HTTP-Cache auf Reverse-Proxy-Ebene für anonyme Besucher. (2) Redis-Cache für DAL-Queries und Sessions. (3) Asset-Cache mit langer Browser-Cache-Lifetime und Hash-basierten Filenames. (4) Optional Varnish für Hochlast-Shops. Jede Schicht spart Last und Latenz an einer anderen Stelle.
Wie messe ich Performance richtig?
Lab-Daten (Lighthouse) sind gut für Verbesserungs-Iterationen während der Arbeit. Field-Daten (Chrome UX Report, Real-User-Monitoring) sind entscheidend für Business-Wirkung — sie zeigen, was Ihre echten Kunden auf echten Geräten erleben. Beide Quellen nutzen, Field-Daten als finalen Maßstab.
Konkretes Performance-Problem?
Im Shop-Audit (990 €, 5 Werktage) bekommen Sie genau diese Liste priorisiert für Ihren Shop — mit echten Aufwand-Schätzungen und Reihenfolge. Bei Beauftragung eines Folge-Mandats voll anrechenbar.