Shopware Performance verbessern: warum dein Shop langsam ist – und was wirklich hilft
Jede Sekunde Ladezeit kostet Umsatz. Das ist keine Floskel – Google hat das in mehreren Studien gemessen: ab einer Ladezeit von drei Sekunden verlässt die Mehrheit der mobilen Besucher den Shop ohne zu kaufen. Shopware 6 ist nicht automatisch langsam, aber eine unoptimierte Installation mit zu vielen Plugins, unkomprimierten Bildern und falschem Caching kann es werden. Dieser Artikel zeigt wo die häufigsten Bremsen stecken – und was du dagegen tun kannst.
Ladezeit ist Teil der technischen Grundlage, nicht des Inhalts — und damit einmalige Arbeit mit dauerhafter Wirkung. Was daneben einmalig eingestellt gehört, steht in der Checkliste für die SEO-Grundeinstellungen.
Inhalt
- Erst messen, dann optimieren
- Die drei häufigsten Ursachen für einen langsamen Shopware-Shop
- Bilder: der größte Einzelhebel
- Plugins: wenn zu viel des Guten bremst
- Caching: was Shopware mitbringt und was fehlt
- Was Google misst: LCP, CLS und INP in Händler-Sprache
- Was du selbst tun kannst – ohne Entwickler
- Was nur ein Entwickler löst
- Hosting: die oft vergessene Variable
- Häufige Fragen
Erst messen, dann optimieren
Wer Performance verbessern will ohne vorher zu messen, optimiert ins Blaue. Die Ausgangslage braucht Zahlen, keine Gefühle. Zwei kostenlose Tools die jeder nutzen sollte:
- Google PageSpeed Insights (pagespeed.web.dev): analysiert eine einzelne URL, zeigt Lab-Daten und – bei genug echtem Traffic – auch Field-Daten aus dem Chrome User Experience Report. Direkt mit der eigenen Shop-URL aufrufen, Desktop und Mobile separat prüfen.
- Google Search Console → Core Web Vitals: zeigt wie echte Nutzer deinen Shop erleben, gruppiert nach Seiten die schlechte, mäßige oder gute Werte haben. Das ist wichtiger als Labor-Daten weil es den tatsächlichen Erfahrungswert zeigt.
Bevor irgendetwas geändert wird: Ausgangswerte notieren. Nur so lässt sich später messen ob eine Maßnahme etwas gebracht hat.
Die drei häufigsten Ursachen für einen langsamen Shopware-Shop
Nach der Analyse vieler Shopware-Installationen lassen sich die häufigsten Performance-Probleme auf drei Kategorien zurückführen:
Die häufigsten Bremsen im Shopware-Shop
- Bilder: zu groß, falsches Format, nicht lazy-loaded. Macht in den meisten Shops 50–70 % des übertragenen Datenvolumens aus.
- Plugins: jedes Plugin das externe Skripte lädt bremst den ersten Seitenaufbau. Fünf Plugins die je ein JavaScript von einem externen Server laden sind fünf zusätzliche Netzwerkanfragen.
- Caching: Shopware hat eingebautes HTTP-Caching, aber es greift nicht für eingeloggte Kunden, nicht für personalisierte Inhalte und nicht für dynamische Elemente. Was nicht gecacht ist, wird bei jedem Aufruf neu berechnet.
Bilder: der größte Einzelhebel
Produktbilder sind der größte Einzelfaktor für Ladezeit in den meisten Shopware-Shops. Was typischerweise falsch läuft:
- Originaldateien werden hochgeladen (3–8 MB pro Bild) ohne dass Shopware automatisch kleinere Varianten erzeugt – oder die Varianten werden erzeugt aber das Theme bindet die Originalversion ein
- JPEG statt WebP – WebP ist bei gleicher Qualität 25–35 % kleiner als JPEG
- Kein Lazy Loading – alle Bilder auf der Kategorie- und Startseite laden gleichzeitig, auch die die sich außerhalb des sichtbaren Bereichs befinden
- Kein width/height-Attribut auf img-Tags – der Browser kann den Platz nicht reservieren bevor das Bild geladen ist, was zu Layout-Sprüngen führt
Shopware 6 erzeugt automatisch verschiedene Bildgrößen (Thumbnails) wenn das Theme sie richtig konfiguriert. WebP-Ausgabe ist seit Shopware 6.5 nativ unterstützt. Was trotzdem manuell geprüft werden muss: ob das aktive Theme srcset und sizes korrekt setzt, und ob Lazy Loading aktiviert ist. Viele ältere Themes tun das nicht.
Plugins: wenn zu viel des Guten bremst
Jedes aktive Shopware-Plugin das JavaScript in die Storefront injiziert, verlängert die Zeit bis die Seite interaktiv ist. Das ist nicht automatisch ein Problem – aber es summiert sich.
Besonders kritisch sind externe Skripte: Chat-Widgets, Bewertungsplattformen, Marketing-Tracker, A/B-Testing-Tools. Jedes dieser Skripte macht eine Netzwerkanfrage zu einem externen Server. Wenn dieser Server langsam antwortet, wartet der Browser – und der Nutzer wartet mit.
Die Lösung ist selten „alle Plugins deinstallieren". Sie ist: prüfen welche Plugins aktiv sind aber nicht genutzt werden, externe Skripte wenn möglich deferred laden (erst wenn der Nutzer interagiert), und Consent-Management so aufsetzen dass Tracking-Skripte erst nach Zustimmung geladen werden – was Performance und DSGVO-Compliance gleichzeitig verbessert.
Caching: was Shopware mitbringt – und was fehlt
Shopware 6 hat einen eingebauten HTTP-Cache (Varnish-kompatibel) der Seiten für nicht-eingeloggte Besucher cached. Das ist solide – für den anonymen Besucher lädt der Shop aus dem Cache, nicht aus der Datenbank.
Was Shopwares Standard-Cache nicht abdeckt:
- Eingeloggte Kunden: für sie wird die Seite bei jedem Aufruf neu gerendert. Bei Shops mit vielen Stammkunden die eingeloggt einkaufen, ist das ein spürbarer Unterschied zur anonymen Performance.
- Datenbankabfragen: wenn Plugins teure Datenbankabfragen ohne eigenes Caching machen, bremsen sie auch gecachte Seiten wenn sie z.B. den Header oder Footer beeinflussen.
- Produktbilder und Assets: Browser-Caching für statische Dateien muss über den Webserver (nginx/Apache) konfiguriert werden. Standardwert ist oft zu kurz.
Redis als Objekt-Cache für Shopware ist eine der wirkungsvollsten Server-seitigen Maßnahmen: häufig gelesene Datenbankwerte werden im Speicher gehalten statt bei jedem Aufruf aus der Datenbank gelesen. Bei Shops mit hohem Traffic ist das oft der größte einzelne Hebel nach den Bildern.
Was Google misst: LCP, CLS und INP in Händler-Sprache
Google bewertet Shopware-Seiten nach drei Metriken die zusammen als Core Web Vitals bekannt sind. Was sie bedeuten – ohne Entwickler-Sprache:
| Metrik | Was sie misst | Typische Ursache im Shopware-Shop | Zielwert |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Wie lange bis das größte sichtbare Element geladen ist – meistens das Produktbild oder Hero-Banner | Großes Bild nicht vorab geladen, langsamer Server, kein CDN | unter 2,5 Sek. |
| CLS (Cumulative Layout Shift) | Wie stark die Seite während des Ladens springt – Elemente die verschieben nachdem sie erscheinen | Bilder ohne width/height, Fonts die nachgeladen werden, Banner die sich einschieben | unter 0,1 |
| INP (Interaction to Next Paint) | Wie schnell reagiert die Seite wenn ein Nutzer klickt oder tippt – ersetzt seit 2024 den alten FID-Wert | Zu viel JavaScript das den Haupt-Thread blockiert, schwere Plugin-Skripte | unter 200 ms |
LCP ist für die meisten Shopware-Shops das drängendste Problem – weil Produktbilder groß sind und meistens das Largest Element auf der Seite. CLS passiert häufig durch Fonts die nachgeladen werden und Text verschieben. INP ist das schwierigste Problem weil es JavaScript-Architektur betrifft – hier hilft meistens nur ein Entwickler.
Was du selbst tun kannst – ohne Entwickler
- Bilder vor dem Upload komprimieren: Tools wie Squoosh (kostenlos, Browser-basiert) oder TinyPNG reduzieren Bildgröße um 50–80 % ohne sichtbaren Qualitätsverlust
- Nicht genutzte Plugins deaktivieren: Shopware lädt aktive Plugins auch wenn sie auf der aktuellen Seite keine Funktion haben. Was nicht aktiv gebraucht wird, deaktivieren.
- WebP in Shopware aktivieren: in den Medien-Einstellungen im Backend. Danach Thumbnail-Generierung neu starten damit bestehende Bilder konvertiert werden.
- HTTP/2 prüfen: ob der Server HTTP/2 unterstützt zeigt ein Tool wie web.dev/measure – HTTP/2 lädt Ressourcen parallel statt nacheinander, was bei vielen kleinen Dateien deutlich schneller ist.
- Google Fonts lokal hosten: statt Fonts von Google-Servern zu laden können sie als lokale Dateien eingebunden werden. Ein Datenschutz-Argument (keine Google-Server) und ein Performance-Argument (keine externe Netzwerkanfrage).
Was nur ein Entwickler löst
Einige Performance-Probleme lassen sich nicht per Backend-Klick beheben:
- JavaScript-Bundle-Größe reduzieren: wenn Plugins große JS-Bundles laden, müssen diese analysiert und wenn möglich aufgeteilt werden – Tree Shaking, Code Splitting. Das ist Entwicklerarbeit.
- Kritisches CSS inline: das CSS das für den ersten sichtbaren Bereich gebraucht wird, direkt im HTML ausliefern statt als externe Datei. Beschleunigt den First Paint messbar.
- Redis konfigurieren: serverseitig, erfordert Hosting-Zugang und PHP-Konfiguration.
- INP-Probleme debuggen: welches Skript blockiert den Haupt-Thread? Chrome DevTools Performance-Profil, Analyse, gezielte Optimierung. Nicht ohne technisches Verständnis möglich.
- CDN einrichten: statische Assets (Bilder, JS, CSS) über ein Content Delivery Network ausliefern das den Inhalt vom nächstgelegenen Server zum Nutzer bringt.
Hosting: die oft vergessene Variable
Zwei Shops mit identischem Code können sehr unterschiedlich schnell sein – wenn sie auf verschiedenen Servern laufen. Shared Hosting auf günstigen Tarifen teilt CPU und RAM mit hunderten anderen Shops. Bei Traffic-Spitzen bremst das den ganzen Server.
Für Shopware-Shops die ernsthaft betrieben werden, sind die relevanten Hosting-Optionen: dedizierter vServer mit mindestens 4 GB RAM und SSD, oder Managed Shopware Hosting (Maxcluster, shopware.cloud, Hetzner mit Shopware-Templates) das auf Shopware-spezifische Performance ausgelegt ist. PHP 8.3, OPcache und MariaDB statt MySQL sind Grundvoraussetzungen. Wer noch auf PHP 8.1 oder einem HDD-Server läuft, gewinnt allein durch den Hosting-Wechsel oft mehr als durch jede Code-Optimierung.
Häufige Fragen
Mein PageSpeed-Score ist 45 auf Mobile und 89 auf Desktop – was bedeutet das?
Mobile-Scores sind fast immer schlechter weil Google einen simulierten Mittelklasse-Mobilfunk-Anschluss als Testbedingung nutzt – das ist absichtlich konservativ. Ein Mobile-Score von 45 ist ernst zu nehmen aber kein Katastrophenwert. Wichtiger als der Gesamtscore sind die konkreten Metriken: was genau ist langsam, und wie weit entfernt ist der LCP-Wert vom Ziel?
Sollte ich ein Caching-Plugin installieren oder reicht der Shopware-eigene Cache?
Der Shopware HTTP-Cache ist für die meisten mittleren Shops ausreichend wenn er korrekt konfiguriert ist. Ein zusätzliches Caching-Plugin macht Sinn wenn viele eingeloggte Kunden den Shop nutzen (wofür der HTTP-Cache nicht greift), oder wenn es datenbankintensive Plugin-Abfragen gibt die gecacht werden sollen.
Verlangsamen mehr Plugins den Shop immer?
Nicht zwingend. Plugins die nur Backend-Funktionalität haben und kein JavaScript in die Storefront laden, haben praktisch keinen Performance-Einfluss. Problematisch sind Plugins die externe Skripte laden, schwere Datenbankabfragen machen, oder das Shopware-Rendering durch Overrides verlangsamen.
Was ist der schnellste Einzelschritt den ich heute tun kann?
Wenn Bilder nicht optimiert sind: WebP aktivieren und Thumbnails neu generieren. Das ist in zehn Minuten erledigt und hat meistens den größten sofortigen Effekt. Danach PageSpeed Insights erneut aufrufen und vergleichen.
Fazit: Performance ist kein Sprint, sondern Hygiene
Shopware-Performance ist kein einmaliges Projekt. Neue Plugins, neue Bilder, neue Features – jede Änderung kann die Performance beeinflussen. Wer PageSpeed Insights einmal im Monat aufruft und die Core Web Vitals in der Search Console im Blick hat, erkennt Verschlechterungen früh – bevor Google sie als Ranking-Signal wertet.
Die gute Nachricht: die wirkungsvollsten Maßnahmen sind meistens keine Entwicklungsprojekte. Bilder optimieren, nicht genutzte Plugins deaktivieren, WebP aktivieren – das bringt bei den meisten Shops bereits einen messbaren Unterschied. Was danach übrig bleibt, ist Feinarbeit für den Entwickler.
- Heute: PageSpeed Insights für Desktop und Mobile aufrufen, Ausgangswerte notieren
- Diese Woche: Bilder prüfen, WebP aktivieren, nicht genutzte Plugins deaktivieren
- Dieser Monat: Core Web Vitals in der Search Console einrichten und beobachten
- Längerfristig: Hosting prüfen, Redis evaluieren, JS-Analyse mit Entwickler
Shopware Performance systematisch angehen
Ertragswerke entwickelt Performance-Optimierungen für Shopware 6 – von Bild-Pipeline bis JavaScript-Analyse. Unverbindlich anfragen.
Projekt anfragen →
Shopware-Entwickler. Betreibt und optimiert eigene Shopware-Shops seit 2016 – und kennt das Gefühl wenn PageSpeed Insights rot wird.