Shopware 6 Performance-Boost: Das volle Potenzial Ihres Shops entfesseln

Warum Geschwindigkeit im Shop zählt

Langsame Ladezeiten kosten Umsatz. Wer warten muss, springt eher ab und kauft seltener. Gleichzeitig fliesst die Ladegeschwindigkeit über die Core Web Vitals in das Google-Ranking ein: Ein langsamer Shop verliert also nicht nur Kundinnen und Kunden im Shop, sondern auch Besucher aus der Suche.

Performance ist deshalb keine reine IT-Aufgabe, sondern betrifft Marketing, Vertrieb und Kundenbindung gleichermassen. Die gute Nachricht: Shopware 6 ist nicht von Natur aus langsam. Ob ein Shop schnell ist, hängt vor allem von Konfiguration, Infrastruktur und der Qualität von Plugins und eigenem Code ab. Dieser Artikel zeigt, wo Sie ansetzen können.

Ausgangslage messen

Optimieren Sie nie ins Blaue. Ein Performance-Audit zu Beginn zeigt, wo die Engpässe tatsächlich liegen, und liefert die Basis, um den Erfolg jeder Massnahme zu messen.

Tools für den Einstieg

Für das Frontend eignen sich Google PageSpeed Insights, Lighthouse in den Chrome DevTools, WebPageTest und GTmetrix. Sie messen Ladezeit, Time to First Byte (TTFB) und die Core Web Vitals. Für das Backend liefern APM-Tools wie Tideways oder New Relic erste Hinweise auf serverseitige Verzögerungen (mehr dazu im Abschnitt zum Monitoring).

Die wichtigsten Kennzahlen

• Largest Contentful Paint (LCP): Wann ist der grösste sichtbare Inhalt geladen?
• Interaction to Next Paint (INP): Wie schnell reagiert die Seite auf Eingaben? INP hat 2024 den früheren Wert First Input Delay (FID) abgelöst.
• Cumulative Layout Shift (CLS): Wie stark springt das Layout beim Laden?
• Time to First Byte (TTFB): Wie schnell antwortet der Server? Ein hoher TTFB-Wert zieht alle anderen Werte nach unten.

Benchmarks: Wo steht Ihr Shop?

Eine Ladezeit von 900 ms sagt für sich allein wenig aus. Hilfreich ist der Vergleich mit anderen Shops. Tideways hat dazu im ersten Quartal 2025 anonymisierte Antwortzeiten von über 150 Shopware-6-Shops ausgewertet. Die Spanne ist gross: Die schnellsten 10 % («Top 10 %») antworten auf Produktseiten im Schnitt in rund 300 ms, die langsamsten 10 % («Letzte 10 %») brauchen das Fünffache.

Durchschnittliche Antwortzeiten in ms (Tideways, Q1 2025)

95. Perzentil der Antwortzeiten in ms (Tideways, Q1 2025)

So lesen Sie die Tabellen:

• Einordnung: Vergleichen Sie Ihre eigenen Messwerte je Seitentyp. Liegt Ihr Shop im unteren Bereich, ist das Verbesserungspotenzial meist erheblich.
• Prioritäten: Produkt- und Kategorieseiten entscheiden über den Umsatz. Sind gerade sie langsam, gehören sie zuoberst auf die Liste.
• Auswirkung auf SEO: Die Server-Antwortzeit ist Teil des LCP. Ab 2,5 Sekunden stuft Google den LCP als verbesserungswürdig ein – eine langsame Antwort des Backends macht diesen Wert schnell unerreichbar.

Die grossen Unterschiede zeigen vor allem eines: Gute Performance ergibt sich nicht von selbst. Viele Shops verschenken Geschwindigkeit, weil Setup und Engpässe nie genauer untersucht wurden.

Server und Infrastruktur

PHP-Version und Konfiguration

Setzen Sie die neueste PHP-Version ein, die Ihre Shopware-Version offiziell unterstützt. Neue PHP-Versionen bringen regelmässig Leistungsverbesserungen und Sicherheitsupdates. Welche Versionen passen, steht in den Systemanforderungen der jeweiligen Shopware-Version.

Das gilt auch für Shopware selbst: Neuere Versionen enthalten Performance-Verbesserungen, die ältere nicht bekommen. Aktuell ist Shopware 6.7; für Shopware 6.5 endet der Sicherheitssupport voraussichtlich am 28.02.2027. Wenn Sie noch auf einer älteren Version arbeiten, lohnt sich ein Upgrade auf Shopware 6.7 doppelt.

