Shopware ist langsam — meist ist es nicht Shopware.

Was Shopware braucht.

Shopware 6 setzt auf einen professionellen Unterbau mit Dienste-Container, getrennter Verwaltungsoberfläche und asynchroner Verarbeitung. Das macht es mächtig und anspruchsvoll.

Konkret heißt das: mehr Arbeitsspeicher als ein einfaches System, eine aktuelle PHP-Fassung, schnelle Datenträger, eine ordentlich dimensionierte Datenbank — und für größere Shops zusätzliche Dienste für Zwischenspeicherung und Suche.

Ein Shopware-Shop auf einem Einsteiger-Webspace ist kein Tempoproblem im eigentlichen Sinn. Es ist ein Werkzeug, das in einer zu kleinen Werkstatt steht (Welches Hosting passt).

Erst messen.

1. Serverantwortzeit je Seitentyp, mit und ohne Cache.
2. Im Backend messen — dort wirkt kein HTTP-Cache.
3. Zweimal laden und vergleichen: greift der Cache?
4. Datenmenge einer Kategorieseite ansehen.
5. Warteschlange prüfen: Stauen sich Nachrichten?
6. Zu verschiedenen Zeiten messen.

Punkt zwei ist bei Shops besonders aufschlussreich: Wenn die Startseite mit Cache in 200 Millisekunden kommt und das Backend fünf Sekunden braucht, ist die Hardware zu knapp — der Cache kaschiert das nur im Frontend (Messen).

Serverausstattung.

Die Zeilen fünf und sechs sind der Punkt, an dem sich kleine von größeren Installationen unterscheiden. Ein Shop mit wenigen hundert Artikeln kommt ohne aus; ab einigen tausend Artikeln und spürbarem Verkehr bringen beide deutlich mehr als jede Mikrooptimierung.

Der PHP-Zwischenspeicher für kompilierten Code ist bei Shopware besonders wirksam, weil viele Dateien beteiligt sind. Prüf, ob er aktiv und ausreichend dimensioniert ist — das ist eine Einstellung ohne Risiko (Serverantwortzeit).

HTTP-Cache und Aufwärmen.

Der größte Tempofaktor für nicht angemeldete Besucher. Shopware liefert dann fertige Seiten aus, statt sie zusammenzubauen.

Wichtig ist der zweite Teil: das Aufwärmen. Nach jedem Cache-Leeren ist der Speicher leer, und die ersten Besucher warten, bis ihre Seite gebaut ist. Bei einem Shop mit vielen Kategorien und Produkten heißt das: hunderte Besucher mit langen Wartezeiten.

Shopware bietet dafür einen Vorgang, der die wichtigsten Seiten vorab erzeugt. Den nach jedem Leeren laufen zu lassen, gehört zum Betrieb (Cache und Build).

Was nicht zwischengespeichert wird: Warenkorb, Kasse, Kundenkonto. Dort muss die Leistung echt erbracht werden — und das ist der Grund, warum ein Shop mit gutem Cache trotzdem eine ordentliche Serverausstattung braucht.

Warteschlange und Indizes.

Ein Shopware-eigenes Thema mit direkter Tempowirkung. Shopware arbeitet vieles asynchron ab und hält Daten in aufbereiteten Indizes.

Wenn die Warteschlange nicht abgearbeitet wird, passieren zwei Dinge: Aufgaben stauen sich — Mails, Bildverarbeitung, Indexaktualisierung — und bei starker Last bindet der Rückstau Ressourcen.

Wenn die Indizes nicht aktuell sind, muss Shopware Daten bei jedem Aufruf zusammensuchen, statt sie fertig vorzufinden. Das macht Kategorielisten und Suche spürbar langsamer.

Beides setzt voraus, dass die zugehörigen Vorgänge regelmäßig laufen — über einen Cronjob auf dem Server. Prüf einmal, ob das eingerichtet ist und wie viele Nachrichten gerade warten. Bei vielen Shops, die ich sehe, ist genau das der Befund (Wartung).

Produktbilder.

Der häufigste Einzelfund und der am leichtesten behobene. In Kategorielisten werden oft die großen Detailbilder ausgeliefert statt kleiner Vorschauen.

Shopware erzeugt beim Hochladen mehrere Größen — vorausgesetzt, die Einstellungen sind richtig und die Größen wurden erzeugt. Nach einem Theme-Wechsel oder einer Massenübernahme fehlen sie oft.

1. Prüfen, welche Datei in der Liste tatsächlich geladen wird.
2. Bildgrößen im Theme und in den Medieneinstellungen kontrollieren.
3. Größen neu erzeugen lassen für den Bestand.
4. Modernes Format aktivieren.
5. Verzögertes Laden für alles unterhalb des ersten Bildschirms — nicht für die erste Reihe.

Punkt drei läuft bei großen Sortimenten über die Warteschlange und dauert. Einplanen, nicht nebenbei starten (Bilder optimieren, Core Web Vitals im Shop).

Erlebniswelten.

Shopwares Werkzeug für gestaltete Kategorie- und Landingseiten — mächtig und bei unbedachter Nutzung ein Tempofaktor.

