Shopware-Performance optimieren: Code-Fix, Infrastruktur oder Caching?

Die kurze Antwort

Wer die Shopware-Performance optimieren und die Ladezeit verbessern will, sollte mit der Frage starten, wo der Engpass liegt, und erst danach Maßnahmen auswählen. Danach gibt es drei Hebel: den Code-Fix, der die Ursache behebt, die Infrastruktur, die bei Einbrüchen und Lastspitzen am schnellsten hilft, und das Caching, das fertige Seiten ausliefert, aber seltener die eigentliche Lösung ist, als viele denken. Oft ist es eine Kombination.

Wie kann ich die Performance meines Shopware-Shops verbessern?

Indem du zuerst misst und dann gezielt den passenden Hebel wählst. Viele Performance-Ratgeber listen Maßnahmen nebeneinander auf, als würde jede bei jedem Shop gleich viel bringen. In der Praxis hängt alles vom Engpass ab: Ein langsamer Datenimport braucht eine andere Lösung als ein Shop, der bei jeder Kampagne einbricht, oder als Seiten, die nur für eingeloggte B2B-Kunden träge sind.

Dieser Artikel ordnet die Maßnahmen deshalb als Entscheidung ein. Zuerst geht es darum, ob überhaupt ein Performance-Problem vorliegt und wo es sitzt. Danach folgen die drei Hebel Code-Fix, Infrastruktur und Caching, jeweils mit dem Fall, in dem sie am meisten bringen. Am Ende stehen die Tipps, die in der Praxis wenig bewirken, obwohl sie oft als Erstes empfohlen werden.

Woran erkenne ich, ob mein Shop wirklich ein Performance-Problem hat?

An echten Nutzerdaten und an Mustern, nicht an einem einzelnen Testwert. Typische Signale sind Seiten, die für Besucher spürbar langsam laden, ein Checkout, der unter Last hängt, Backend-Prozesse wie Importe oder Indexierung, die immer länger dauern, und ein Shop, der bei Kampagnen oder zu Spitzenzeiten einbricht. Ein schwacher PageSpeed-Wert allein ist noch kein Beleg für ein echtes Problem.

Entscheidend ist, ob deine Kunden die Langsamkeit spüren. Google PageSpeed Insights unterscheidet dafür selbst zwischen Labordaten, die Lighthouse in einer kontrollierten Simulation erzeugt, und Felddaten von echten Nutzern. Labordaten helfen beim Debuggen, bilden reale Engpässe aber nicht unbedingt ab. Wenn deine Felddaten gut sind und nur der Laborwert schwach ist, sieht dein Score schlechter aus als die Realität, und ein dringendes Problem hast du wahrscheinlich nicht.

Wie finde ich heraus, wo der Engpass liegt?

Mit Profiling. Ein Profiler misst, wie viel Zeit ein Seitenaufruf oder Prozess in welchem Teil des Systems verbringt: in Datenbankabfragen, im PHP-Code einzelner Plugins, in externen Schnittstellen oder im Seitenaufbau. Erst damit wird sichtbar, ob das Problem im Code, in der Infrastruktur oder in fehlendem Caching liegt. Ohne diese Messung bleibt jede Maßnahme ein Schuss ins Blaue.

Welcher Hebel greift, lässt sich ohne tiefes Verständnis des Systems und ohne diese Messung nicht seriös entscheiden. Manche Hoster bringen Profiling-Werkzeuge direkt mit. Wo das nicht der Fall ist, lässt sich das Problem lokal nachstellen und dort analysieren. Für Lasttests verweist Shopware selbst auf Werkzeuge wie k6 oder Locust und betont, dass sich generische Benchmarks selten auf individuell angepasste Projekte übertragen lassen. Genau deshalb lohnt der Blick auf den eigenen Shop statt auf allgemeine Vergleichswerte.

Code-Fix, Infrastruktur oder Caching: Welcher Hebel hilft wann?

Das hängt vom Symptom ab. Ein Code-Fix ist richtig, wenn ein konkreter Prozess ineffizient ist. Mehr Infrastruktur ist der schnellste Hebel, wenn der Shop regelmäßig einbricht oder ein Ansturm bevorsteht. Caching hilft vor allem bei vielen gleichen Seitenaufrufen nicht eingeloggter Besucher. Bei den Performance-Problemen, die unser Shopware-Team analysiert, ist Caching in den wenigsten Fällen die eigentliche Lösung.

Wann ist ein Code-Fix der richtige Weg?

