Shopware Performance optimieren: Nginx, Varnish-Cache und Elasticsearch richtig konfigurieren

Warum Shopware Performance heute an der Server-Architektur hängt

Wenn ein Shopware-Shop „langsam“ wirkt, ist das selten nur ein Frontend-Thema. In der Praxis sind es meist drei Engpässe, die sich gegenseitig verstärken: hohe Time-to-First-Byte (TTFB) durch fehlendes oder falsch konfiguriertes HTTP-Caching, unnötige Last auf PHP-FPM/Applikation durch fehlende Reverse-Proxy-Entkopplung und eine träge Suche durch suboptimales Elasticsearch-Tuning. Die gute Nachricht: Mit einer sauberen Kette aus Nginx als Reverse Proxy, Varnish als HTTP-Cache und Elasticsearch für schnelle Suche lässt sich die Shopware Performance oft deutlich verbessern, ohne dass man sofort Code anfassen muss.

Dieser Leitfaden zeigt eine praxiserprobte Zielarchitektur, konkrete Konfigurationsbausteine und typische Stolperfallen: Cache-Invalidierung, Cookies, ESI, Grace Mode, Timeouts und Debugging von HIT/MISS. Am Ende findest du eine Checkliste, um die Performance in Produktion messbar abzusichern.

Zielarchitektur: Nginx vor Varnish vor Shopware

Bewährt hat sich folgende Reihenfolge:

• Nginx als Edge/Reverse Proxy (TLS-Termination, HTTP/2/3 je nach Setup, Security-Header, Rate-Limits, statische Assets, Kompression).

• Varnish als HTTP-Cache für Cacheable Pages (Kategorie, Produkt, CMS-Seiten, ggf. Teile via ESI).

• Shopware (PHP-FPM) als Origin/Backend (liefert Inhalte, setzt Cache-Header, triggert Purges/Invalidierungen).

• Elasticsearch separat (Suche, Filter, Aggregationen).

Wichtig: Nginx und Varnish haben unterschiedliche Aufgaben. Nginx ist ideal für TLS, statische Dateien und als „Front Door“. Varnish ist der Spezialist für HTTP-Caching, VCL-Logik, Grace Mode und sehr schnelle Auslieferung bei hoher Parallelität.

Schritt 1: Messen, bevor du optimierst (Baseline)

Ohne Baseline optimierst du im Blindflug. Miss mindestens:

• TTFB (Start Render ist nett, aber TTFB zeigt dir Cache- und Backend-Probleme sofort).

• Cache HIT/MISS (Header-basiert und über Varnish-Logs).

• Search-Latenz (z. B. P95 für typische Suchanfragen und Filterkombinationen).

• Backend-Fehler/Timeouts (502/504, PHP-FPM slowlog, Elasticsearch GC/Threadpools).

Tools: WebPageTest (TTFB, Waterfall), Lighthouse (Lab), Real User Monitoring (RUM) für Feldwerte, und serverseitig varnishstat/varnishlog sowie Elasticsearch Monitoring.

Schritt 2: Nginx als Reverse Proxy sauber aufsetzen

Nginx sollte vor allem stabil und vorhersehbar sein: TLS terminieren, Requests sauber an Varnish weiterreichen, statische Assets direkt ausliefern und sinnvolle Timeouts setzen. Zwei typische Fehlerquellen sind (1) zu kurze Timeouts bei langsamen Backends und (2) falsches Forwarding von Host/Proto, was zu Redirect-Loops oder falschen Canonicals führen kann.

Minimaler Nginx-Proxy-Block (Konzept)

Die Details variieren je nach Deployment, aber diese Punkte sind zentral:

• proxy_set_header Host und X-Forwarded-Proto korrekt setzen.

• proxy_read_timeout nicht zu knapp (Checkout/Import/Heavy Pages berücksichtigen).

• Statische Dateien (z. B. /theme, /media) möglichst direkt über Nginx ausliefern, mit Cache-Control.

