Shopware 6 schneller machen: Cache, Redis, Elasticsearch, Bilder – die Reihenfolge, die sich lohnt

Die meisten langsamen Shopware-6-Shops haben kein Hardware-Problem, sondern ein Konfigurationsproblem: HTTP-Cache aus, Admin-Worker an, kein Redis, zu große Bilder. Ich gehe hier die Maßnahmen in der Reihenfolge durch, in der sie am meisten bringen – von kostenlos bis aufwendig.

1. Messen, bevor Sie schrauben

Ohne Messung optimieren Sie ins Blaue. Zwei Werkzeuge reichen für den Anfang: Google PageSpeed Insights für die Core Web Vitals und die Netzwerk-Ansicht Ihres Browsers für die Serverantwortzeit (TTFB, „Time to First Byte“). Die Core Web Vitals sind drei Kennzahlen, mit denen Google die Nutzererfahrung bewertet: LCP (Ladezeit des größten sichtbaren Elements), INP (Reaktionszeit auf Eingaben) und CLS (Layoutverschiebungen). Als „gut“ gelten laut Google ein LCP bis 2,5 Sekunden, ein INP bis 200 Millisekunden und ein CLS bis 0,1.

Wichtig für die Diagnose: Ist die Serverantwort langsam (TTFB über einer Sekunde), liegt das Problem im Backend – Cache, Datenbank, Plugins. Ist der Server schnell, aber die Seite trotzdem träge, geht es um Bilder, JavaScript und Theme.

2. HTTP-Cache einschalten und richtig warm halten

Der HTTP-Cache speichert fertig gerenderte Seiten für anonyme Besucher. Shopware nennt ihn in der eigenen Dokumentation ein „Must-have“ für jedes Produktivsystem. Aktiviert wird er in der .env mit SHOPWARE_HTTP_CACHE_ENABLED=1. Ich sehe erstaunlich oft Shops, bei denen dieser Wert auf 0 steht, weil er beim Entwickeln ausgeschaltet wurde.

Zum Aufwärmen: Der Symfony-Befehl cache:warmup erzeugt den Container- und Routing-Cache, aber nicht die gerenderten Seiten. Die früheren HTTP-Cache-Warmer hat Shopware mit 6.6 als veraltet markiert und empfiehlt stattdessen, die Seiten mit einem Crawler aufzurufen. In der Praxis heißt das: nach jedem Cache-Leeren die wichtigsten Kategorien und Produkte per Script oder Sitemap-Crawler einmal abrufen.

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

Leeren Sie den Cache nicht reflexartig bei jedem Problem. Jedes cache:clear bedeutet, dass die nächsten Besucher ungecachte Seiten bekommen.

3. Admin-Worker aus, Message Queue per Cron

Shopware erledigt viele Aufgaben im Hintergrund: Indexierung, Mails, Sitemap, Importe. Standardmäßig verarbeitet der sogenannte Admin-Worker diese Warteschlange – aber nur, solange jemand in der Administration eingeloggt ist, und auf Kosten der Browser-Performance. Shopware selbst rät für Produktivsysteme davon ab.

Besser: Admin-Worker deaktivieren (shopware.admin_worker.enable_admin_worker: false in einer YAML-Datei unter config/packages/) und die Worker serverseitig laufen lassen, per Cron oder als Dienst:

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

Beachten Sie: Seit 6.6 müssen Worker die Warteschlange low_priority ausdrücklich mit angeben, sonst bleiben Aufgaben liegen. Shopware beschreibt bis zu drei Worker-Prozesse als üblichen Wert für Produktivumgebungen.

4. Redis für Cache und Sessions

Redis ist ein Speicher im Arbeitsspeicher. Ohne Redis legt Shopware den Cache im Dateisystem und die Sessions in der Datenbank ab. Beides funktioniert, beides skaliert schlecht. Mit Redis als App-Cache (cache.adapter.redis_tag_aware ab Shopware 6.5.8.3) und als Session-Handler (framework.session.handler_id) sinkt die Datenbanklast spürbar. Shopware empfiehlt für den Cache die Eviction-Policy volatile-lru, für Sessions allkeys-lru und persistente Speicherung, damit Sessions einen Redis-Neustart überleben.