Typische Probleme: sehr viele Blöcke auf einer Seite, große Hintergrundbilder ohne passende Größen, eingebettete Videos, die beim Aufbau laden, und Blöcke mit vielen Produkten, die jeweils Daten nachschlagen.

Was hilft: Blöcke zählen und reduzieren, Hintergrundbilder in passender Größe hinterlegen, Videos erst auf Klick laden und Produktlisten auf eine sinnvolle Anzahl begrenzen. Eine Startseite mit vierzig Produkten in sechs Schiebereglern ist kein Gestaltungsproblem, sondern ein Tempoproblem (Externe Einbettungen).

Plugins.

Wie überall: Jedes Plugin kostet. Bei Shopware kommt hinzu, dass manche in den Seitenaufbau eingreifen und bei jedem Aufruf arbeiten.

Besonders zu prüfen: Plugins, die Preise neu berechnen, Verfügbarkeiten bei einem externen System abfragen, Empfehlungen erzeugen oder Daten an fremde Dienste senden. Die laufen bei jedem Seitenaufruf mit.

Der Test ist unangenehm und eindeutig: In der Testumgebung Plugins einzeln deaktivieren und die Serverantwortzeit messen. Was dabei auffällt, ist der Kandidat für eine Alternative (Plugins).

Suche.

Bei größeren Sortimenten ein eigener Posten. Die eingebaute Suche arbeitet über die Datenbank und kommt bei vielen tausend Artikeln mit Filtern an Grenzen.

Ein spezialisierter Suchdienst ist dann die wirksamste Einzelmaßnahme — er beschleunigt nicht nur die Suche, sondern auch gefilterte Kategorielisten erheblich, weil beides über denselben Index läuft.

Das ist mit Aufwand und laufenden Kosten verbunden und lohnt nicht bei jedem Shop. Die Grenze liegt erfahrungsgemäß dort, wo Kategorieseiten mit aktiven Filtern spürbar länger brauchen als ohne (Shop-Suche).

Langsames Backend.

Ein eigener Fall, weil dort kein HTTP-Cache wirkt. Wenn die Verwaltung zäh ist, misst man die ungefilterte Leistung des Systems — das ist ein ehrlicheres Signal als jede Frontend-Messung.

Häufige Ursachen: zu wenig Arbeitsspeicher, langsame Datenbank, sehr viele Bestellungen in Listen ohne Einschränkung, Plugins mit eigener Oberfläche, und nicht aktualisierte Indizes.

Wenn das Backend langsam und das Frontend schnell ist, liegt es fast immer an der Serverausstattung — und dann hilft nur Aufrüsten oder Entlasten, nicht Optimieren (Backend langsam).

Prüfweg nach Seitentyp.

Diese Aufteilung verhindert den häufigsten Fehler: an der Startseite zu optimieren, während die Kategorieseiten das Problem sind — und das sind die Seiten, über die verkauft wird.

Reihenfolge.

1. Serverausstattung prüfen — passt sie zur Shopgröße?
2. PHP-Zwischenspeicher aktiv und ausreichend?
3. Warteschlange und Indizes laufen lassen.
4. HTTP-Cache einrichten und aufwärmen.
5. Produktbilder auf vernünftige Größen.
6. Erlebniswelten entschlacken.
7. Plugins einzeln messen.
8. Zwischenspeicherdienst und Suchdienst, wenn die Größe es rechtfertigt.

Die Punkte eins bis drei sind Betriebsgrundlagen, keine Optimierung — und sie fehlen bei den meisten langsamen Shopware-Shops, die ich sehe. Erst danach lohnt der Feinschliff (Ladezeit optimieren).

Wenn du nicht weiterkommst.

Wenn dein Shop zäh ist und du wissen willst, ob es an der Ausstattung oder am Aufbau liegt. Ich finde die Ursache, behebe sie und erkläre dir, was passiert ist. Wenn gerade keine Bestellungen durchgehen, hilft der Notfall-Support, dauerhaft begleitet die Shopware-Wartung.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Content-Management- und Shopsysteme sind mein Fachgebiet — ich arbeite seit Jahren damit, unterrichte das Thema als Dozent und kenne die Systeme von innen: Datenmodell, Rechtekonzept, Templating, Plugin-Architektur, Caching, Betrieb.

Bei Shopware 6 zahlt sich das besonders aus, weil es auf demselben professionellen Unterbau aufsetzt wie andere ausgewachsene Systeme: Abhängigkeitsverwaltung, Dienste-Container, eine getrennte Verwaltungsoberfläche und eine Schnittstelle für alles. Wer dieses Modell verstanden hat, findet Fehler schnell — und sieht auch, wo ein Shop gegen das Modell gebaut wurde.

Was du bekommst: eine Diagnose in verständlicher Sprache, eine Behebung, die hält, und eine ehrliche Einschätzung dazu, ob dein Shop weiterbetrieben, aktualisiert oder abgelöst gehört — auch wenn die Antwort lautet, dass alles so bleiben kann.