• Gzip/Brotli sinnvoll aktivieren (Brotli wenn verfügbar), aber nicht „blind“ für alles.

Praxis-Tipp: Wenn du Varnish einsetzt, sollte Nginx für dynamische Seiten nicht selbst cachen (kein zusätzliches Microcaching), außer du weißt genau, warum und wie du es invalidierst. Doppelte Cache-Schichten erschweren Debugging und Cache-Kohärenz.

Schritt 3: Varnish für Shopware richtig konfigurieren (Cache-Regeln, Cookies, Grace)

Varnish ist der größte Hebel für TTFB. Der Knackpunkt ist: Shopware-Seiten sind nur dann cachebar, wenn (a) die richtigen Cache-Header gesetzt sind und (b) du in VCL sauber zwischen „anonym“ und „personalisiert“ trennst. Die häufigsten Ursachen für schlechte HIT-Rates sind Cookies, die unnötig auf allen Requests mitgeschickt werden, sowie fehlende Ausnahmen für Login/Checkout.

Cache-Strategie: Was darf in den Cache?

• Cachebar: Startseite, Kategorien, Produktdetailseiten, CMS-Seiten, Blog/Content (sofern nicht personalisiert).

• Nicht cachebar: Warenkorb, Checkout, Kundenkonto, Login, Wunschliste (je nach Implementierung), alle Seiten mit personalisierten Preisen/Regeln.

• Teilweise cachebar: Seiten mit kleinen personalisierten Fragmenten (z. B. Mini-Cart) via ESI oder clientseitigem Nachladen.

Stolperfalle: Cookies killen deinen Cache

Varnish betrachtet Requests mit Cookies oft als „potenziell personalisiert“. In Shopware-Setups sind Cookies für Session, Consent, Tracking etc. üblich. Viele davon sind für die HTML-Auslieferung irrelevant und sollten für cachebare Routen entfernt oder ignoriert werden. Ziel: Für anonyme Besucher sollen HTML-Seiten ohne „cache-busting“ Cookies ausgeliefert werden.

Beispiel-VCL: Shopware-spezifische Ausnahmen und Cookie-Bereinigung

Das folgende Snippet zeigt typische Muster: Checkout und Account werden durchgereicht, irrelevante Cookies werden entfernt, und Grace Mode wird aktiviert, um bei Backend-Spikes trotzdem schnell auszuliefern.

sub vcl_recv {
  if (req.method != "GET" && req.method != "HEAD") {
    return (pass);
  }

  if (req.url ~ "^/(account|checkout|cart|api)") {
    return (pass);
  }

  if (req.http.Cookie) {
    set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_ga|_gid|_gcl_au|cookie_consent|consent|tracking)=[^;]*", "");
    set req.http.Cookie = regsuball(req.http.Cookie, "^;\s*|;\s*$", "");
    if (req.http.Cookie == "") {
      unset req.http.Cookie;
    }
  }
}

sub vcl_backend_response {
  set beresp.grace = 2m;
  if (beresp.status >= 500) {
    set beresp.ttl = 0s;
    return (deliver);
  }
}

Wichtig: Cookie-Namen und Pfade sind projektspezifisch. Entferne nur Cookies, die garantiert keine Personalisierung beeinflussen. Bei B2B-Shops mit kundenspezifischen Preisen ist die Trennung „anonym vs. eingeloggt“ besonders kritisch.

Grace Mode: Stabilität bei Lastspitzen

Grace Mode erlaubt, abgelaufene Objekte noch kurz auszuliefern, wenn das Backend langsam ist oder Fehler liefert. Das ist ein echter Produktions-Retter: Statt dass TTFB explodiert oder 503/504 auftreten, liefert Varnish „stale“ Inhalte und aktualisiert im Hintergrund (je nach Konfiguration). Für Shops mit Kampagnen-Traffic ist das oft wichtiger als die letzte Sekunde Aktualität.

ESI: Nur einsetzen, wenn du es wirklich brauchst

