Warum Shopware 6 langsam wird und welche Einstellungen aus der Shopware-Doku in welcher Reihenfolge helfen: HTTP-Cache, Redis, Queue-Worker, OpenSearch, Bilder, PHP. Mit Zielwerten und Kosten.
Die größten Hebel liegen im Backend, nicht im Theme. Ein aktiver HTTP-Cache, Redis statt Dateisystem, ein abgeschalteter Admin-Worker mit echten Queue-Workern und ab einigen tausend Produkten OpenSearch bringen in den meisten Shopware-6-Shops mehr als jede Frontend-Optimierung.
Messen Sie mit Felddaten, nicht nur mit Lighthouse. Google bewertet die Core Web Vitals am 75. Perzentil echter Nutzer: LCP höchstens 2,5 Sekunden, INP höchstens 200 Millisekunden, CLS höchstens 0,1.
Rechnen Sie mit 1.500 bis 4.000 € für Audit und Basismaßnahmen. Redis, OpenSearch, Bild-CDN und Theme-Bereinigung kosten je nach Shop 5.000 bis 15.000 € zusätzlich, ein Cluster mit Varnish mehr. Das sind Erfahrungswerte aus unseren Projekten, keine Listenpreise.
Wir haben vor der Gründung von solution25 selbst einen Online-Shop auf mehr als 500 Bestellungen am Tag gebracht und dabei gelernt, was jede Sekunde Ladezeit an Umsatz kostet. Seit 2017 betreiben und optimieren wir Shopware-Shops für Händler, vom Starter-Shop auf einem Server bis zum Cluster mit Varnish und OpenSearch.
Ein langsamer Shop verliert Besucher und Bestellungen, und Google bewertet die Ladezeit über die Core Web Vitals. Dieser Beitrag richtet sich an Shop-Betreiber, E-Commerce-Leiter und Entwickler, deren Shopware-6-Shop langsam lädt oder vor einer Kampagne mehr Last tragen muss.
Nach dem Lesen können Sie die Shopware Performance gezielt optimieren: die Ursache langsamer Seiten selbst eingrenzen, die Maßnahmen nach Wirkung und Aufwand ordnen und entscheiden, was Hoster, Agentur oder eigenes Team umsetzen. Alle Angaben beziehen sich auf Shopware 6.7 und die Shopware-Dokumentation, alle Preise Stand Oktober 2026, zuzüglich Mehrwertsteuer.
Bevor Sie eine Einstellung ändern, brauchen Sie eine Ausgangsmessung. Sonst weiß hinterher niemand, ob die Optimierung gewirkt hat.
Google bewertet Seiten anhand von drei Kennzahlen, die web.dev definiert. Entscheidend ist jeweils das 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop.
| Kennzahl | Gut | Schlecht | Was sie im Shop misst | Typische Ursache in Shopware |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | bis 2,5 s | über 4,0 s | Wann das größte sichtbare Element gerendert ist, meist das Bühnen- oder Produktbild | Serverantwort ohne Cache, zu große Bilder, Bild-Slider ohne Priorisierung |
| INP (Interaction to Next Paint) | bis 200 ms | über 500 ms | Wie schnell die Seite auf Klicks reagiert, etwa im Offcanvas-Warenkorb oder in Filtern | Zu viel JavaScript aus Plugins, Consent-Tools und Tracking im Hauptthread |
| CLS (Cumulative Layout Shift) | bis 0,1 | über 0,25 | Wie stark Inhalte beim Laden springen | Bilder ohne reservierten Platz, nachgeladene Schriften, eingeschobene Banner |
Die Zielwerte stammen aus den Artikeln zu LCP, INP und CLS auf web.dev. INP hat 2024 den früheren Wert First Input Delay abgelöst. Wer noch FID-Werte auswertet, misst eine Kennzahl, die Google nicht mehr nutzt.
PageSpeed Insights zeigt zwei verschiedene Dinge. Oben stehen Felddaten aus dem Chrome User Experience Report, also echte Nutzer der letzten 28 Tage am 75. Perzentil. Darunter folgt ein Lighthouse-Labortest, der ein Mittelklasse-Smartphone im Mobilfunknetz simuliert.
Für das Ranking zählen die Felddaten. Ein Lighthouse-Score von 95 auf der Startseite sagt nichts über die Kategorieseite, auf der die meisten Besucher landen.
Die Zeit bis zum ersten Byte (TTFB) trennt Server- von Frontend-Problemen. PageSpeed Insights stuft bis 800 Millisekunden als gut ein. Ein Shopware-Shop, dessen Seite aus dem HTTP-Cache kommt, antwortet nach unserer Erfahrung in unter 100 Millisekunden, eine ungecachte Kategorieseite mit vielen Filtern braucht oft 500 bis 1.500 Millisekunden.
Messen Sie dieselbe URL zweimal hintereinander. Ist der zweite Aufruf nicht deutlich schneller, ist der HTTP-Cache nicht aktiv oder wird ständig geleert. Das ist in unseren Audits die häufigste Einzelursache für einen langsamen Shopware-Shop.
Google dokumentiert auf web.dev mehrere Fallstudien. Vodafone steigerte den Umsatz um 8 %, nachdem der LCP um 31 % verbessert wurde, und die BBC verlor pro zusätzlicher Sekunde Ladezeit 10 % ihrer Nutzer. Die Zahlen sind nicht auf jeden Shop übertragbar, die Richtung ist es.
Shopware 6 ist von Haus aus nicht langsam. Shopware selbst misst für 6.7 im Benchmark-Szenario ohne Caching eine Antwortzeit von 231 Millisekunden, die 95 % aller Anfragen unterschreiten (p95). Langsam wird ein Shop durch Betrieb und Konfiguration, fast immer aus einem dieser sechs Gründe.
Die folgende Reihenfolge hat sich in unseren Projekten bewährt. Die Aufwände sind Erfahrungswerte aus Agenturprojekten, mit Stundensätzen, wie wir sie im Beitrag zu den Shopware Kosten beschreiben.
| Maßnahme | Wirkt vor allem auf | Aufwand | Für wen |
|---|---|---|---|
| 1. HTTP-Cache aktivieren und Invalidierung prüfen | TTFB, LCP | 1 bis 2 Tage | Jeder Shop |
| 2. Admin-Worker abschalten, Queue-Worker und Cronjob einrichten | TTFB, Stabilität | 0,5 bis 1 Tag | Jeder Shop |
| 3. Redis für Cache, Sessions und Delayed Invalidation | TTFB, Cache-Trefferquote | 1 bis 2 Tage | Ab mittlerem Traffic |
| 4. PHP-Version, OPcache und MySQL-Einstellungen | TTFB ungecachter Seiten | 0,5 bis 1 Tag | Jeder Shop |
| 5. Bilder: Thumbnails, Lazy Loading, WebP, CDN | LCP, Datenvolumen | 1 bis 3 Tage | Jeder Shop |
| 6. Plugin-Audit und Drittskripte reduzieren | INP, LCP | 2 bis 5 Tage | Shops mit mehr als 10 Plugins |
| 7. OpenSearch oder Elasticsearch | Listing, Filter, Suche | 3 bis 5 Tage plus Hosting | Ab einigen tausend Produkten |
| 8. Varnish oder Fastly als Reverse Proxy | Lastspitzen, TTFB | 2 bis 5 Tage plus Hosting | Kampagnen, hoher Traffic, Cluster |
Unsere Einschätzung: Wir empfehlen, die Maßnahmen 1 bis 4 umzusetzen, bevor Sie in größere Server oder Varnish investieren. Sie kosten zusammen drei bis sechs Tage und beheben die Ursachen, die wir in Audits am häufigsten finden; mehr Hardware macht einen Shop ohne funktionierenden Cache teurer, aber kaum schneller.
Shopware 6 bringt einen Full-Page-Cache mit, der über SHOPWARE_HTTP_CACHE_ENABLED=1 in der .env aktiviert wird. Die Cache-Dokumentation nennt ihn ein Muss für den Produktivbetrieb. Ob er läuft, sehen Sie in der Administration unter Einstellungen, System, Caches und Indizes.
Zwei Zustände schließen eine Seite standardmäßig vom Cache aus: eingeloggte Kunden und gefüllte Warenkörbe (shopware.cache.invalidation.http_cache mit den Werten logged-in und cart-filled). Wer keine personalisierten Inhalte ausspielt, kann diese Liste laut Performance-Tweaks-Dokumentation in der config/packages/prod/shopware.yaml leeren und erreicht deutlich höhere Trefferquoten.
Seit Shopware 6.7 werden Header und Footer per ESI (Edge Side Includes) als eigene Bausteine geladen und getrennt vom Rest der Seite gecacht, so die Release Notes zu 6.7.0.0. Eine Änderung im Menü muss damit nicht mehr jede gecachte Produktseite verwerfen.
Seit 6.7 ist die verzögerte Cache-Invalidierung standardmäßig aktiv (shopware.cache.invalidation.delay_enabled: true). Statt bei jeder Produktänderung sofort Cache-Einträge zu löschen, sammelt Shopware die betroffenen Tags und arbeitet sie alle fünf Minuten über die geplante Aufgabe shopware.invalidate_cache ab. Das Intervall steht in der Spalte run_interval der Tabelle scheduled_task.
Als Speicher dafür nutzt Shopware im Standard MySQL. Die Dokumentation empfiehlt Redis (shopware.cache.invalidation.delay_options.storage: redis), weil der MySQL-Adapter bei vielen gleichzeitigen Schreibzugriffen Deadlocks verursachen kann, etwa bei ERP-Importen mit tausenden Bestandsänderungen.
Der integrierte Cache läuft in PHP, jeder Treffer kostet also einen PHP-Prozess. Ein Reverse Proxy vor dem Shop beantwortet gecachte Seiten, ohne Shopware anzufassen. Shopware unterstützt laut Dokumentation Varnish ab Version 6.0 mit dem Modul xkey für das gezielte Löschen über Cache-Tags, das seit 6.7 Pflicht ist, sowie Fastly seit Shopware 6.4.11.0.
Die Konfiguration liegt seit 6.6 unter shopware.http_cache.reverse_proxy mit enabled: true, use_varnish_xkey: true und der Liste der Varnish-Hosts. Aktivieren Sie Soft Purges, damit Kunden während der Aktualisierung die alte Seite erhalten, und tragen Sie den Proxy in SYMFONY_TRUSTED_PROXIES ein. Steht der Antwort-Header Age dauerhaft auf 0, cacht der Proxy nicht.
Was das bringt, zeigt Shopware in seinen Benchmarks zu 6.7: Im Szenario Flash Sale mit Varnish stieg die Zahl der Bestellungen pro Sekunde gegenüber 6.6 um 108 %, die p99-Latenz sank von 1.000 auf 425 Millisekunden. Wie Varnish im verwalteten Betrieb aussieht, beschreiben wir im Beitrag zu Shopware PaaS auf Platform.sh.
Wichtig für Deployment-Skripte: cache:clear leert seit 6.7 nicht mehr den HTTP-Cache. Dafür gibt es cache:clear:http (seit 6.6.10) und cache:clear:all (seit 6.6.8).
Abbildung: Aus dem Cache bleibt die Serverantwort weit unter dem Grenzwert, ungecachte Kategorieseiten liegen oft darüber; prüfen Sie deshalb zuerst den HTTP-Cache. Grenzwert: Google PageSpeed Insights; Cache- und Kategoriewerte: Erfahrungswerte solution25, Stand Oktober 2026
Im Standard schreibt Shopware den Object-Cache nach var/cache und Sessions in den PHP-Standard-Handler. Für einen einzelnen Server reicht das laut Cache-Dokumentation aus. Bei mehreren Servern, vielen Cache-Tags oder hohen Bestellzahlen ist Redis die bessere Wahl.
Die Redis-Dokumentation empfiehlt, die Daten nach Lebensdauer zu trennen, weil eine Redis-Instanz nur eine Verdrängungsstrategie kennt. Eine Instanz mit allkeys-lru, die nebenbei Warenkörbe speichert, wirft unter Last genau diese Warenkörbe weg.
| Datenart | Beispiele | Persistenz | Eviction Policy |
|---|---|---|---|
| Flüchtig | HTTP-Cache, Object-Cache, Delayed Invalidation | keine, Verlust bei Neustart unkritisch | volatile-lru |
| Dauerhaft, alternd | Sessions | RDB-Snapshots und/oder AOF | allkeys-lru |
| Dauerhaft, kritisch | Warenkörbe, Nummernkreise, Lock Store, Increment Storage | RDB-Snapshots und/oder AOF | volatile-lru |
Der Tag-Aware-Adapter von Symfony legt Tag-Indizes ohne TTL an. Diese Schlüssel sammeln sich über Monate, bis Redis trotz volatile-lru nichts mehr verdrängen kann und mit Out-of-Memory aussteigt. Prüfen Sie den Anteil persistenter Schlüssel mit redis-cli INFO keyspace und bereinigen Sie verwaiste Tags nachts, etwa mit frosh:redis-tag:cleanup aus den FroshTools.
Shopware erledigt Indexierung, Thumbnails, Mails, Sitemap und Cache-Invalidierung asynchron über die Symfony Message Queue. Im Standard arbeitet der Admin-Worker diese Queue ab: Solange ein Administrator eingeloggt ist, fragt sein Browser alle 20 Sekunden nach und stößt die Verarbeitung an. Die Message-Queue-Dokumentation warnt, dass das bei mehreren Admin-Nutzern hohe CPU-Last erzeugt und PHP-FPM beeinträchtigt.
bin/console messenger:consume async low_priority --time-limit=60 --memory-limit=128M, überwacht von systemd oder supervisor. Ein eigener Worker für den Transport failed ist Pflicht, sonst bleiben fehlgeschlagene Nachrichten liegen.*/5 * * * * php bin/console scheduled-task:run --no-wait (ab 6.5.5.0) stellt fällige Aufgaben in die Queue. Die Einrichtung zeigt unser Beitrag zu Cronjobs und geplanten Aufgaben in Shopware.Zwei Indexer lassen sich abschalten, wenn Sie sie nicht brauchen: der Product-Stream-Indexer (shopware.product_stream.indexing: false, ab 6.6.10.0) und die geplante Sitemap-Generierung (shopware.sitemap.scheduled_task.enabled: false, ab 6.7.1.0, stattdessen nachts per Cron sitemap:generate). Ohne Product-Stream-Indexer aktualisieren sich dynamische Produktgruppen erst nach Ablauf des HTTP-Caches.
Listing, Filter und Suche laufen in Shopware 6 standardmäßig über MySQL. Die Shopware-Dokumentation empfiehlt eine Suchmaschine ab mehreren tausend Datensätzen. In unseren Projekten wird der Unterschied ab etwa 5.000 Produkten mit vielen Eigenschaften und Varianten deutlich, bei 50.000 Produkten ist OpenSearch alternativlos.
Die Anbindung läuft über wenige Variablen: OPENSEARCH_URL für die Hosts, SHOPWARE_ES_ENABLED=1 für die Suche, SHOPWARE_ES_INDEXING_ENABLED=1 für die Indexierung und SHOPWARE_ES_INDEX_PREFIX für den Indexnamen. Die Indexierung mit bin/console es:index läuft über die Message Queue, braucht also die Worker aus dem vorherigen Abschnitt.
Setzen Sie SHOPWARE_ES_THROW_EXCEPTION=1. Ohne diese Einstellung fällt Shopware bei einem Fehler der Suchmaschine stillschweigend auf MySQL zurück, und Sie bemerken den Ausfall erst an der Ladezeit. Mit 6.7.2.0 hat Shopware außerdem Sortierung und Abfragen für OpenSearch überarbeitet und nennt in den Release Notes bis zu 85 % kürzere Abfragezeiten.
Shopware stuft einen einzelnen Knoten als Testumgebung ein und nennt drei Master-fähige Knoten als Minimum für Ausfallsicherheit. In mittelständischen Shops betreiben wir trotzdem oft eine einzelne OpenSearch-Instanz mit 2 bis 4 GB RAM, dann mit Monitoring. Installation und typische Fehler beschreiben wir im Beitrag zu Elasticsearch und OpenSearch für Shopware 6.
Bilder sind auf fast jeder Shop-Seite das LCP-Element. Shopware erzeugt beim Upload laut Medien-Dokumentation standardmäßig drei Thumbnail-Größen (400, 800 und 1920 Pixel), konfigurierbar je Medienordner samt Qualitätsstufe. Nach einer Änderung erzeugt bin/console media:generate-thumbnails die Dateien neu.
Das Thumbnail-Template der Storefront baut automatisch srcset und sizes auf, damit der Browser je Viewport die passende Größe lädt, seit 6.7.12 auch für den XXL-Breakpoint. Standardmäßig lädt es Bilder mit loading=“eager“, die Produktkacheln im Listing setzen loading=“lazy“. In eigenen CMS-Elementen müssen Sie Lazy Loading selbst setzen, und zwar nur unterhalb des sichtbaren Bereichs.
Für das Bühnenbild gilt das Gegenteil: Seit 6.7.2.0 gibt es in der CMS-Konfiguration von Bild-Slider und Bildergalerie eine Einstellung für fetchpriority, mit der der Browser das erste Bild bevorzugt lädt. Shopware begründet das in den Release Notes ausdrücklich mit dem LCP.
Das Template gibt keine width- und height-Attribute aus. Reservieren Sie den Platz für Bilder im Theme per CSS (aspect-ratio), sonst springt das Layout beim Laden und der CLS leidet.
Shopware akzeptiert WebP beim Upload, rechnet JPG und PNG aber nicht selbst in moderne Formate um. Drei Wege führen zum Ziel: Produktbilder bereits als WebP hochladen, eine Erweiterung aus dem Shopware Store zur Konvertierung einsetzen oder die Bildverarbeitung auslagern.
Der dritte Weg ist seit 6.6.4.0 im Kern angelegt: Mit shopware.media.remote_thumbnails.enable: true erzeugt Shopware keine Thumbnail-Dateien mehr, sondern baut URLs nach einem Muster wie {mediaUrl}/{mediaPath}?width={width}, die ein Bild-CDN oder ein Dienst wie imgproxy auflöst. Der Dienst liefert WebP oder AVIF je nach Browser. Quelle: Dokumentation zu Remote Thumbnails.
Ein CDN hängt sich über die URL des öffentlichen Dateisystems ein (shopware.filesystem.public.url), danach bin/console asset:install und theme:compile ausführen. Für Assets aus dem CDN empfiehlt Shopware einen Cache-Control-Header wie public, max-age=86400. Quelle: Filesystem-Dokumentation.
Mit 6.7 hat Shopware laut eigenen Angaben das Storefront-JavaScript um 25 % und das CSS um 24 % verkleinert. Was danach noch bremst, kommt fast immer aus Plugins, Theme-Anpassungen und Drittskripten.
Seit 6.7.12 lädt Shopware auf Wunsch nur noch reduzierte Produktdaten im Listing, mit einem HTML-freien Beschreibungsauszug von maximal 512 Zeichen. Die Einstellung core.listing.partialDataLoading (Einstellungen, Produkte) ist bei Neuinstallationen aktiv, bei bestehenden Shops nicht. Aktivieren Sie sie nur, wenn Theme und Erweiterungen im Listing keine weiteren Produktfelder brauchen. Quelle: Release Notes 6.7.12.0.
Seit 6.7.2.0 lädt die Seitennavigation aktive Kategorie-Ebenen dynamisch nach. Die Navigationstiefe im Verkaufskanal bestimmt damit vor allem die Header-Navigation und kann für mehr Tempo gesenkt werden.
Shopware 6.7 unterstützt laut Update-Guide PHP 8.2, 8.3 und 8.4, seit 6.7.6.0 (Januar 2026) laut Shopware auch PHP 8.5. Nutzen Sie die neueste Version, die Ihre Plugins vertragen.
Die Performance-Tweaks-Dokumentation nennt für die Produktion konkrete PHP-Einstellungen: zend.assertions=-1, opcache.enable_file_override=1, opcache.interned_strings_buffer=20, opcache.validate_timestamps=0, zend.detect_unicode=0, realpath_cache_ttl=3600 und opcache.max_accelerated_files von mindestens 20000. Mit validate_timestamps=0 müssen Sie PHP-FPM nach jedem Deployment neu laden, sonst läuft alter Code weiter. OPcache-Preloading bringt laut Dokumentation weitere 2 bis 5 %, schaltet aber den Extension Manager ab.
Dazu kommen Kleinigkeiten mit Wirkung: die .env per bin/console dotenv:dump prod in eine PHP-Datei dumpen, ungenutzte Symfony Secrets deaktivieren und Monolog in der Produktion auf level: error setzen, auch für den Handler business_event_handler_buffer. Mit der PHP-Erweiterung zstd komprimieren Cache und Warenkorb seit 6.6.4.0 schneller als mit gzip (shopware.cache.cache_compression_method: zstd).
Shopware 6.7 verlangt MySQL ab 8.0.17 (nicht 8.0.20 und 8.0.21) oder MariaDB ab 10.11 (nicht 10.11.5 und 11.0.3). Zwei Serverwerte nennt die Performance-Tweaks-Dokumentation ausdrücklich: group_concat_max_len mindestens 320000 und ein sql_mode ohne ONLY_FULL_GROUP_BY. Shopware setzt beide Werte sonst bei jedem Verbindungsaufbau selbst.
Dimensionieren Sie innodb_buffer_pool_size so, dass die Arbeitsdaten des Shops hineinpassen, nach unserer Erfahrung 2 bis 4 GB für Kataloge bis 20.000 Produkte. Für sehr große Shops unterstützt Shopware Lese-Replikate über DATABASE_REPLICA_0_URL, womit Listing-Abfragen vom schreibenden Datenbankserver wegziehen.
Die folgenden Größen sind Erfahrungswerte aus unseren Projekten für spezialisiertes Shopware-Hosting in Deutschland, keine Vorgabe von Shopware. Sie entsprechen den Stufen in unserem Ratgeber Shopware Hosting, dort stehen auch Anbieter und Preise.
Nicht jeder Shop braucht Varnish und OpenSearch. Drei Profile decken die meisten Händler ab, die mit einem langsamen Shop zu uns kommen.
Alle Beträge sind Erfahrungswerte aus Agenturprojekten, zuzüglich Mehrwertsteuer. Ein Shop mit 40 Plugins und individuellem Theme kostet in der Bereinigung mehr als ein Shop mit Standard-Theme.
Beim Shopware-Shop der Kosmetikmarke Banana Beauty bremsten langsame Ladezeiten und eine begrenzte mobile Optimierung Conversions und Engagement. Nach Caching, Bildkompression, Lazy Loading und einem CDN sanken die Ladezeiten laut Fallstudie auf allen Geräten um 40 %.
Bei Miniature Market, einem Händler für Brettspiele und Miniaturen mit tausenden Artikeln, stieß der frühere Magento-Shop bei Nachfragespitzen zu Neuerscheinungen auf Performance-Engpässe. In Shopware 6 haben wir Suche und Filter mit Elasticsearch optimiert, das Kategorie-Caching verbessert, Assets über ein CDN ausgeliefert und große Veröffentlichungen per Last- und Stresstest simuliert. Laut Fallstudie liefert der Shop seitdem schnellere Suchergebnisse, flüssigere Filter und bessere Ladezeiten, die Warenkorbabbrüche sind gesunken.
Eine Optimierung hält etwa bis zum nächsten Plugin, deshalb gehört eine laufende Erfolgskontrolle dazu.
In den meisten Audits ist der HTTP-Cache aus oder wird ständig geleert, der Admin-Worker arbeitet die Queue im Browser ab, und zu viele Plugins und Drittskripte laden auf jeder Seite. Ein doppelter Aufruf derselben Kategorieseite zeigt in Sekunden, ob der Cache fehlt.
LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1, jeweils am 75. Perzentil der mobilen Nutzer. Die Serverantwort (TTFB) gilt bis 800 Millisekunden als gut, aus dem Cache sollte ein Shopware-Shop in unter 100 Millisekunden antworten.
Nicht zwingend, der integrierte HTTP-Cache reicht für viele Shops bis weit in den sechsstelligen Jahresumsatz. Varnish oder Fastly lohnen sich bei Lastspitzen durch Kampagnen oder mehreren Anwendungsservern; seit Shopware 6.7 ist dafür das Modul xkey Pflicht.
Laut den Benchmarks von Shopware ja: Mit Varnish stieg die Zahl der Bestellungen pro Sekunde um 108 %, das Storefront-JavaScript wurde um 25 % kleiner. Version 6.6 erhält laut endoflife.date bis zum 28. Februar 2028 Sicherheitsupdates, aber keine dieser Verbesserungen.
Nein. Shopware 5 ist seit dem 31. Juli 2024 abgekündigt und erhält keine regulären Sicherheitsupdates mehr; das Budget ist in der Migration auf Shopware 6 besser angelegt.
Selten bei den Ursachen. Erweiterungen für Bildkonvertierung, Cache-Warmup oder Lazy Loading verbessern einzelne Punkte, ersetzen aber keine Servereinstellung und keinen Queue-Worker.
So selten wie möglich. Mit Delayed Invalidation aktualisiert Shopware geänderte Seiten alle fünf Minuten selbst, ein nächtliches cache:clear wirft dagegen den Full-Page-Cache weg und macht den Shop morgens für alle langsam. Ein vollständiges Leeren gehört zu Deployments, nicht in den Cron.
Sie möchten wissen, welche der genannten Maßnahmen in Ihrem Shop fehlen und was sie bringen würden? Unsere kostenlose Shop-Analyse misst Ladezeit und Core Web Vitals mit Labor- und Felddaten, crawlt Ihren Shop und liefert innerhalb von zwei Werktagen eine priorisierte Fehlerliste. Zugang zu Ihrem Server braucht sie dafür nicht.
Für ein Performance-Audit mit Profiling, Lasttest und Umsetzungsplan schreiben Sie uns. Wir sagen Ihnen vorab, ob sich der Aufwand für Ihren Shop lohnt.
Mehr über unsere Arbeitsweise, Zertifizierungen und Standorte lesen Sie auf der Seite Shopware Agentur solution25.
Besar Bilalli ist Mitgründer und Geschäftsführer von solution25, der Shopware Agentur aus Bremen. Vor der Agenturgründung 2017 hat er gemeinsam mit Besnik Bilalli einen eigenen Online-Shop ohne Startkapital aufgebaut und auf mehr als 500 Bestellungen am Tag gebracht. Seitdem begleitet er Händler bei Shopware-Projekten, von der Systemauswahl bis zum laufenden Betrieb. Fragen zum Artikel beantwortet er gern persönlich: Kontakt aufnehmen.
Verantwortlich für Inhalt und Aktualisierung: Besar Bilalli. Stand: Oktober 2026. Nächste inhaltliche Prüfung: Januar 2027.