Für die PHP-Konfiguration gilt:

• PHP-FPM verwenden. Der FastCGI Process Manager verwaltet PHP-Prozesse deutlich effizienter als ältere Server-Module.
• Bytecode-Cache aktivieren: OPcache (Zend OPcache) mit mindestens 256 MB Speicher, dazu APCu mit mindestens 128 MB. Vorkompilierter Code liegt dann im Arbeitsspeicher und muss nicht bei jeder Anfrage neu übersetzt werden.
• Grenzwerte: memory_limit auf mindestens 512 MB und max_execution_time auf mindestens 30 Sekunden setzen, damit aufwendige Vorgänge nicht abbrechen.

Webserver

Shopware läuft mit Apache 2.4 (mit mod_rewrite) und mit NGINX. NGINX arbeitet ereignisgesteuert und verarbeitet viele gleichzeitige Verbindungen ressourcenschonender. Für stark frequentierte Shops ist er deshalb oft die bessere Wahl.

Aktivieren Sie in jedem Fall die Komprimierung auf dem Webserver (Brotli oder gzip). Das reduziert die übertragene Datenmenge spürbar.

Redis für Cache, Sessions und Warenkörbe

Redis speichert Daten im Arbeitsspeicher und gehört zu jeder leistungsfähigen Shopware-Installation. Es entlastet die Datenbank, weil häufig benötigte Daten direkt aus dem RAM kommen.

Der HTTP-Cache von Shopware wird über die .env gesteuert:

SHOPWARE_HTTP_CACHE_ENABLED=1
SHOPWARE_HTTP_DEFAULT_TTL=7200

Den Cache-Adapter legen Sie anschliessend in config/packages/shopware.yaml bzw. in der Framework-Konfiguration auf Redis fest. Auch Sessions lassen sich nach Redis auslagern, was Login und Warenkorb beschleunigt.

Ab Shopware 6.6.8.0 können Sie mehrere Redis-Verbindungen definieren. Trennen Sie dabei die Daten nach Art:

• Cache (flüchtig, darf jederzeit verdrängt werden), z.B. Datenbank /0
• Sessions (sollen bestehen bleiben, dürfen aber altern), z.B. /1
• Kritische Daten wie Warenkörbe und Nummernkreise (dürfen nie verloren gehen), z.B. /2

So verhindern Sie, dass eine aggressive Verdrängungsstrategie im Cache wichtige Daten löscht. Bei viel Verkehr reduzieren persistente Verbindungen (?persistent=1 in der Redis-DSN) den Aufwand für den Verbindungsaufbau.

Ändern sich Warenbestände sehr häufig, lohnt sich zudem die verzögerte Cache-Invalidierung über Redis: Shopware sammelt die Invalidierungen und arbeitet sie im Hintergrund ab, statt bei jeder Änderung sofort den Cache zu leeren und damit MySQL zu belasten.

Leeren und aufwärmen Sie den Cache nach Konfigurationsänderungen:

bin/console cache:clear
bin/console cache:warmup

Reverse Proxy und CDN

Ein Reverse Proxy wie Varnish oder Fastly liefert ganze Seiten für nicht angemeldete Besucher aus dem Cache, ohne dass PHP überhaupt arbeiten muss. Ein CDN verteilt statische Dateien (Bilder, CSS, JavaScript) über ein weltweites Servernetz und liefert sie vom nächstgelegenen Standort aus. Shopware 6 unterstützt externe Speicher wie AWS S3 für Medien und Assets, die sich gut hinter ein CDN stellen lassen.

Genügend Ressourcen

Software-Optimierung ersetzt keine ausreichende Hardware. Die Leistung von Shopware skaliert mit CPU und Arbeitsspeicher. Kleine Shops kommen mit einem gut abgestimmten, bescheidenen Hosting aus; stark frequentierte Shops brauchen genügend RAM und CPU. Ab einer gewissen Grösse lohnt sich ein eigener Datenbankserver, damit Webserver und Datenbank nicht um Ressourcen konkurrieren.

Caching als Gesamtsystem

Bei Shopware greifen mehrere Cache-Ebenen ineinander: Bytecode-Cache (OPcache/APCu), der HTTP-Cache von Shopware, Redis für Objekte, Sessions und Queues, ein Reverse Proxy für ganze Seiten und das Browser-Caching für statische Dateien. Es geht nicht darum, sich für eine Ebene zu entscheiden – sie müssen zusammenspielen.