ESI (Edge Side Includes) kann personalisierte Fragmente (z. B. Mini-Cart) aus dem Cache herauslösen. Der Trade-off: mehr Komplexität, mehr Requests, mehr Debugging-Aufwand. Wenn du ESI nutzt, achte auf:

• Timeouts für ESI-Subrequests (sonst blockiert ein Fragment die ganze Seite).

• Cachebarkeit der Fragmente (kurze TTLs sind ok, aber nicht „no-store“ ohne Grund).

• Fehlerverhalten: Fragment darf die Seite nicht komplett brechen.

Cache-Invalidierung: Purge/Ban sauber planen

Ein HTTP-Cache ist nur so gut wie seine Invalidierung. Typische Fälle: Produkt geändert, Preis geändert, Kategoriezuordnung geändert, CMS-Seite aktualisiert. Du brauchst eine Strategie, wie Shopware den Cache invalidiert (z. B. Purge/Ban nach Tags oder URLs). Häufige Stolperfallen:

• Zu grobe Purges (z. B. alles löschen) führen zu Cache-Cold-Starts und schlechter TTFB nach Deployments.

• Zu feine Purges (nur eine URL) übersehen abhängige Seiten (Kategorie, Landingpages, Cross-Selling).

• Fehlende Auth für Purge-Endpunkte ist ein Security-Risiko.

Praxis-Tipp: Plane nach Deployments einen kontrollierten Cache Warmup (Startseite, Top-Kategorien, Top-Produkte, Suchseiten), damit der erste echte Nutzer nicht den Cold-Cache bezahlt.

Schritt 4: Timeouts und Buffering zwischen Nginx, Varnish und Backend abstimmen

Viele Performance-Probleme sind eigentlich Timeout-Mismatches. Beispiele:

• Nginx wartet 60s, Varnish nur 30s: Varnish bricht ab, Nginx liefert 503/504.

• Varnish wartet lange, PHP-FPM ist aber am Limit: Requests stauen sich, Backend wird „zäh“.

• Elasticsearch antwortet langsam, Shopware blockiert, Varnish kann nicht füllen.

Empfehlung: Definiere Zielwerte (z. B. 95% der uncached HTML-Requests < 800ms) und setze Timeouts so, dass sie realistisch darüber liegen, aber nicht unendlich. Ergänze Circuit-Breaker-Logik über Grace Mode und sinnvolle Retry-Strategien (vorsichtig mit Retries bei POST).

Schritt 5: Elasticsearch für Shopware Suche optimieren

Eine schnelle Suche ist nicht nur „nice to have“: Filter, Aggregationen und Suggest beeinflussen Conversion direkt. Typische Symptome schlechter Elasticsearch-Performance sind: hohe Latenz bei Filterkombinationen, Timeouts bei großen Indizes und CPU-Spikes durch häufige Refreshes oder zu kleine Heaps.

Heap und JVM: Stabil vor schnell

• Setze den Heap nicht zu klein (GC thrash) und nicht zu groß (lange GC-Pausen). Als Faustregel wird oft ~50% RAM bis zu einem sinnvollen Maximum genutzt; beachte aber die konkrete Node-Größe und Workload.

• Behalte genügend RAM für File System Cache (wichtig für Lucene).

Refresh Interval und Indexing-Last

Wenn du häufige Produktupdates/Imports hast, kann ein zu aggressives Refresh Interval die Suche ausbremsen. Für Bulk-Indexing kann es sinnvoll sein, temporär das Refresh Interval zu erhöhen und danach wieder zurückzustellen. Das ist besonders relevant bei Reindexing oder großen Preis-/Bestandsupdates.

Konkrete Checks für Shopware-Suche

• Shard/Replica-Planung: Zu viele Shards erhöhen Overhead, zu wenige können Hotspots erzeugen.

• Query-Profiling: Identifiziere langsame Aggregationen (z. B. Preisfilter, Variantenattribute).

