Page Speed ist nicht optional. Es ist Revenue. Ein Shop der eine Sekunde langsamer ist, verliert real Umsatz. Und wenn du dich in Shopware nicht explizit um Performance kümmerst, wird sie zum Problem. Aber nicht zum unlösbaren.
Wir bauen seit 2012 Shopware Shops und haben die gleichen Performance-Probleme in zahlreichen Projekten gesehen. Die gute Nachricht: Die meisten lassen sich beheben. Manchmal mit Konfiguration, manchmal mit echtem Engineering. Dieser Guide zeigt dir beides.
Inhalt
- Warum Performance in E-Commerce wirklich zählt
- Die 5 größten Performance-Killer in Shopware
- Server und Hosting: Was dein Stack braucht
- Caching-Strategie: HTTP, Varnish, Redis und Elasticsearch
- Frontend-Performance: Core Web Vitals und Lazy Loading
- Datenbank-Optimierung für große Kataloge
- Monitoring: So erkennst du Performance-Probleme früh
- Quick Wins: Fünf Dinge die sofort wirken
Warum Performance in E-Commerce wirklich zählt
Die Zahlen sind brutal. Eine Studie von Google zeigt dass jede zusätzliche Sekunde Ladezeit die Conversion-Rate um durchschnittlich 7% senkt. Bei einem Shop mit 1.000 Besuchern pro Tag sind das real verlorene Verkäufe.
Amazon hat es vorgemacht. Jede 100ms schneller bedeutet 1% mehr Revenue. Das war 2006. Die Erwartungen sind heute noch höher.
In Shopware sehen wir regelmäßig Shops mit Ladezeiten von 4-6 Sekunden. Das ist keine technische Schwäche der Plattform, sondern eine Konfigurationsfrage. Shopware kann extrem schnell sein. Oder langsam. Beides ist möglich.
Das Wichtigste: Performance ist kein Projekt das man "irgendwann macht". Es ist eine Entscheidung die beim Hosting anfängt und beim Code endet.
Die 5 größten Performance-Killer in Shopware
1. Shared Hosting und zu kleine Server
Das erste Problem sitzt im Keller. Wenn dein Shopware läuft auf einem Shared Hosting oder auf VPS mit 1GB RAM, dann kannst du alle anderen Optimierungen vergessen.
Shopware 6 ist ressourcenhungrig. Das ist nicht falsch, es ist die Realität einer modernen Plattform. Ein Katalog mit 10.000+ Produkten, Varianten, Kategorien und komplexe Geschäftslogik braucht CPU und RAM.
Minimum für einen ernstzunehmenden Shop: 4GB RAM, 2+ CPU Cores, SSD Storage. Für größere Kataloge (50.000+ Produkte): 8GB+ RAM, 4 CPU Cores. Das ist nicht teuer, aber es ist nicht optional.
2. Fehlende Caching-Layer
Shopware ohne Caching ist wie ein Auto ohne Rollen. Möglich, aber niemand macht es.
Die meisten Projekte laufen ohne HTTP-Cache-Proxy (Varnish) oder Redis. Das bedeutet dass jeder Request bis zu PHP durchläuft, jedes Mal. Das ist nicht nur langsam, das ist auch Verschwendung weil ein Shop zu 80-90% statische Inhalte ausliefert.
Mit HTTP-Cache kann dein Shop eine Produktseite in 50-100ms ausliefern statt in 500-800ms. Das ist keine kleine Verbesserung, das ist ein echter Wendepunkt.
3. Unkonfiguriertes Elasticsearch
Shopware nutzt Elasticsearch für die Produktsuche. Das ist smart. Elasticsearch ist schnell und kann eine komplexe Produktsuche mit Filtern, Facetten und Aggregationen millisekunden-schnell beantworten.
Aber: Die Standard-Konfiguration ist nicht optimiert. Wir sehen regelmäßig Shops wo die Suche 2-3 Sekunden braucht. Das ist nicht Elasticsearch, das ist eine veraltete Konfiguration oder ein viel zu großer Index mit ungefilterten Daten.
Eine richtig eingerichtete Suche sollte unter 200ms sein. Alles andere ist Performance-Geldverbrennung.
4. Unoptimierte Datenbank-Abfragen
Ein typischer Kategorie-Request in Shopware braucht 20-50 Queries. Das ist normal. Aber wenn diese Queries nicht gecacht sind und noch dazu schlecht optimiert, wird es zum Problem.
Häufige Fehler:
- Duplicate SQL Queries ohne Caching
- Fehlende Datenbank-Indizes
- N+1 Problem bei Produktvarianten-Abfragen
- Zu aggressive Joins auf große Tabellen
Das ist Developer-Arbeit, keine Konfiguration. Aber es macht den Unterschied zwischen "ok" und "schnell".
5. Bloated Frontend
Ein modernes Shopware Theme lädt oft 500KB+ JavaScript. Das ist nicht mehr normal, das ist technisch rückständig.
Häufige Sünden:
- Zu viele externe Skripte (Analytics, Marketing-Pixel, Ads)
- Kein Code-Splitting und kein Tree-Shaking
- Kritische CSS wird nicht extrahiert
- Bilder werden in Originalgröße geladen statt responsiv skaliert
Das sieht man sofort im PageSpeed Insights. Ein gut optimiertes Frontend sollte unter 150KB JavaScript sein. Alles andere ist Verschwendung.
Server und Hosting: Was dein Stack braucht
Ein schneller Shopware Stack sieht so aus:
Compute Layer:
- 4-8 CPU Cores (je nach Katalog-Größe und Traffic)
- 8-16GB RAM (wieder: je nach Last)
- SSD Storage (kein HDD, niemals)
Caching Layer:
- Redis für Session und Cache (obligatorisch)
- HTTP-Cache mit Varnish oder Nginx (stark empfohlen)
- Elasticsearch für Suche (eingebaut, muss aber konfiguriert sein)
Datenbank:
- MySQL 8.0+ oder MariaDB 10.5+
- Separate DB-Instanz, nicht auf dem selben Server
- Automatische Backups
CDN:
- Für statische Assets (CSS, JS, Bilder)
- CloudFront, Bunny, Cloudflare (alle gut)
- Das spart echte Sekunden beim Page Load
Monitoring:
- APM (Application Performance Monitoring) - New Relic, DataDog oder Sentry
- Damit siehst du nicht nur dass es langsam ist, sondern warum
Das beste Hosting ist eins bei dem diese Layer nicht "optional" sind, sondern Standard. Einen ausführlichen Überblick über passende Hosting-Optionen für Shopware findest du in unserem Artikel zum Shopware Hosting. Bei Projekten nutzen wir Hetzner Cloud, AWS oder Scale Commerce. Alle drei haben die Infrastruktur die Shopware braucht. Wenn du keine Infrastruktur selbst bauen willst: Scale Commerce ist Managed Premium mit dediziertem Support für genau diese Komplexität.
Caching-Strategie: HTTP, Varnish, Redis und Elasticsearch
Caching ist nicht eine Konfiguration, es ist eine Strategie. Shopware hat drei verschiedene Cache-Layer.
HTTP-Cache und Varnish
Das ist der erste und wichtigste Layer. HTTP-Caching ist nicht neu, aber in Shopware wird es oft übersehen.
Shopware sendet HTTP-Header (Cache-Control, ETag, Last-Modified) die dem Browser und Proxies sagen wie lange eine Seite gecacht werden darf. Produktseiten können 12-24 Stunden gecacht sein. Kategorien auch. Das ist nicht faul, das ist clever weil der Cache automatisch invalidiert wird wenn sich etwas ändert.
Mit Varnish (oder einem vergleichbaren HTTP-Cache-Proxy) wird das zur Waffe. Varnish läuft zwischen dem Internet und deinem Shopware und liefert gecachte Seiten direkt aus dem RAM. Das heißt: 50-100ms statt 500ms.
Die Konfiguration ist nicht trivial. Varnish braucht Custom VCL (Varnish Configuration Language) um zu verstehen wie Shopware Cache invalidiert. Aber einmal gemacht, ist es ein Auto-Pilot Feature das einfach funktioniert.
Redis für Sessions und Query Cache
Redis ist eine in-Memory Datenbank. Shopware nutzt es für zwei Dinge:
- Sessions - Jeder Request braucht eine Session. Mit Redis ist das in 5ms erledigt, mit Dateien dauert das 50-100ms.
- Query Cache - Häufige Datenbank-Abfragen werden in Redis gecacht. Das erspart echte Requests.
Konfiguration in Shopware:
REDIS_URL=redis://localhost:6379/0
REDIS_HOST=localhost
REDIS_PORT=6379
Das ist obligatorisch für jeden produktiven Shop. Nicht optional. Die Performance-Gewinne sind real.
Elasticsearch / OpenSearch für Suche
Shopware 6.5+ nutzt Elasticsearch (oder OpenSearch, die Open-Source Alternative) für die Produktsuche. Das ist gut. Elasticsearch kann komplexe Suchen in Millisekunden beantworten.
Der Standard-Index ist aber nicht optimiert. Größere Probleme:
- Zu viele Felder: Der Index speichert oft Daten die für die Suche nicht relevant sind (interne Metadaten, Admin-Felder). Das macht den Index unnötig groß.
- Ungefilterte Produkte: Viele Shops indexieren auch versteckte oder gelöschte Produkte. Das verlangsamt die Suche.
- Zu aggressive Analysatoren: Die Standard-Analyse für Text ist zu komplex. Ein einfacherer Analysator ist oft schneller und gibt bessere Ergebnisse.
Eine richtig konfigurierte Suche sollte bei 1M Produkten unter 200ms sein. Die meisten Shops liegen bei 800ms-2s. Das ist nicht Elasticsearch, das ist Misconfiguration.
Frontend-Performance: Core Web Vitals und Lazy Loading
Google hat 2021 die "Core Web Vitals" eingeführt als Ranking-Faktor. Das heißt: Langsame Seiten ranken schlecht. Das ist nicht optional.
Core Web Vitals erklärt
Largest Contentful Paint (LCP): Wie schnell wird der Hauptcontent sichtbar? Ziel: unter 2.5 Sekunden.
Interaction to Next Paint (INP): Wie responsiv ist die Seite auf Nutzer-Input? Ziel: unter 200ms.
Cumulative Layout Shift (CLS): Springt die Seite beim Laden herum? Ziel: unter 0.1.
In Shopware sehen wir häufig:
- Schlechtes LCP weil Bilder nicht verzögert geladen werden
- Schlechtes INP weil JavaScript zu groß ist oder synchron lädt
- Schlechtes CLS weil Ads oder Icons später laden und Layout verschieben
Die Fixes sind nicht kompliziert, brauchen aber Aufmerksamkeit.
Konkrete Optimierungen
Lazy Loading für Bilder:
<img src="product.jpg" loading="lazy" width="200" height="200">
Das ist ein von Haus aus verfügbares Browser-Feature seit 2019. Bilder außerhalb des Viewports werden erst geladen wenn der User scrollt. Das spart massive Bandbreite beim initialen Page Load.
Critical CSS Extraction:
CSS das "above the fold" benötigt wird sollte inline im <head> sein, der Rest kann async geladen werden. Das ändert LCP radikal.
Code-Splitting: Statt eine 500KB JavaScript Datei zu laden, lädt man nur was man braucht:
- Theme-Code für Kategorie-Seite
- Produkt-Code für Produkt-Seite
- Checkout-Code nur im Checkout
Das senkt das JavaScript auf der Kategorie-Seite von 500KB auf 150KB. Das ist ein realer Impact.
Responsive Images:
<img srcset="small.jpg 600w, medium.jpg 1200w, large.jpg 1920w"
sizes="(max-width: 600px) 100vw, 50vw">
Ein Handy lädt nicht die 1920px Version, sondern die 600px Version. Das spart 80% Bandbreite auf Mobile.
Datenbank-Optimierung für große Kataloge
Die Datenbank ist oft der stumme Performance-Killer. 20.000 SQL Queries pro Pageload, aber alle dauern nur kurz. Addieren tut sich das zu 3 Sekunden.
Richtige Indizes
Das erste ist dass MySQL die richtigen Indizes hat. Standard:
-- Product Table Indizes
ALTER TABLE product ADD INDEX idx_active (active);
ALTER TABLE product ADD INDEX idx_sales (sales);
ALTER TABLE product ADD INDEX idx_created (created_at);
ALTER TABLE product_category ADD INDEX idx_product_id (product_id);
Eine Product-Tabelle mit 100.000+ Produkten braucht mindestens diese Indizes. Ohne sie wird jede Query ein Full Table Scan. Mit ihnen 10-50ms.
Richtige Konfiguration
MySQL/MariaDB Standard-Konfiguration ist nicht für Performance optimiert. Die wichtigsten Tuning-Parameter:
innodb_buffer_pool_size: Sollte 70-80% des RAM sein. Das ist der Cache für die Datenbank-Pages.max_connections: Nicht zu niedrig, nicht zu hoch. Bei 4-8 Application Servers: 100-200.slow_query_log: Loggt alle Queries langsamer als X Millisekunden. Das ist dein Debugging-Werkzeug.
Beispiel für einen 8GB Server:
[mysqld]
innodb_buffer_pool_size = 6G
innodb_log_file_size = 512M
max_connections = 150
query_cache_type = 0
query_cache_size = 0
Das ist keine Zauberei, aber es kostet 30 Minuten einmalig und spart dir echte Performance.
N+1 Queries eliminieren
Das N+1 Problem ist klassisch. Du lädst 100 Produkte, dann für jedes Produkt separat die Kategorien. Das sind 101 Queries statt 1.
In Shopware sieht man das oft bei Variant-Abfragen:
// Falsch: 1 + N Queries
$products = $repository->findAll();
foreach ($products as $product) {
$product->getVariants(); // Zusätzlicher Query pro Produkt
}
// Richtig: 1 Query mit eager loading
$products = $repository->findAll(['variants']); // Association eager-loaded
Das ist Developer-Arbeit, aber kritisch für große Kataloge.
Monitoring: So erkennst du Performance-Probleme früh
Ein Shop ohne Monitoring ist wie ein Auto ohne Tacho. Du weißt nicht ob du schnell fährst oder langsam.
Tools die du brauchst
PageSpeed Insights (Kostenlos): Google-Tool, misst Core Web Vitals echte Nutzer. Das solltest du mindestens wöchentlich checken.
New Relic oder DataDog: Zeigt dir nicht nur dass dein Shop langsam ist, sondern warum. Welcher Code ist slow? Welche Database-Queries fressen CPU?
Sentry: Zeigt JavaScript-Fehler und Performance-Probleme auf der Browser-Seite.
Custom Monitoring im Code:
$start = microtime(true);
$products = $this->productRepository->search($criteria);
$duration = microtime(true) - $start;
if ($duration > 1000) { // Länger als 1 Sekunde
$this->logger->warning('Slow product search: ' . $duration . 'ms');
}
Das ist kein Overkill, das ist Standard bei ernstzunehmenden Shops.
Die KPIs die zählen
- P95 Ladezeit: 95% aller Requests sind schneller als X Sekunden. Das ist aussagekräftiger als der Durchschnitt.
- First Input Delay (FID) / INP: Wie responsiv ist die Seite wirklich?
- Error Rate: Wie viel % der Requests crashen?
- Database Query Duration: Die Summe aller Query-Zeiten pro Request.
Diese vier sollten auf einem Dashboard sichtbar sein. Täglich gecheckt. Nicht wöchentlich.
Quick Wins: Fünf Dinge die sofort wirken
Du hast 2 Stunden Zeit? Dann mach diese fünf Dinge:
1. Redis aktivieren (15 Minuten)
# .env
REDIS_URL=redis://127.0.0.1:6379/0
SHOPWARE_CACHE_ID=sw6
SESSION_HANDLER=redis
Und Redis starten:
docker run -d -p 6379:6379 redis:7-alpine
Danach: Cache leeren. Das ist echte Performance ohne Code-Änderungen.
2. Bilder Lazy Loading (20 Minuten)
In deinem Theme, alle <img> Tags mit loading="lazy" versehen. Das ist von Haus aus im Browser verfügbar seit 2019.
<img src="{{ product.image }}" loading="lazy" alt="{{ product.name }}">
Das ist sofort messbar. Seiten laden 30-50% schneller.
3. HTTP Cache aktivieren (10 Minuten)
Shopware hat einen HTTP Cache den man ausschalten kann. Das ist standardmäßig an, aber nicht richtig optimiert.
// config/services.yaml
parameters:
shopware.cache:
invalidation:
product: true
category: true
media: true
Damit werden Produktseiten 24 Stunden gecacht. Das ist echte Magie.
4. Datenbank-Indizes prüfen (30 Minuten)
-- Alle Indizes checken
SELECT * FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = 'shopware' AND TABLE_NAME = 'product';
Falls nicht da: die oben erwähnten Indizes hinzufügen. Das ist keine Zauberei, aber es wirkt.
5. JavaScript minimiert? (5 Minuten)
# Konfiguration in theme.json
"script": "dist/storefront.min.js"
Falls noch nicht: Die Theme-Dateien müssen minified sein. Das ist eine Zeile Config.
Diese fünf Dinge zusammen: 30-50% schneller. Nicht übertrieben. Echt.
Fazit: Performance ist nicht Luxus
Performance ist nicht etwas das man "später optimiert". Es ist eine Entscheidung die am Anfang getroffen wird: Welcher Host? Welche Caching-Strategie? Welche Monitoring-Tools?
Shopware kann unfassbar schnell sein. 1-2 Sekunden Ladezeit auch auf großen Katalogen. Das braucht aber:
- Den richtigen Host (nicht Billigware)
- Die richtige Architektur (HTTP Cache, Redis, Elasticsearch)
- Sorgfalt im Detail (Lazy Loading, Code-Splitting, Datenbankoptimierung)
- Kontinuierliches Monitoring
Die Alternative ist ein langsamer Shop der Conversion-Rate kostet. Jeden Tag. Das ist keine Verbesserung, das ist Standard.