Wenn das Profiling zeigt, dass ein bestimmter Ablauf zu viel Zeit oder zu viele Ressourcen braucht, etwa eine ineffiziente Datenbankabfrage in einem Plugin, eine Schnittstelle, die bei jedem Seitenaufruf abgefragt wird, oder ein Import, der alles auf einmal verarbeitet. Ein Code-Fix behebt die Ursache, statt sie mit mehr Leistung zu überdecken, und spart dauerhaft Hosting-Kosten.

Unsere Entwickler tendieren fast immer zum Code-Fix, weil mehr Serverleistung ein ineffizientes System nur überdeckt: Die Last wächst weiter, und mit ihr die Hosting-Rechnung. Der Code-Fix braucht dafür mehr Zeit für Analyse und Umsetzung. Deshalb ist er bei akuten Einbrüchen selten der erste, aber fast immer der zweite Schritt.

Wann hilft mehr Hosting-Leistung, und wie skaliert man richtig?

Mehr Infrastruktur ist der schnellste Hebel, wenn der Shop regelmäßig einbricht oder ein Ansturm bevorsteht. Unser Shopware-Team skaliert in solchen Fällen zuerst hoch, um den Shop zu stabilisieren, sucht danach die Ursache und fährt die Infrastruktur wieder zurück, sobald sie behoben ist. Vor einem planbaren Ansturm wie einer großen Kampagne wird vorab hochskaliert.

Dabei gibt es zwei Wege. Vertikal skalieren heißt, einem Server mehr CPU-Kerne und Arbeitsspeicher zu geben. Das ist einfach, stößt aber irgendwann an eine Grenze. Horizontal skalieren heißt, weitere App-Server danebenzustellen. Das ist teurer und aufwendiger im Betrieb, lässt sich aber fast beliebig erweitern. Die meisten Shops, die unser Shopware-Team betreut, lasten ihre Infrastruktur im Regelbetrieb gar nicht aus. Mehr Leistung überbrückt deshalb meist nur die Zeit, bis die Ursache behoben ist. Die Vor- und Nachteile beider Wege vertieft unser Artikel zu horizontaler und vertikaler Skalierung, wie zwei Hoster das umsetzen, zeigt unser Hosting-Vergleich.

Was bringt Caching in Shopware, und wo stößt es an Grenzen?

Caching speichert fertige Ergebnisse zwischen, damit Shopware sie nicht bei jedem Aufruf neu berechnen muss. Laut Shopware-Dokumentation ist der HTTP-Cache ein Muss für jedes Produktivsystem. Er bringt am meisten bei vielen gleichen Seitenaufrufen, etwa auf Kategorie- und Produktseiten für nicht eingeloggte Besucher.

Die Grenze liegt genau dort, wo viele Shops im Mittelstand ihr Geschäft machen. Für eingeloggte Kunden oder sobald Produkte im Warenkorb liegen, liefert Shopware standardmäßig keine kompletten Seiten mehr aus dem Cache, weil sich Inhalte wie Preise je Kunde unterscheiden können. So steht es in den Shopware Performance Tweaks. In einem B2B-Shop, in dem fast alle Kunden eingeloggt bestellen, hilft der Seiten-Cache deshalb deutlich weniger als in einem B2C-Shop mit vielen anonymen Besuchern. Dort sind schnelle Datenbankabfragen, Redis und effizienter Code die wichtigeren Hebel.

Was bringen Redis, Reverse Proxy und Message Queue konkret?

Alle drei entlasten den Shop an einer anderen Stelle. Redis hält häufig gelesene Daten wie Cache, Sessions und Warenkörbe im Arbeitsspeicher und entlastet die Datenbank. Ein Reverse Proxy wie Varnish liefert fertige Seiten aus, ohne dass Shopware sie neu berechnet. Eine Message Queue verlagert Aufgaben wie den Mailversand in den Hintergrund, damit sie Seitenaufrufe nicht bremsen.

• Redis: Die Altfassung dieses Artikels empfahl bereits, Cache und Sessions vom Dateisystem auf Redis zu verlagern. Das gilt weiterhin. In übernommenen Setups ist Redis allerdings oft angelegt, aber nicht aktiv. Wie du das prüfst, steht in unserem Artikel über die häufigsten Fehler in übernommenen Shopware-Setups.
• Reverse Proxy: Bei mehreren App-Servern empfiehlt Shopware einen Reverse-Proxy-Cache wie Varnish. Unser Shopware-Team hat nach der Aktivierung in einem Projekt einen deutlichen Unterschied gemerkt, weil die Berechnung der Seite für viele Aufrufe komplett entfällt.
• Message Queue: Shopware versendet Mails laut Dokumentation standardmäßig synchron, was die Seitengeschwindigkeit beeinträchtigen kann. Über die Message Queue mit eigenen Worker-Prozessen statt dem Admin-Worker laufen solche Aufgaben im Hintergrund, auch wenn niemand im Backend eingeloggt ist.