In der Praxis sehen wir häufig, dass Caching zwar «eingeschaltet» ist, aber falsch konfiguriert oder lückenhaft. Dann wird der Cache umgangen, die Last landet wieder beim Backend, und andere Optimierungen verpuffen. Prüfen Sie deshalb gezielt, welche Anfragen tatsächlich aus dem Cache kommen.

Datenbank

MySQL oder MariaDB

Shopware unterstützt MySQL und MariaDB, empfiehlt für die beste Leistung aber MySQL – vor allem, wenn keine Suchmaschine wie Elasticsearch oder OpenSearch im Einsatz ist. Grund sind die JSON-Felder, die Shopware verwendet: MySQL filtert, sortiert und aggregiert diese effizienter. Einzelne Versionen sind wegen bekannter Fehler ausgenommen (z.B. MySQL 8.0.20 und 8.0.21 sowie MariaDB 10.11.5 und 11.0.3). Prüfen Sie die aktuellen Systemanforderungen Ihrer Shopware-Version.

Zwei Einstellungen lohnen sich:

• max_allowed_packet auf mindestens 32 MB setzen.
• Ist Ihr MySQL-Server bereits korrekt konfiguriert, können Sie mit SQL_SET_DEFAULT_SESSION_VARIABLES=0 in der .env verhindern, dass Shopware bei jeder Anfrage Session-Variablen setzt. Das spart Overhead.

Indizes und Abfragen

Datenbankindizes funktionieren wie das Stichwortverzeichnis eines Buches: Die Datenbank findet Daten, ohne jede Zeile durchsuchen zu müssen. Fehlen passende Indizes, werden Suche, Filter und Sortierung langsam.

Ein verbreitetes Problem ist die N+1-Abfrage: Der Code lädt zuerst eine Liste von Datensätzen und stellt dann in einer Schleife für jeden einzelnen eine weitere Abfrage. Aus einer Seite werden so Hunderte Datenbankzugriffe. Die Lösung: alle benötigten Daten in einer Abfrage laden, etwa über Joins oder Eager Loading. Profiling-Tools wie Blackfire oder Tideways machen solche Muster sichtbar.

DAL oder DBAL

Der Data Abstraction Layer (DAL) von Shopware ist flexibel und erweiterbar, kostet aber Leistung. Für interne Prozesse oder wenn nur IDs benötigt werden, ist direktes SQL über DBAL deutlich schneller. Entwickler sollten bewusst entscheiden, welche Schicht zur Aufgabe passt – und eigene Abfragen in jedem Fall optimieren.

Elasticsearch oder OpenSearch

Bei grossen Sortimenten ist eine Suchmaschine wie Elasticsearch oder OpenSearch oft Pflicht. Sie ist für schnelle Suchen gebaut und nimmt MySQL die aufwendigen Such- und Filterabfragen ab.

Setzen Sie dabei in der .env:

SHOPWARE_ES_THROW_EXCEPTION=1

Sonst fällt Shopware bei einem Fehler der Suchmaschine stillschweigend auf MySQL zurück – und das kann in grossen Projekten die Datenbank komplett überlasten.

Datenbank aufräumen

Eine schlanke Datenbank bleibt schneller. Behalten Sie vor allem diese Bereiche im Auge:

• Alte Warenkörbe: Verlassene Warenkörbe sammeln sich an. Was für Remarketing nicht mehr relevant ist, kann weg. Stimmen Sie die Ablaufzeiten auf Ihre Geschäftsprozesse ab.
• Log-Tabellen: Logs wachsen über die Zeit stark und belasten Abfragen und Speicher. Kürzen oder archivieren Sie alte Einträge.
• Geplante Aufgaben: Shopware räumt einen Teil selbst über Scheduled Tasks auf – das funktioniert aber nur, wenn diese zuverlässig laufen (siehe unten).

Die Datenbank ist oft der «stille» Engpass: Caching kann Probleme lange verdecken, bis bei Lastspitzen oder komplexen Abfragen alles gleichzeitig langsam wird. Ziel ist deshalb nicht nur schnellere Einzelabfragen, sondern eine insgesamt geringere Last auf dem Datenbankserver.

Frontend

Bilder

Bilder machen auf vielen Seiten den grössten Teil der Datenmenge aus und beeinflussen den LCP direkt.

