// Shopware Performance
Ein langsamer Shop kostet Umsatz, vor allem auf dem Handy und im Checkout. Wir suchen die Ursache dort, wo sie wirklich sitzt: im Server, im Cache, in der Suche, in Plugins oder im Theme. Erst messen, dann ändern, dann nachmessen, mit einem Bericht, der Vorher und Nachher zeigt.
// Wo es hakt
Zu wenig Speicher, veraltete PHP-Version, OPcache zu klein, PHP-FPM mit zu wenigen Prozessen. Oft der schnellste Hebel.
HTTP-Cache aus oder ständig ungültig, Cache und Sessions im Dateisystem statt in Redis. Dann rechnet der Shop jede Seite neu.
Bei großen Katalogen ist die Standardsuche über die Datenbank zu langsam. OpenSearch bringt Suche und Filter auf Tempo.
Laufen Warteschlange und geplante Aufgaben über den Admin statt über den Server, bremsen sie jeden Seitenaufruf mit aus.
Zu viele oder schlecht gebaute Plugins laden bei jedem Aufruf Daten, die niemand braucht. Ein Plugin-Audit zeigt, welche sich lohnen.
Große Bilder, unnötiges JavaScript und Drittanbieter-Skripte wie Tracking und Chat-Widgets verschlechtern die Ladezeit im Browser.
Meist ist es nicht eine große Ursache, sondern mehrere kleine. Deshalb prüfen wir alle sechs Stellen.
// Checkliste
Viele Einstellungen, die Shopware in seiner Dokumentation für den Live-Betrieb empfiehlt, sind in bestehenden Shops nie umgesetzt worden. Diese Punkte gehen wir durch:
Läuft der Shop wirklich im Produktivmodus, ohne Debug-Werkzeuge? Im Entwicklungsmodus ist jeder Aufruf spürbar langsamer.
Den Admin-Worker abschalten und Warteschlange sowie geplante Aufgaben als dauerhafte Hintergrundprozesse auf dem Server laufen lassen.
Fertige Seiten aus dem Cache ausliefern und so leeren, dass Preise und Bestände stimmen, ohne den Cache bei jeder Kleinigkeit zu verwerfen.
Cache, Sessions und Zähler im Arbeitsspeicher statt in Dateisystem und Datenbank. Entlastet vor allem bei vielen gleichzeitigen Besuchern.
Suche, Filter und Kategorien über einen eigenen Suchindex, sinnvoll ab größeren Katalogen und vielen Filtern.
Prozesszahlen passend zu Speicher und Last, genug OPcache, auf Wunsch Preloading. Zu wenige Prozesse erzeugen Warteschlangen, zu viele sprengen den Speicher.
Langsame Abfragen finden, Indizes prüfen, aufgeblähte Log- und Hilfstabellen aufräumen, Puffergrößen an den Server anpassen.
Schreibvorgänge, die im Live-Betrieb niemand braucht, etwa Beispieldaten für Mail-Vorlagen, dazu Komprimierung des Caches.
Vorschaubilder in passenden Größen und Formaten, Lazy Loading, Schriften, eigenes JavaScript und Skripte von Drittanbietern, gemessen auf dem Handy.
// Ablauf
Ladezeiten von Startseite, Kategorie, Produktseite und Checkout, dazu Server-Auslastung, langsame Datenbankabfragen und Core Web Vitals.
Profiling zeigt, ob die Zeit im Server, in der Datenbank, in einem Plugin oder im Browser verloren geht.
Zuerst die Änderungen mit dem größten Effekt, jede einzeln und auf einer Kopie getestet, damit klar bleibt, was geholfen hat.
Dieselben Messungen wiederholen. Sie bekommen Vorher und Nachher schwarz auf weiß, dazu eine Liste, was noch möglich wäre.
Nein. Mehr Leistung hilft, wenn der Server tatsächlich am Limit läuft. Oft liegt die Ursache aber in der Konfiguration oder in einem Plugin, und dann ist ein teurerer Tarif nur eine teure Überbrückung. Deshalb messen wir zuerst. Ist der Server die Ursache, übernehmen wir die Einrichtung gleich mit, auf Wunsch als Komplett-Hosting.
Ein vorgeschalteter Cache wie Varnish kann einen Shop enorm beschleunigen, lohnt sich aber vor allem bei viel Verkehr und mehreren Servern. Falsch eingerichtet, liefert er im schlimmsten Fall persönliche Inhalte an fremde Besucher aus, etwa einen Warenkorb oder Kontodaten. Wir setzen solche Lösungen nur ein, wenn Messung und Besucherzahlen sie rechtfertigen, und testen die Regeln für Warenkorb, Konto und Checkout besonders gründlich.
Jedes Plugin kann sich in jeden Seitenaufruf einklinken. Im Plugin-Audit sehen wir, welche Erweiterungen Zeit kosten, welche doppelt dasselbe tun und welche kaum genutzt werden, aber jeden Monat Miete kosten. Oft ist die schnellste Lösung, drei Plugins durch eine schlanke eigene Erweiterung zu ersetzen, die genau das macht, was Ihr Shop braucht.
Gekaufte Themes bringen häufig hunderte Optionen und Skripte mit, von denen nur ein Teil genutzt wird, aber alle geladen werden. Manchmal reicht es, Überflüssiges abzuschalten und Bilder richtig auszuliefern. Wenn nicht, ist ein individuelles Theme auf Basis des Shopware-Standards oft die nachhaltigere Lösung.
Ladezeit ist für Google eines von vielen Signalen. Der größere Effekt liegt meist beim Umsatz: Schnelle Kategorien und ein flüssiger Checkout halten Kunden im Shop. Ein schneller, sauber ausgelieferter Shop wird außerdem von Suchmaschinen und KI-Crawlern besser erfasst, mehr dazu unter SEO.
War der Shop bisher schnell und ist erst seit Kurzem träge, steckt meist ein konkreter Auslöser dahinter, etwa eine gestaute Warteschlange, ein ständig geleerter Cache oder Bots. Erste Schritte dazu stehen unter Shopware plötzlich langsam.
Unser eigener Shop lekoni.de läuft mit über 5.000 konfigurierbaren Produkten auf Shopware 6.7 mit PHP 8.4, eigenem Theme und über 20 eigenen Plugins. Wie sich Server, Cache, Suche und Plugins bei so einem Katalog verhalten, sehen wir jeden Tag selbst. Die Messwerte dafür liefert unter anderem unser Plugin Shop-Analytics ohne Cookies, das Live-Besucher und Conversion direkt im Admin zeigt.
Nach Updates, neuen Plugins oder wachsenden Katalogen wird ein Shop schleichend langsamer. In der laufenden Betreuung prüfen wir die wichtigsten Seiten nach jedem Update, bauen Suchindex und Cache sauber neu auf und schauen regelmäßig auf Warteschlange und Datenbank.
// Kostenloser Website-Check
Der Check misst Ladezeit und Seitengröße, prüft Produktdaten für Google und zeigt, wo Ihr Shop Kunden verliert.
// Performance-Check
Schicken Sie uns die Adresse Ihres Shops. Wir sagen Ihnen nach einem ersten Blick, wo wir die Bremse vermuten und was ein Performance-Check kostet.
// Häufige Fragen
Die häufigsten Ursachen sind ein nicht optimal eingerichteter Server, ein Cache, der nicht greift, Hintergrundaufgaben, die über den Admin laufen, zu viele oder schlecht gebaute Plugins und schwere Bilder oder Skripte im Theme. Oft ist es eine Kombination. Welche Ursache bei Ihnen zutrifft, zeigt erst eine Messung.
Google bewertet eine Seite als gut, wenn der größte sichtbare Inhalt nach höchstens 2,5 Sekunden steht, Eingaben innerhalb von 200 Millisekunden reagieren und sich das Layout kaum verschiebt. Der Server sollte die erste Antwort möglichst unter einer Sekunde liefern, bei gecachten Seiten deutlich schneller.
Redis lohnt sich für fast jeden Shop, weil Cache und Sessions dann im Arbeitsspeicher liegen. OpenSearch lohnt sich vor allem bei größeren Katalogen und vielen Filtern. Bei kleinen Shops reicht die Standardsuche oft aus.
Meist nicht. Der eingebaute HTTP-Cache von Shopware reicht für die meisten Shops. Ein vorgeschalteter Cache wie Varnish lohnt sich bei sehr viel Verkehr oder mehreren Servern und muss sorgfältig eingerichtet werden, damit keine persönlichen Inhalte im Cache landen.
Sie bekommen vorab einen Festpreis, ohne Mindestlaufzeit. Sind größere Umbauten am Server oder an Plugins nötig, schätzen wir das nach der Messung separat.
Einen kurzen Bericht mit den Messwerten vorher und nachher, den umgesetzten Änderungen und einer Liste, was sich darüber hinaus noch lohnen würde.
Einen ersten Eindruck gibt Google PageSpeed Insights. Das misst allerdings nur den Browser-Teil einer einzelnen Seite. Wo die Zeit auf dem Server verloren geht, zeigt erst ein Blick auf Server, Datenbank und Plugins.
Das kann passieren, vor allem bei gekauften Themes mit sehr vielen Optionen und Skripten. Ein schlankes, individuelles Theme auf Basis des Shopware-Standards lädt meist deutlich weniger.
Die Storefront wird aus dem Cache ausgeliefert, die Administration nicht. Langsam wird sie vor allem, wenn der Admin-Worker die Warteschlange im Browser abarbeitet, wenn mehrere Mitarbeiter gleichzeitig eingeloggt sind, bei sehr großen Listen oder durch Plugins, die sich in den Admin einklinken.
Oft ja, neue Versionen bringen regelmäßig Verbesserungen an Leistung und Caching. Ob es bei Ihnen spürbar wird, hängen Plugins, Theme und Server mit. Deshalb messen wir vor und nach dem Update.
Shopware 6.7 verlangt mindestens PHP 8.2. Neuere PHP-Versionen sind in der Regel schneller, unser eigener Shop läuft auf PHP 8.4. Vor dem Wechsel prüfen wir, ob alle Plugins die neue Version unterstützen.
Eine feste Grenze gibt es nicht. Entscheidend ist, wie die Plugins gebaut sind und ob sie sich unnötig in jeden Seitenaufruf einklinken. Unsere eigenen Shops laufen mit über 20 eigenen Plugins. Ein einziges schlecht gebautes Plugin kann mehr bremsen als zwanzig schlanke.
Ein CDN beschleunigt vor allem Bilder und statische Dateien, besonders bei Besuchern aus dem Ausland. Liegt die Bremse im Server, in der Datenbank oder in Plugins, ändert es daran nichts. Bei deutschen Shops ist die Server-Einrichtung meist der größere Hebel.