Warum euer Shopware-Shop langsam wird - und was wirklich hilft

Executive Summary

Ein langsamer Shop ist ein Umsatzproblem, kein technischer Schönheitsfehler - jede zusätzliche Sekunde Ladezeit kostet euch Besucher, die abspringen, bevor sie etwas in den Warenkorb legen. Die naheliegende Reaktion ist meist die falsche: einen großen Re-Build „auf Verdacht" beauftragen. Das Problem dabei ist, dass ein langsamer Shopware-Shop fast nie eine einzelne Ursache hat, sondern eine Summe vieler kleiner. Wer ohne Messung neu baut, riskiert, dass der neue Shop dieselben Engpässe erbt - nur teurer. Dieser Beitrag zeigt, woher die Langsamkeit typischerweise kommt und warum Messen vor Bauen der einzige Weg ist, der euer Budget nicht verbrennt.

Ein langsamer Shop ist selten ein Problem

Wenn ein Shop „langsam" ist, klingt das nach einer Sache, die man findet und behebt. In der Praxis ist es fast nie so. Über die Jahre haben sich viele kleine Bremsen angesammelt, und jede einzelne kostet ein bisschen. Zusammen ergeben sie eine Ladezeit, die Kunden vertreibt.

Das ist die wichtigste Erkenntnis für eine Budget-Entscheidung: Es gibt selten den einen Schalter. Wer den großen Wurf erwartet, plant am Problem vorbei - und wer alles gleichzeitig neu bauen will, behebt vieles, das gar nicht das Problem war, und übersieht womöglich genau die Bremse, die zählt.

Die typischen Ursachen - und warum sie zusammen wirken

Diese Punkte sehen wir in gewachsenen Shopware-Shops immer wieder. Keiner davon ist exotisch - gerade deshalb summieren sie sich unbemerkt:

• Über Jahre gewachsene Plugin-Last. Jedes Plugin schien einzeln sinnvoll. In Summe laden sie bei jedem Seitenaufruf Code, behindern sich gegenseitig und niemand traut sich mehr, eines zu entfernen, weil unklar ist, was dann kaputtgeht.

• Falsch oder unzureichend konfiguriertes Caching. Shopware bringt leistungsfähige Caching-Mechanismen mit. Sind sie nicht sauber eingerichtet, berechnet der Shop bei jedem Aufruf Dinge neu, die er längst fertig vorliegen haben könnte.

• Schwere Templates und ineffiziente Datenbank-Abfragen. Eine Seite, die für die Anzeige Dutzende einzelne Abfragen auslöst, ist langsam - egal wie gut der Server ist.

• Fehlende Datenbank-Indizes. Wächst der Katalog, werden ungünstige Abfragen mit jeder neuen Bestellung und jedem Artikel träger.

• Nicht optimierte Bilder und Assets. Große, unkomprimierte Produktbilder sind oft der größte einzelne Brocken, den der Browser eures Kunden laden muss.

• Unterdimensioniertes oder falsch konfiguriertes Hosting. Manchmal ist nicht der Code das Problem, sondern eine Serverumgebung, die nie zur tatsächlichen Last gepasst hat.

Das Tückische: Jeder dieser Punkte kann die Hauptursache sein - oder eine Nebenrolle spielen. Von außen, durch reines Hinschauen, lässt sich das nicht entscheiden.

Warum „neu bauen auf Verdacht" das Geld verbrennt

Die teure Variante ist nicht die Reparatur. Die teure Variante ist der Re-Build ohne Diagnose. Wer einen neuen Shop baut, ohne zu wissen, wo die Zeit im alten verloren geht, baut die Engpässe oft direkt mit ein: dieselben schweren Templates, dieselbe Plugin-Logik, dieselben Abfragemuster, nur in neuer Verpackung. Am Ende steht ein Projekt mit sechsstelligem Volumen - und ein Shop, der sich kaum schneller anfühlt.

Hinzu kommt: Ein Re-Build bindet Monate. In dieser Zeit bleibt der langsame Shop online und kostet weiter Conversion. Eine gezielte, gemessene Verbesserung kann oft schon nach Wochen den größten Hebel entschärfen - während der Shop durchgehend live bleibt.

Erst messen, dann beheben

Unser Ansatz für Performance ist derselbe wie für den Rest dieser Serie: iterativ statt Big-Bang, und nichts auf Verdacht. Konkret heißt das, dass wir vor jeder Optimierung Transparenz herstellen.

Monitoring aufsetzen. Ein Application-Performance-Monitoring wie Elastic APM zeigt, welche Seiten langsam sind und woran die Zeit dort konkret hängt - an einer Datenbank-Abfrage, an einem Plugin, am Rendering. Fehler-Tracking wie Sentry deckt Probleme auf, die im Hintergrund mitlaufen, ohne dass es jemand sieht. Damit wird aus „der Shop fühlt sich lahm an" eine Liste benannter Ursachen.

Den größten Einzelhebel zuerst. Sobald die Messung vorliegt, ist die Reihenfolge klar: Man geht die Ursache an, die nachweislich am meisten Zeit kostet - nicht die, die am einfachsten klingt. Ist sie behoben, misst man erneut. So arbeitet man die Liste ab, jeder Schritt belegbar, kein Schritt geraten.

Was das in Sekunden oder in Conversion bringt, lässt sich seriös erst nach der Messung in eurem konkreten Shop sagen - Kataloggröße, Traffic und Plugin-Setup sind bei jedem Händler anders. Genau deshalb messen wir, statt zu versprechen.

Womit ihr anfangen könnt

Ihr braucht für den ersten Schritt kein großes Projekt:

1. Verschafft euch echte Zahlen. Lasst Monitoring auf eurem Shop einrichten, statt euch auf das Bauchgefühl „fühlt sich langsam an" zu verlassen. Erst dann diskutiert ihr über Fakten.

2. Identifiziert die langsamsten Seiten und Abfragen. Meist sind es wenige Stellen, die den Großteil der Last verursachen - Startseite, Listing, Produktdetailseite, Checkout.

3. Nehmt euch den größten Hebel zuerst vor - einzeln. Eine Ursache beheben, neu messen, weitermachen. Kein Rundumschlag.

Fazit

Ein langsamer Shopware-Shop ist kein Schicksal und meistens auch kein Fall für den Abrissbagger. Er ist eine Summe vieler kleiner, messbarer Ursachen. Wer sie misst, statt zu raten, repariert gezielt das, was Conversion kostet - und vermeidet den teuersten Fehler: einen neuen Shop zu bezahlen, der dieselben Engpässe erbt. Wie iteratives Vorgehen ein ganzes Shop-Projekt prägt, vertiefen wir im Beitrag zum Re-Build ohne Big-Bang.

Teil 4 der Serie „E-Commerce ohne Bullshit".