Wie diese Bausteine in ein Gesamt-Setup passen, beschreibt unser Überblick Was macht ein gutes Shopware-Setup aus?

Welche Performance-Tipps bringen in der Praxis wenig?

Vor allem Tipps, die einen Messwert verbessern, aber nicht das Erlebnis der Kunden. Dazu gehört der Versuch, ungenutztes CSS und JavaScript aus einem Framework wie Shopware vollständig zu entfernen. Dazu gehören viele automatisierte Empfehlungen, die mit großem Aufwand wenig bewirken. Und dazu gehören Optimierungen mit Nebenwirkungen, deren Effekt im einstelligen Prozentbereich liegt.

Wer mit einem Framework wie Shopware arbeitet, lebt mit einem gewissen Overhead. Eine komplett selbst geschriebene Seite, die zu 100 % auf Performance getrimmt ist, wäre schneller, hätte aber in Wartung, Erweiterbarkeit und Kosten viele andere Nachteile. Ein Beispiel für kleine Effekte mit Nebenwirkungen nennt Shopware selbst: Ein OPcache-Preload bringt laut den Performance Tweaks zusätzlich nur etwa 2 bis 5 %, verlangt aber bei jedem Cache-Clear einen Neustart von PHP-FPM. Gravierende Performance-Probleme haben in den Shops, die wir analysieren, meist andere Ursachen als das Frontend, etwa langsame Datenbankabfragen oder fehlende Hintergrundverarbeitung.

Schlanke, komprimierte Bilder und Lazy Loading bleiben dagegen sinnvoll. Sie gehören zur Basishygiene. Einem Shop, der unter Last einbricht, helfen sie nicht.

Wie aussagekräftig sind PageSpeed- und Lighthouse-Werte?

Für das Debugging sind sie nützlich, als alleiniges Ziel taugen sie wenig. Lighthouse misst in einer kontrollierten Simulation, nicht bei deinen echten Kunden. Google weist selbst darauf hin, dass Labordaten reale Engpässe nicht unbedingt abbilden. Aussagekräftiger sind die Felddaten echter Nutzer, die PageSpeed Insights zusätzlich anzeigt.

Wer stur jede Empfehlung umsetzt, um 100 Punkte zu erreichen, kann die real gemessene Performance sogar verschlechtern. Ein Beispiel aus früheren Projekten unseres Teams: Lighthouse empfahl, ein externes Analyse-Skript selbst zu hosten, weil sich dessen Caching-Header nicht anpassen ließ. Selbst gehostet musste jeder Besucher das Skript neu laden, statt eine bereits im Browser vorhandene Version zu nutzen. Entscheidend ist, wie schnell der Shop für deine Kunden lädt und ob der Checkout auch unter Last funktioniert.

Was hat Shopware 6.7 an der Performance verbessert?

Laut dem Shopware 6.7 Performance Report hat Shopware die Versionen 6.6 und 6.7 unter identischen Bedingungen verglichen. Nach Herstellerangabe verarbeitet 6.7 im Flash-Sale-Szenario mit aktivem Caching 108 % mehr Bestellungen pro Sekunde und reduziert die Latenz bei gleichzeitiger API-Last um bis zu 85 %. Der Report nennt dafür unter anderem bessere Cache-Nutzung, asynchrone Verarbeitung und Valkey statt Redis. Valkey ist ein Redis-kompatibler Open-Source-Fork, die Hinweise zu Redis weiter oben gelten deshalb genauso.

Für dich heißt das: Ein Update auf die aktuelle Version kann selbst ein spürbarer Performance-Hebel sein, bevor du in zusätzliche Infrastruktur investierst. Herstellerwerte aus Testumgebungen lassen sich aber nicht eins zu eins auf einen individuell angepassten Shop übertragen. Ob und wie stark dein Shop profitiert, hängt von Plugins, Anpassungen und Datenmenge ab. Auch hier hilft ein Lasttest vor und nach dem Update mehr als jede Pauschalaussage. Diesen Lasttest fährst du am besten auf einem Staging-System, das dem Live-Shop entspricht. Wie du Staging und Live sauber im Gleichstand hältst, zeigt unser Artikel zur Deployment-Hygiene. Was Performance-Arbeit, Updates und Skalierung im laufenden Betrieb kosten, zeigt unsere Übersicht zu den Shopware-Kosten.

Wie wir dich unterstützen können

Wir bei datrycs finden zuerst heraus, wo dein Shop wirklich Zeit verliert, und wählen dann den Hebel, der das Problem behebt, statt es nur zu überdecken. Wenn dein Shop unter Last einbricht oder für deine Kunden spürbar langsam ist, sprich uns über das Kontaktformular am Ende dieser Seite an.