• Moderne Formate: WebP oder AVIF komprimieren deutlich besser als JPEG oder PNG.
• Vor dem Upload komprimieren: Tools wie TinyPNG oder ImageOptim verkleinern Dateien ohne sichtbaren Qualitätsverlust. Einige Shopware-Erweiterungen automatisieren das.
• Thumbnails nutzen: Die Twig-Funktion sw_thumbnails erzeugt passende Bildgrössen, damit der Browser je nach Gerät die richtige Variante lädt.
• Breite und Höhe angeben: width- und height-Attribute im <img>-Tag verhindern Layout-Verschiebungen (CLS).
• Lazy Loading: Bilder, Videos und Iframes ausserhalb des sichtbaren Bereichs erst laden, wenn sie gebraucht werden. Wichtig: Bilder, die ohne Scrollen sichtbar sind, davon ausnehmen – sonst verschlechtert sich der LCP.

CSS und JavaScript

Minimierte CSS-, JavaScript- und HTML-Dateien sind kleiner und schneller geladen. Shopware minimiert Storefront-CSS und -JavaScript im Produktivbuild; für das HTML gibt es Plugins, die das zusätzlich übernehmen.

Seit Shopware 6.6 lädt die Storefront JavaScript-Plugins asynchron. Früher steckten alle Plugins in einer grossen Datei, die auf jeder Seite geladen wurde. Heute werden sie erst geladen, wenn ein passendes Element im DOM vorhanden ist. Das Einstiegsskript wird mit defer eingebunden und blockiert das Rendern nicht mehr. Damit eigene Plugins davon profitieren, sollten sie in den Twig-Templates über Datenattribute an konkrete DOM-Elemente gebunden sein.

Gefühlte Geschwindigkeit

Lazy Loading und asynchrones JavaScript verkürzen nicht unbedingt die Gesamtladezeit aller Dateien. Sie sorgen aber dafür, dass sichtbare Inhalte zuerst erscheinen und die Seite früh bedienbar ist. Eine Seite, die schnell vollständig aussieht und nicht springt, wirkt auf Besucher oft schneller als eine mit minimal kürzerer Gesamtladezeit, die anfangs leere Flächen zeigt. Genau das bilden LCP und CLS ab.

Plugins und eigener Code

Plugins regelmässig prüfen

Das Plugin-System ist eine Stärke von Shopware, aber auch eine häufige Ursache für Leistungsprobleme. Plugins können sich in jede Anfrage einklinken, unnötige Datenbankabfragen auslösen oder schlecht skalieren. Schon ein einzelnes Plugin kann einen ganzen Shop ausbremsen – etwa, wenn sein Debug-Modus aktiv geblieben ist.

• Plugin-Liste ausmisten: Entfernen Sie Plugins, die Sie nicht mehr brauchen oder die nicht mehr gepflegt werden. Auch deaktivierte Altlasten erschweren Updates und Fehlersuche.
• Laufzeit messen: Prüfen Sie mit Profiling-Tools, wie viel Zeit jedes aktive Plugin kostet – besonders im Checkout.
• Kompatibilität sicherstellen: Alle Plugins müssen zur eingesetzten Shopware-Version passen. Veraltete Plugins kosten Leistung und können Sicherheitslücken öffnen.

Fehlt eine Funktion, ist ein schlankes, auf Ihren Shop zugeschnittenes Plugin oft die bessere Lösung als mehrere Allzweck-Erweiterungen. Mehr dazu auf unserer Seite zu Shopware-Plugins.

Eigenen Code sauber halten

Individuelle Anpassungen brauchen klare Regeln. Regelmässige Code-Reviews helfen, Probleme früh zu erkennen. Typische Leistungsbremsen:

• Ineffiziente Datenbankabfragen: fehlende Indizes, unnötige Joins, N+1-Abfragen. Langsame Abfragen finden Sie mit dem Symfony Profiler oder dem FroshDevelopmentHelper.
• Zu viel synchrone Verarbeitung: Was nicht sofort erledigt sein muss, gehört in die Message Queue.
• Schwerfällige Event-Subscriber: Ein Subscriber, der bei jedem Event aufwendige Logik ausführt, erzeugt versteckten Overhead.
• Fehlendes Caching: Daten, die sich selten ändern, sollten nicht bei jeder Anfrage neu berechnet werden.
• Technische Schulden: Toter oder unübersichtlicher Code und Klassen mit zu vielen Aufgaben erschweren Fehlersuche und Optimierung. Entfernen Sie Code, der nicht mehr gebraucht wird.

CLI-Worker statt Admin-Worker