Ein Hinweis aus der Praxis: Redis ohne Pflege füllt sich mit Tag-Indizes ohne Ablaufdatum. Shopware empfiehlt dafür eine regelmäßige Bereinigung, zum Beispiel nächtlich mit dem Befehl frosh:redis-tag:cleanup aus dem kostenlosen FroshTools-Plugin.

5. Elasticsearch oder OpenSearch – ab wann?

Elasticsearch und OpenSearch sind Suchmaschinen, die Shopware statt MySQL für Produktsuche und Listings nutzen kann. Die Frage „ab wann“ beantworte ich so: Wenn die Kategorieseiten und die Suche trotz HTTP-Cache und Redis bei nicht gecachten Aufrufen mehrere Sekunden brauchen und der Katalog einige zehntausend Produkte oder sehr viele Varianten hat. Darunter ist der Betriebsaufwand meist höher als der Nutzen.

Die Aktivierung läuft über OPENSEARCH_URL, SHOPWARE_ES_ENABLED=1 und SHOPWARE_ES_INDEXING_ENABLED=1 in der .env. Danach indexieren – die Worker aus Schritt 3 müssen dafür laufen:

bin/console cache:clear
bin/console es:index
bin/console dal:refresh:index --use-queue

dal:refresh:index baut alle Indizes neu auf, also auch SEO-URLs und den Produktindex; Shopware empfiehlt die Option --use-queue. Falls nach fehlerfreier Indexierung keine Produkte erscheinen, hilft oft bin/console es:create:alias. Beachten Sie außerdem: Mit aktivem Elasticsearch greifen die Sucheinstellungen aus der Administration nicht mehr; die durchsuchbaren Felder konfigurieren Sie dann über die Advanced-Search-Erweiterung.

6. Bilder: Thumbnails, WebP, Größen

Bilder sind fast immer der größte Posten beim LCP. Drei Punkte:

• Thumbnail-Größen prüfen. Shopware legt standardmäßig 400, 800 und 1920 Pixel an. Nach Änderungen an den Größen müssen Sie die Thumbnails neu erzeugen:

bin/console media:generate-thumbnails

• WebP. Shopware akzeptiert WebP beim Upload. Eine automatische Umwandlung bestehender JPEG-Bilder in WebP oder AVIF bringt der Kern nach meinem Stand nicht mit; dafür gibt es Plugins aus dem Store und der Community (etwa den FroshPlatformThumbnailProcessor).
• Originale nicht ausliefern. Wenn das Theme auf Produktseiten die Originaldatei statt eines Thumbnails lädt, ist das ein Theme-Fehler, kein Hosting-Problem.

7. Plugins, Theme, JavaScript – und zuletzt der Server

Ich messe bei Performance-Analysen regelmäßig, dass ein einzelnes Plugin 30 bis 50 Prozent der Serverzeit frisst – häufig Tracking, Feeds oder Preisanpassungen, die bei jedem Aufruf rechnen. Der schnellste Test: Plugin deaktivieren, Cache leeren, dieselbe Seite messen. Ein Profiler wie Tideways oder Blackfire zeigt das präziser, kostet aber Geld.

Beim Theme gilt: jede zusätzliche Schriftart, jedes Slider-Script und jede Drittanbieter-Einbindung (Chat, Bewertungen, Consent-Tool) verschlechtert INP und LCP. Laden Sie Drittscripte nach, wo es geht, und halten Sie das Theme nah am Standard – das zahlt sich auch beim nächsten Update aus.

Erst wenn die Punkte oben erledigt sind, lohnen sich Server-Details. Shopware nennt in seinen Performance-Hinweisen unter anderem: OPcache mit opcache.validate_timestamps=0 (dann OPcache bei jedem Deployment leeren), opcache.max_accelerated_files=20000 oder höher, realpath_cache_ttl=3600, bei MySQL group_concat_max_len mindestens 320000 und ein sql_mode ohne ONLY_FULL_GROUP_BY. Das sind Einstellungen für den Hoster oder Administrator – nicht für die Administration.

Häufige Fragen

Wenn Sie solche Messungen nicht selbst regelmäßig durchführen wollen, gehört ein Performance-Check in ein Shopware-Wartungspaket – dort läuft er bei mir als fester Punkt mit.