• Timeouts: Stelle sicher, dass Shopware und Reverse Proxies nicht zu früh abbrechen.

• Monitoring: GC, Heap Usage, Search Threadpool Queue, Slow Logs.

Schritt 6: Troubleshooting: Cache HIT/MISS, Login/Checkout-Ausnahmen, Warmup

HIT/MISS sichtbar machen

In der Praxis brauchst du schnelle Antworten: „Kommt die Seite aus Varnish oder aus dem Backend?“ Setze dafür Debug-Header (nur intern/whitelist!) und nutze Varnish-Tools. Beispiel: varnishlog zeigt dir, warum ein Request gepasst wurde (Cookie, Authorization, URL-Regel).

Typische Ursachen für MISS

• Set-Cookie im Response: Viele Setups verhindern dann Caching (zu Recht). Prüfe, ob Shopware oder ein Plugin unnötig Cookies setzt.

• Cache-Control: private/no-store: Kann korrekt sein (Account), aber falsch bei Content-Seiten.

• Vary auf zu vielen Headern: Zerstückelt den Cache (z. B. Vary: User-Agent ohne Not).

• Cookies im Request: Siehe Cookie-Bereinigung.

Login/Checkout-Ausnahmen korrekt behandeln

Diese Bereiche müssen zuverlässig „pass“ sein. Achte darauf, dass nicht nur die offensichtlichen Pfade ausgenommen sind, sondern auch AJAX-Endpunkte, die Warenkorb/Session beeinflussen. Gleichzeitig sollten anonyme Seiten nicht aus Versehen „pass“ werden, nur weil ein Consent- oder Tracking-Cookie existiert.

Warmup nach Deployments

Ein kontrollierter Warmup reduziert TTFB-Spitzen nach Releases. Warmup ist kein „SEO-Crawler“, sondern ein internes Tooling, das definierte URLs anfragt. Wichtig: Warmup sollte ohne Cookies laufen und idealerweise aus dem internen Netz kommen, damit Debug-Header nicht nach außen gelangen.

Mess- und Betriebs-Checkliste für Produktion

• TTFB-Zielwerte definiert (Cache HIT vs. MISS getrennt).

• Varnish HIT-Rate überwacht (z. B. pro Route/Device/Locale).

• Debug-Header nur intern aktiv (IP-Whitelist).

• Cookie-Policy dokumentiert: welche Cookies sind cache-relevant?

• Grace Mode aktiv und getestet (Backend down/slow Simulation).

• Purge/Invalidierung sicher (authentifiziert) und vollständig (Abhängigkeiten).

• Timeouts abgestimmt (Nginx ↔ Varnish ↔ Backend ↔ Elasticsearch).

• Elasticsearch Monitoring aktiv (Heap, GC, Threadpools, Slow Logs).

• Warmup nach Deployments automatisiert (Top-URLs, Suchseiten).

• Load-Test vor Peak-Events (Kampagnen, Black Friday) inkl. Cache-Warm-Szenario.

Kurze Praxis-Kommandos für Diagnose

Diese Kommandos helfen dir, Cache-Verhalten und Systemzustand schnell zu prüfen. Passe Hostnames/Ports an dein Setup an.

Fazit: Shopware Performance ist ein Zusammenspiel aus Cache-Logik, Timeouts und Such-Tuning

Die größten Performance-Gewinne entstehen meist nicht durch „mehr Server“, sondern durch eine klare Trennung der Verantwortlichkeiten: Nginx als stabiler Reverse Proxy, Varnish als intelligenter HTTP-Cache mit sauberer Cookie-Strategie und Grace Mode, sowie Elasticsearch als gezielt getunte Suchmaschine. Wenn du Baselines misst, Cache-Regeln Shopware-spezifisch definierst und Invalidierung/Warmup als festen Teil deines Release-Prozesses behandelst, bekommst du nachhaltig bessere TTFB, stabilere Peaks und eine spürbar schnellere Suche.