Standardmässig arbeitet Shopware die Message Queue über den Admin-Worker ab. Er ist langsam und läuft nur, solange jemand die Administration geöffnet hat. Für Produktivsysteme deaktivieren Sie ihn in config/packages/shopware.yaml:

shopware:
  admin_worker:
    enable_admin_worker: false

Stattdessen verarbeiten Sie Queue und geplante Aufgaben über die Kommandozeile:

bin/console messenger:consume async low_priority --time-limit=60
bin/console scheduled-task:run --time-limit=60

Lassen Sie diese Befehle dauerhaft über einen Prozessmanager wie systemd oder Supervisor laufen, der sie nach Ablauf des Zeitlimits automatisch neu startet. So werden Hintergrundaufgaben laufend abgearbeitet, ohne die Administration zu bremsen.

Kurz gesagt: Jedes Plugin und jede Zeile eigener Code sollten ihre Notwendigkeit und ihre tatsächlichen Kosten zur Laufzeit rechtfertigen. Eine schlanke Codebasis ist ebenso wichtig wie leistungsfähige Hardware.

Überwachen, testen, pflegen

Application Performance Monitoring (APM)

APM-Tools zeigen laufend, wie es um Ihren Shop steht, und helfen, Probleme zu finden, bevor Kunden sie bemerken.

• Blackfire.io: Profiling auf Code-Ebene. Zeigt Zeit pro Funktion und Controller, Speicherverbrauch, langsame Datenbankabfragen und den Overhead einzelner Plugins.
• New Relic APM: Überwacht PHP-Transaktionen, langsame MySQL-Abfragen und externe Dienste in Echtzeit und warnt bei Auffälligkeiten.
• Tideways: Auf PHP spezialisiert. Findet Engpässe wie N+1-Abfragen, vergleicht die Leistung vor und nach einem Release und bietet Benchmarks wie die oben gezeigten.

Lasttests

Lasttests zeigen, wie sich Ihr Shop unter Druck verhält – bevor es echte Kunden in einer Spitzenzeit trifft. Mit Tools wie dem Open-Source-Werkzeug k6 simulieren Sie realistischen Verkehr. Testen Sie typische Abläufe:

• Stöbern ohne Login (Startseite, Kategorien, Suche)
• Registrierung und Checkout von Neukunden
• Wiederkäufe mit Login
• Backend-Prozesse wie Produktimporte über die API

Die Ergebnisse zu Antwortzeit, Anfragerate und Fehlerquote zeigen Engpässe und wie gut der Cache greift.

Cache und Indizes nach Änderungen

• Cache: Leeren Sie den Cache gezielt nach Deployments, Plugin-Installationen oder Theme-Änderungen und wärmen Sie ihn danach wieder auf. Unnötig häufiges Leeren macht den Shop vorübergehend langsamer.
• Indizes: Shopware aktualisiert seine Indizes normalerweise über die Message Queue. Nach grossen Importen oder Updates können Sie sie mit bin/console dal:refresh:index neu aufbauen – bei grossen Katalogen mit der Option --use-queue und möglichst ausserhalb der Hauptverkehrszeiten.

Performance ist kein Projekt mit Enddatum. Software, Plugins, Sortiment und Verkehr ändern sich laufend. Wer nur einmal optimiert und dann nicht mehr hinschaut, verliert die gewonnene Geschwindigkeit nach und nach wieder. Messen Sie deshalb regelmässig, testen Sie vor grösseren Releases und berücksichtigen Sie Performance schon bei der Entwicklung neuer Funktionen.

Fazit

Ein schneller Shopware-Shop entsteht aus vielen Bausteinen: einer sauberen Messung als Ausgangspunkt, einer passenden Server-Konfiguration mit PHP, Webserver, Redis und CDN, einer gut abgestimmten Datenbank, einem schlanken Frontend sowie geprüften Plugins und sauberem eigenem Code.

Engpässe haben selten nur eine Ursache. Meist ist es ein Zusammenspiel aus Code, Caching, Konfiguration und Infrastruktur. Wer nur an einer Stelle optimiert, erzielt oft nur begrenzte Wirkung. Dazu kommen regelmässiges Monitoring, Lasttests und eine aktuelle Shopware-Version.

Sie möchten wissen, wo Ihr Shop Zeit verliert, oder suchen Unterstützung bei Wartung und Optimierung? Mit unserem Shopware-Support kümmern wir uns um Updates, Performance und Fehleranalyse – damit Ihr Shop dauerhaft schnell bleibt.