Stand: Juli 2026
Die Cache-Quote (Hit-Rate) ist die eine Zahl, die über die gefühlte Geschwindigkeit eines Shops entscheidet: Welcher Anteil der Anfragen wird aus dem Cache beantwortet — und welcher muss durchs volle Backend? Der Unterschied ist kein Feintuning, sondern eine Größenordnung: In unserer Labormessung liefert dieselbe Shopware-Instanz eine Produktseite in 0,26 s aus dem Cache und braucht 0,7 bis 8,5 s für den vollen Render. Eine Quote von 99 % gegenüber 90 % bedeutet: zehnmal weniger langsame Seitenaufrufe.
Wer die Quote nicht misst, optimiert blind. Die gute Nachricht: Messen ist einfacher, als die meisten denken — es braucht nur curl.
Der Age-Header: Hit-Erkennung ohne Werkzeuge
Jeder HTTP-Cache nach Standard (Shopware-HTTP-Cache, Varnish, CDNs) schickt den Age-Header mit: die Sekunden, die das Objekt schon im Cache liegt.
curl -sI https://www.example-shop.de/ | grep -i '^age'
# age: 286 ← Antwort kam aus dem Cache (seit 286 s drin)
# age: 0 ← gerade erst gespeichert: das war ein MISS
# (kein age) ← Cache nicht beteiligtDie Falle, in die wir im Labor selbst kurz getappt sind: Age: 0 ist kein Hit. Der Header erscheint auch beim frischen Speichern. Die Regel lautet: Age > 0 = Hit, Age: 0 oder fehlend = Miss. Damit lässt sich mit einer Schleife und einer URL-Liste (die Sitemap!) in fünf Minuten eine ehrliche Quote messen — genau so sind die Zahlen in unserem Beitrag zum 6.8-Cache entstanden.
Bei Varnish kommt die Betriebs-Sicht dazu: varnishstat zeigt cache_hit und cache_miss als laufende Zähler — die Quote des echten Traffics, nicht nur der Stichprobe.
Was eine „gute“ Quote ist
Es gibt keine Norm-Zahl, aber belastbare Faustwerte für Shop-Traffic: Unter 80 % arbeitet der Cache gegen sich selbst (zu kurze TTL, zersplitterte Varianten, zu viel ausgeschlossen). 90–95 % ist solide. Ab 98 % rennt der Shop — dann bestimmen fast nur noch Cache-Antwortzeiten das Nutzererlebnis. Wichtig ist die Blickrichtung: Nicht der Durchschnitt zählt, sondern wer die Misses abbekommt — wenn es immer die Kategorieseiten nach einer Preispflege trifft, hilft der schönste Durchschnitt nichts.
Die drei Quoten-Killer
1. Invalidierung. Jede Produktänderung wirft potenziell Cache-Einträge weg — Detailseite, Listings, Suchergebnisse. Ein Shop mit stündlicher Warenwirtschafts-Synchronisation kann sich seine Quote komplett zerschießen. Deshalb sammelt Shopware Invalidierungen inzwischen standardmäßig und arbeitet sie verzögert ab (delay_enabled: true seit 6.7 Standard). Die Betriebsfalle dabei: Der Abbau läuft über Scheduled Tasks — ohne laufenden Worker wird nie invalidiert, bis die TTL abläuft. Beides gehört überwacht (etwa mit FroshTools: überfällige Tasks sind dort ein Ampel-Check).
2. Varianten-Zersplitterung. Jede Dimension im Cache-Schlüssel vervielfacht die Einträge: Encodings (die Vary-Falle), Währungen, Kundengruppen, Kontext-Regeln. Zehn Varianten heißt: jede Seite muss zehnmal warm werden — die Quote sinkt, obwohl der Cache „funktioniert“. Genau hier setzt Shopware 6.8 an und entrümpelt den Schlüssel radikal.
3. Ausgeschlossene Nutzergruppen. Bis Shopware 6.7 umgehen eingeloggte Kunden den Cache komplett — im Labor messbar: 0,26 s anonym gegen 0,85 s eingeloggt, bei jedem Klick. Ein B2B-Shop, dessen Kundschaft eingeloggt bestellt, hat effektiv Quote null, egal was varnishstat für den anonymen Traffic meldet. Auch das ändert 6.8.
Quote im Blick behalten
Für den Dauerbetrieb reichen drei Handgriffe: die curl-Stichprobe über die Sitemap (wöchentlich, nach Deploys), varnishstat/Cache-Statistiken als Trendkurve, und ein Blick auf die p75-Antwortzeiten in den Felddaten — steigt der LCP, ohne dass sich am Frontend etwas geändert hat, ist oft die Quote gekippt. Wie man den Cache nach Deploys gar nicht erst kalt werden lässt, steht im Cache-Warming-Leitfaden.
Die Labor-Zahlen stammen aus unserer Messreihe zu Shopware 6.8: „cached (fast) alles“ — zwei identische Instanzen, 200 identische Produkte, Age-Header-Methode.