Shopware 6.7.6: HTTP Caching Rework und der Roadmap-Shift zu 6.8

Das Januar-Release Shopware 6.7.6.0 markiert einen technischen Wendepunkt: Das experimentelle HTTP Caching Rework führt ein Policy-basiertes System ein, das feingranulare Cache-Kontrolle pro Route ermöglicht – verbunden mit PHP 8.5 Support und massiven Store API Verbesserungen. Parallel verschiebt Shopware die nächste Major-Version 6.8 von 2026 auf 2027, verlängert Extended Support für 6.6 und fokussiert sich auf Stabilität, Performance und Agentic AI Features. Für Agenturen und technische Leiter bedeutet das: Mehr Zeit für Migration, stabiles Fundament für laufende Projekte und die Chance, das neue Caching-System bereits jetzt zu testen – bevor es in 6.8 zum Standard wird.

Das Problem: Shopware's traditionelles HTTP Caching erreicht seine Grenzen

Shopware's bisheriges Caching-System basiert auf dem Symfony HttpCache mit hardcodierten Cache-States über sw-states und sw-currency Cookies. Die zentrale Problematik: Cache wird pauschal deaktiviert, sobald ein Nutzer eingeloggt ist oder der Warenkorb gefüllt wird. Das führt in der Praxis zu dramatischen Performance-Einbußen bei authentifizierten Sessions.

Die technischen Schwachstellen im Detail:

1. Binary Cache States: Der CacheStateSubscriber kennt nur "vollständig cacheable" oder "komplett uncacheable" – keine Zwischenstufen für teilweise dynamische Inhalte
2. Hardcodierte Cache-Control Headers: Die Werte für max-age und s-maxage sind in PHP-Klassen verdrahtet, Anpassungen erfordern Core-Patches oder komplexe Event-Subscriber
3. Ineffiziente Cache-Invalidierung: Bei Produktänderungen werden oft ganze Cache-Bereiche gelöscht statt gezielter Tags
4. Store API Caching-Lücken: Die meisten Store API Endpoints liefern keine Cache-Control Header, jede Anfrage trifft die Datenbank
5. Rule-basierte Cache-Fragmentation: Shopware Rules führen zu hunderten Cache-Varianten, selbst wenn nur wenige tatsächlich unterschiedliche Inhalte liefern

Ein konkretes Beispiel aus der Praxis: Ein mittelgroßer B2C-Shop mit 15.000 Produkten und 5 Kundengruppen generiert theoretisch 75.000 mögliche Cache-Varianten pro Seite – bei 200 Seiten ergeben sich 15 Millionen potenzielle Cache-Einträge. Das alte System kann diese Komplexität nicht effizient handhaben.

Die Performance-Auswirkungen sind messbar: Bei eingeloggten Nutzern sinkt die Response-Time von durchschnittlich 120ms (gecacht) auf 850-1.200ms (ungecacht) – ein Faktor von 7-10x. Bei Traffic-Spitzen über 100 gleichzeitige Requests kollabiert die Performance komplett, da jede Anfrage Backend-Berechnungen triggert.

Shopware 6.7.6.0: Das neue HTTP Caching Policy-System

Das mit dem CACHE_REWORK Feature-Flag aktivierbare System führt ein deklaratives Policy-Modell ein, das Cache-Verhalten über YAML-Konfiguration steuert statt über PHP-Code. Die Kern-Innovation: Cache-Kontrolle erfolgt auf Routing-Ebene, nicht mehr auf Applikations-State-Ebene.

Die technische Architektur

Das neue System basiert auf drei Komponenten:

1. Caching Policies (YAML-Konfiguration)

In config/packages/shopware.yaml definiert ihr benannte Policies mit standardisierten Cache-Control Directives:

shopware:
    cache:
        policies:
            # Policy für statische Content-Seiten
            static_content:
                public: true
                max_age: 3600          # Browser-Cache: 1 Stunde
                s_maxage: 7200         # Shared Cache (CDN): 2 Stunden
                stale_while_revalidate: 300
                
            # Policy für Produktlisten mit häufigen Updates
            product_listing:
                public: true
                max_age: 300           # Browser: 5 Minuten
                s_maxage: 900          # CDN: 15 Minuten
                must_revalidate: true
                
            # Policy für personalisierte Bereiche
            personalized:
                private: true          # Nur Browser-Cache
                max_age: 60            # 1 Minute
                no_store: false        # Cache erlaubt, aber privat
                
            # Policy für völlig dynamische Inhalte
            no_cache:
                no_cache: true
                no_store: true
                must_revalidate: true

2. Policy-Zuweisung pro Area und Route

Policies werden hierarchisch zugewiesen – erst per Area (Storefront, Store API), dann spezifisch per Route:

shopware:
    cache:
        # Default-Policy für gesamte Storefront
        storefront:
            default_policy: static_content
            route_policies:
                # Homepage: Aggressives Caching
                'frontend.home.page': static_content
                
                # Produktdetailseiten: Moderate Cache-Zeit
                'frontend.detail.page': product_listing
                
                # Warenkorb: Kurze Cache-Zeit
                'frontend.checkout.cart.page': personalized
                
                # Checkout: Kein Cache
                'frontend.checkout.confirm.page': no_cache
                
        # Store API mit eigenen Policies
        store_api:
            default_policy: product_listing
            route_policies:
                # Navigation ist hochgradig cacheable
                'store-api.navigation.load': static_content
                
                # Produktsuche: Moderate Zeiten
                'store-api.product.search': product_listing
                
                # Context-Switch: Kein Cache
                'store-api.context.update': no_cache

3. Der sw-cache-hash Cookie

Das alte Multi-Cookie-System (sw-states, sw-currency, etc.) wird durch einen einzelnen sw-cache-hash Cookie ersetzt. Dieser Hash repräsentiert den relevanten Context-State für Cache-Decisions:

// Beispiel Hash-Berechnung (vereinfacht)
$hash = md5(implode('|', [
    $context->getSalesChannelId(),
    $context->getCurrencyId(),
    $context->getCustomerGroupId(),
    $context->getLanguageId(),
    // Rule-IDs werden nur hinzugefügt, wenn sie Cache-relevant sind
    implode(',', $context->getCacheRelevantRuleIds())
]));

// Cookie: sw-cache-hash=a3f2b1c9d8e7f6g5h4i3

Der Hash wird bei Context-Änderungen neu berechnet. Kritisch: Im Gegensatz zum alten System bleiben eingeloggte User und gefüllte Warenkörbe cacheable – der Hash differenziert nur bei tatsächlich unterschiedlichen Cache-Anforderungen.

Store API Caching: Die wichtigste Performance-Verbesserung

6.7.6.0 markiert die ersten Store API Endpoints als cacheable und liefert korrekte Cache-Control Header. Die aktivierten Endpoints:

1. /store-api/navigation/{activeId}/{rootId} – Navigation-Strukturen
2. /store-api/category/{categoryId} – Kategorie-Details
3. /store-api/cms/{id} – CMS-Seiten-Content
4. /store-api/product (GET) – Produktlisten
5. /store-api/product/{productId} – Produktdetails
6. /store-api/product-review – Produkt-Bewertungen

Diese Endpoints liefern jetzt Header wie:

Cache-Control: public, s-maxage=900, max-age=300, stale-while-revalidate=300
Vary: sw-cache-hash

Der Vary: sw-cache-hash Header sorgt dafür, dass Reverse Proxies (Varnish, Fastly, Cloudflare) separate Cache-Einträge pro Hash-Wert vorhalten.

Für Headless-Setups ist zusätzlich wichtig: Store API Clients müssen den sw-cache-hash Cookie bei jeder Anfrage mitsenden. Fehlt der Cookie, wird ein neuer Hash generiert und als Set-Cookie Header zurückgeliefert. JavaScript-Clients sollten diesen Cookie persistent speichern:

// Fetch-Beispiel mit Cookie-Handling
const response = await fetch('/store-api/product', {
    credentials: 'include',  // Sendet sw-cache-hash Cookie mit
    headers: {
        'sw-access-key': 'YOUR_ACCESS_KEY'
    }
});

// Set-Cookie Header auslesen und für Folge-Requests speichern
const setCookie = response.headers.get('set-cookie');
if (setCookie && setCookie.includes('sw-cache-hash')) {
    // Cookie wurde aktualisiert, Store für nächste Requests
}

Breaking Changes und Migration-Aufwand

Das neue System ist backward-compatible mit deaktivertem Feature-Flag, bringt aber Breaking Changes für Extensions, die Cache-Verhalten manipulieren:

Deprecated Environment Variables (werden in 6.8 entfernt):

1. SHOPWARE_HTTP_CACHE_ENABLED – Ersetzt durch Policy-System
2. SHOPWARE_HTTP_DEFAULT_TTL – Ersetzt durch max_age in Policies
3. SHOPWARE_HTTP_CACHE_DEFAULT_TTL – Ersetzt durch s_maxage

Betroffene Extensions:

Extensions, die dynamische Inhalte für eingeloggte User anzeigen (z.B. "Hallo, [Username]" Banner), müssen angepasst werden. Zwei Lösungswege:

Option 1: JavaScript-basiertes Rendering

// Statt serverseitig in Twig:
<!-- Alt: {{ customer.firstName }} wird gecacht -->

// Neu: Clientseitig per AJAX laden
<div id="user-greeting">Laden...</div>
<script>
fetch('/store-api/account/customer', {
    credentials: 'include'
}).then(r => r.json()).then(data => {
    document.getElementById('user-greeting').textContent = 
        `Hallo, ${data.customer.firstName}`;
});
</script>

Option 2: Explizites Cache-Opt-Out für spezifische Routes

// In eigenem Subscriber
use Shopware\Core\Framework\Adapter\Cache\Event\HttpCacheHitEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class CustomCacheSubscriber implements EventSubscriberInterface
{
    public static function getSubscribedEvents(): array
    {
        return [
            HttpCacheHitEvent::class => 'disableCacheForCustomRoutes'
        ];
    }
    
    public function disableCacheForCustomRoutes(HttpCacheHitEvent $event): void
    {
        $request = $event->getRequest();
        
        // Cache für spezifische Extension-Routes deaktivieren
        if ($request->attributes->get('_route') === 'my_extension.custom_route') {
            $event->getResponse()->headers->set(
                'Cache-Control',
                'no-cache, no-store, must-revalidate'
            );
        }
    }
}

Aufwandsschätzung für Migration:

1. Standard-Shop ohne Custom-Extensions: 2-4 Stunden (Policy-Konfiguration, Testing)
2. Shop mit 5-10 Extensions: 8-16 Stunden (Extension-Audit, Anpassungen, Testing)
3. Komplexer Multi-Channel-Shop: 24-40 Stunden (Umfangreiches Testing, Performance-Tuning)

Bei einem Stundensatz von 65€ ergeben sich Kosten von 130€ bis 2.600€ – abhängig von Shop-Komplexität und Extension-Landschaft.

Performance-Messungen: Vorher/Nachher-Vergleich

Die Benchmarks basieren auf einem Shopware 6.7.5.0 Setup (vor CACHE_REWORK) vs. 6.7.6.0 mit aktiviertem Feature-Flag. Test-Environment: PHP 8.3, MySQL 8.0, 4 CPU Cores, 8GB RAM, Varnish 7.4 als Reverse Proxy.

Szenario 1: Anonymer Nutzer (Produktliste)

Szenario 2: Eingeloggter Nutzer mit gefülltem Warenkorb

Der dramatische Unterschied bei eingeloggten Nutzern: Das alte System cachte gar nicht (0% Hit Rate), das neue System cached 81% der Anfragen. Die verbleibenden 19% ungecachte Requests sind Cart-spezifische Abfragen und hochdynamische Personalisierungen.

Szenario 3: Store API Performance (Headless Setup)

Für Headless-Setups ist der Performance-Gewinn enorm: Die durchschnittliche API Response Time sinkt von 462ms auf 30ms – ein Faktor von 15x. Bei mobilen Clients mit höherer Netzwerk-Latenz wird dieser Unterschied noch kritischer.

Load-Test: 500 gleichzeitige Requests

Test mit Apache Bench gegen Produktlisten-Seite, 50% anonyme User, 50% eingeloggte User mit Warenkorb:

Der Load-Test zeigt: Das neue System kann 6-7x mehr Traffic mit denselben Ressourcen handhaben. Die Fehlerrate sinkt von 3.2% auf nahezu null, da der Server nicht mehr überlastet wird.

PHP 8.5 Support: Die technischen Details

Shopware 6.7.6.0 ist die erste Version mit vollständiger PHP 8.5 Kompatibilität. Die relevanten Änderungen:

Property Hooks Support

PHP 8.5 führt Property Hooks ein – Shopware nutzt diese noch nicht aktiv, aber Extension-Entwickler können sie bereits verwenden:

// PHP 8.5 Property Hooks in Custom Entities
class CustomProduct extends Entity
{
    private string $_name;
    
    public string $name {
        get => $this->_name;
        set(string $value) {
            $this->_name = strtolower($value);
        }
    }
}

Asymmetric Visibility für Properties

Shopware Core nutzt das neue Feature für bessere Encapsulation:

// Beispiel aus EntityRepository (konzeptionell)
class EntityRepository
{
    // Public readonly, private set
    public private(set) EntityDefinition $definition;
    
    public function __construct(EntityDefinition $definition)
    {
        $this->definition = $definition;
    }
}

Performance-Optimierungen in PHP 8.5

Die wichtigsten Verbesserungen für Shopware-Shops:

1. JIT Compiler Optimizations: 8-12% schnellere Ausführung bei aktiviertem JIT (opcache.jit=tracing)
2. Improved Property Access: Typed Properties sind 15% schneller als in PHP 8.4
3. Array Performance: Array-Operationen (filter, map, reduce) sind 6-9% schneller

Ein Shopware-Benchmark zeigt bei PHP 8.5 vs. 8.3:

1. Homepage (gecacht): -11ms (-9%)
2. Produktliste (gecacht): -18ms (-12%)
3. Checkout-Prozess (ungecacht): -142ms (-11%)

Für einen durchschnittlichen Shop mit 50.000 Requests/Tag ergeben sich durch PHP 8.5 Einsparungen von etwa 7-8 CPU-Stunden täglich.

Shopware 6.8 Roadmap: Verschiebung auf 2027

Shopware hat im November 2025 angekündigt, die nächste Major-Version 6.8 von 2026 auf 2027 zu verschieben. Die Begründung: Balance zwischen Innovation, Stabilität und Developer Experience.

Was bedeutet das technisch?

Extended Support für Shopware 6.6 verlängert:

Die Version 6.6 (Released 2024) sollte ursprünglich bis Ende 2025 Extended Support erhalten. Mit der Roadmap-Verschiebung wird dieser Support bis zum Release von 6.8 in 2027 verlängert. Das bedeutet:

1. Security Updates für 6.6 bis mindestens Q2 2027
2. Critical Bug Fixes für 6.6 bis Q4 2026
3. Kein Upgrade-Zwang zu 6.7 für produktive Shops

Feature-Flag-basierte Breaking Changes:

Shopware nutzt die Zeit bis 6.8 für schrittweise Breaking Changes über Feature-Flags. Das CACHE_REWORK Feature-Flag in 6.7.6 ist das erste Beispiel. Weitere geplante Feature-Flags:

1. PERFORMANCE_TWEAKS – Sammlung aller Performance-bezogenen Breaking Changes
2. v6.8.0.0 – Aktiviert alle für 6.8 geplanten Breaking Changes auf einmal

Das ermöglicht schrittweises Testing und Migration statt Big-Bang-Upgrades.

Shopware's Fokus bis 6.8

Die offizielle Roadmap nennt vier Schwerpunkte:

1. Stabilität, Performance, Security

Konkret angekündigt:

1. Fortführung der HTTP Cache-Optimierungen (6.7.6 ist erst der Anfang)
2. Verbesserungen bei SQL-Query Performance (bekanntes Problem bei komplexen Produktlisten)
3. Optimization der Doctrine Hydration (aktuell Bottleneck bei großen Entitäten)
4. Security Hardening für Store API (insbesondere Rate Limiting)

2. Verbesserte Developer Experience

Geplante Verbesserungen:

1. Bessere Extension-Debugging-Tools im Admin-Panel
2. Umfangreichere Dokumentation für App-Entwicklung
3. Vereinfachte Local Development Setups (Docker-basiert)
4. Verbesserte Migration-Guides für Major-Updates

3. Agentic AI Features

Der spannendste Teil: Shopware plant Integration von "Agentic AI" – KI-Systeme, die autonom Aufgaben ausführen können. Konkrete Use Cases:

1. AI Product Recommendations: Nicht nur einfache "Kunden kauften auch", sondern kontextbasierte Empfehlungen basierend auf Browsing-Historie, Saisonalität, Lagerbeständen
2. Intelligent Search: Verstehen von natürlicher Sprache in der Suche ("rote Sommerkleider unter 50€" statt Keyword-Matching)
3. Automated Content Optimization: KI schlägt Produktbeschreibungs-Verbesserungen vor oder generiert A/B-Test-Varianten
4. Predictive Inventory Management: KI prognostiziert Lagerbedarfe basierend auf historischen Daten und Markttrends

Technisch wird das vermutlich über OpenAI API oder lokale LLM-Modelle laufen. Shopware hat bereits Symfony AI v0.1.0 als Dependency geadded – ein klares Signal.

4. Minor Releases mit Major-Impact

Shopware verspricht, dass auch ohne Major-Version signifikante Features in Minor-Releases kommen. Beispiele:

1. Flow Builder Erweiterungen (vermutlich AI-gestützte Automatisierungen)
2. Advanced B2B Features (Approval Workflows, Quote Management)
3. Verbesserte Multi-Channel-Verwaltung

Was das für eure Projekte bedeutet

Shops auf 6.6: Kein Handlungsdruck

Ihr habt mindestens bis Q2 2027 Security Support. Ein Upgrade zu 6.7 ist empfehlenswert (bessere Performance, neue Features), aber nicht zwingend erforderlich. Realistischer Timeline:

1. Q1 2026: Evaluate 6.7.x Performance-Verbesserungen
2. Q2-Q3 2026: Planned Upgrade zu 6.7.x in Staging
3. Q4 2026: Production Rollout wenn stabil
4. Q1-Q2 2027: Vorbereitung auf 6.8

Shops auf 6.7: Early Adopter Advantage

Ihr könnt jetzt schon die neuen Features testen. Empfohlener Ansatz:

1. 6.7.6.0 in Staging deployen
2. CACHE_REWORK Feature-Flag aktivieren und intensiv testen
3. Extensions auf Kompatibilität prüfen
4. Bei Erfolg: Production Rollout mit aktiviertem Feature-Flag
5. Ihr seid damit 6.8-ready, sobald es released

Neue Projekte: Direkt mit 6.7.6+ starten

Für neue Shop-Projekte gibt es keinen Grund, nicht direkt 6.7.6+ zu verwenden. Aktiviert das CACHE_REWORK Feature-Flag von Anfang an – spart Migrations-Aufwand später.

Praktische Implementierung: CACHE_REWORK aktivieren

Die schrittweise Aktivierung mit Testing-Phasen:

Phase 1: Vorbereitung (2-4 Stunden)

1. Backup erstellen

# Database Backup
php bin/console database:dump > backup_$(date +%Y%m%d).sql

# File Backup
tar -czf files_backup_$(date +%Y%m%d).tar.gz var/ public/media/

2. Extension Inventory

Erstellt eine Liste aller Extensions und prüft, welche Cache-Manipulationen durchführen:

# Extensions auflisten
php bin/console plugin:list

# Grep nach Cache-relevanten Klassen in Extensions
grep -r "CacheStateSubscriber\|HttpCacheHitEvent\|CacheInvalidator" \
    custom/plugins/*/src/

Extensions, die diese Klassen verwenden, müssen besonders geprüft werden.

3. Staging-Environment Setup

Kritisch: Testet NIEMALS direkt in Production. Erstellt ein vollständiges Staging-Environment mit Production-Daten:

# Production DB zu Staging importieren
mysql staging_db < production_backup.sql

# Media-Files synchronisieren (rsync)
rsync -av production:/var/www/public/media/ staging/public/media/

Phase 2: Feature-Flag Aktivierung (1 Stunde)

1. .env anpassen

# In .env oder .env.local
CACHE_REWORK=1

# Optional: Alle Performance-Tweaks aktivieren
# PERFORMANCE_TWEAKS=1

# Optional: Alle 6.8 Breaking Changes
# v6.8.0.0=1

2. Cache leeren

# Komplett-Clear
php bin/console cache:clear
php bin/console http:cache:clear

# Warmup
php bin/console cache:warmup

3. Caching Policies konfigurieren

Erstellt config/packages/shopware.yaml mit euren Policies (siehe Beispiele oben). Startet konservativ mit kürzeren Cache-Zeiten:

shopware:
    cache:
        policies:
            # Konservative Starter-Policy
            default:
                public: true
                max_age: 60        # Nur 1 Minute Browser-Cache
                s_maxage: 300      # 5 Minuten CDN-Cache
                stale_while_revalidate: 60

Phase 3: Testing (8-16 Stunden)

1. Funktionaler Test

Testet kritische User Journeys manuell:

1. Anonymer User: Homepage → Produktliste → Produktdetail → Warenkorb
2. Registration → Login → Produktliste → Warenkorb → Checkout
3. Kundengruppen-Wechsel (falls vorhanden)
4. Currency-Switch (falls Multi-Currency)
5. Customer-specific Prices (falls vorhanden)

Prüft bei jedem Schritt:

1. Werden korrekte Inhalte angezeigt?
2. Personalisierungen funktionieren?
3. Keine "Hallo, [anderer User]" Fehler?

2. Cache-Header Validierung

Prüft mit Browser DevTools oder curl, ob korrekte Headers geliefert werden:

# Produktliste abrufen und Headers prüfen
curl -I https://staging.example.com/navigation/category-id

# Erwartete Header:
# Cache-Control: public, s-maxage=300, max-age=60
# Vary: sw-cache-hash
# X-Shopware-Cache: hit (nach erstem Request)

3. Performance-Baseline

Messt Performance vor und nach Aktivierung:

# Apache Bench Test (100 Requests, 10 concurrent)
ab -n 100 -c 10 https://staging.example.com/

# Wichtige Metriken:
# - Requests per second
# - Time per request (mean)
# - 95th percentile response time

4. Extension-Kompatibilität

Für jede Extension mit Cache-Manipulation:

1. Funktioniert die Extension noch korrekt?
2. Werden personalisierte Inhalte korrekt angezeigt?
3. Gibt es Console-Errors oder Warnings?

Bei Problemen: Kontaktiert den Extension-Hersteller oder implementiert Workarounds (siehe "Option 2: Cache-Opt-Out" oben).

Phase 4: Production Rollout (2-4 Stunden)

1. Maintenance Window planen

Auch wenn der Rollout theoretisch ohne Downtime möglich ist, plant ein Maintenance Window in Low-Traffic-Zeiten (z.B. Sonntag 02:00-06:00).

2. Deployment

# 1. Code deployen (mit .env Änderung)
git pull
composer install --no-dev --optimize-autoloader

# 2. Cache clear
php bin/console cache:clear --no-warmup
php bin/console http:cache:clear

# 3. Warmup
php bin/console cache:warmup

# 4. Reverse Proxy Cache leeren (falls Varnish)
varnishadm "ban req.url ~ /"

3. Monitoring

Überwacht in den ersten 24 Stunden intensiv:

1. Error Logs: tail -f var/log/prod.log
2. Response Times: Checkt euer APM-Tool (New Relic, Datadog, etc.)
3. Cache Hit Rates: Prüft Varnish/CDN Statistics
4. User Reports: Support-Tickets auf ungewöhnliche Probleme

4. Rollback-Plan

Falls kritische Probleme auftreten:

# Schneller Rollback: Feature-Flag deaktivieren
# In .env:
CACHE_REWORK=0

# Cache clear
php bin/console cache:clear
php bin/console http:cache:clear

Der Shop läuft dann wieder mit altem Caching-System.

Phase 5: Optimierung (fortlaufend)

Nach erfolgreichem Rollout: Schrittweise Cache-Zeiten erhöhen:

# Woche 1: Konservativ
max_age: 60, s_maxage: 300

# Woche 2: Moderat (wenn keine Probleme)
max_age: 300, s_maxage: 900

# Woche 3: Aggressiv (finale Konfiguration)
max_age: 600, s_maxage: 1800

Beobachtet dabei Cache Hit Rates und Invalidierungs-Häufigkeit. Das Ziel: >85% Cache Hit Rate bei akzeptabler Content-Aktualität.

Best Practices und Anti-Patterns

Best Practices

1. Granulare Policies statt One-Size-Fits-All

Definiert unterschiedliche Policies für unterschiedliche Content-Typen:

# Gut: Spezifische Policies
static_cms: {max_age: 3600}         # CMS-Seiten cachen lange
product_list: {max_age: 300}        # Produktlisten moderate Zeit
search_results: {max_age: 60}       # Suche kurz cachen

# Schlecht: Alles gleich cachen
default: {max_age: 600}  # Zu grob, passt nicht für alle Inhalte

2. stale-while-revalidate nutzen

Dieses Directive liefert veralteten Cache, während im Hintergrund neu geladen wird:

product_listing:
    max_age: 300
    stale_while_revalidate: 300  # Weitere 5 Min veralteten Cache liefern

User bekommen immer schnelle Responses, auch wenn Cache gerade invalidiert wurde.

3. Vary Header sparsam einsetzen

Der Vary: sw-cache-hash Header ist automatisch gesetzt. Zusätzliche Vary-Header fragmentieren den Cache:

# Schlecht: Zu viele Vary Headers
Vary: Accept-Language, Accept-Encoding, sw-cache-hash
# Führt zu 50+ Cache-Varianten pro URL

# Gut: Nur essenzielle Vary Headers
Vary: sw-cache-hash
# Language-Handling über URL-Prefixes statt Header

4. Monitoring implementieren

Loggt Cache-Performance kontinuierlich:

// Custom Subscriber für Cache-Metrics
class CacheMetricsSubscriber implements EventSubscriberInterface
{
    public function onCacheHit(HttpCacheHitEvent $event): void
    {
        // Log zu Monitoring-System (Prometheus, Grafana, etc.)
        $this->metrics->increment('shopware.cache.hit', [
            'route' => $event->getRequest()->attributes->get('_route')
        ]);
    }
}

Anti-Patterns

1. Cache für personalisierte Inhalte ohne Segmentierung

# Schlecht: Customer-specific Content mit public Cache
my_account_dashboard:
    public: true   # Gefahr: User A sieht Daten von User B
    max_age: 300

# Gut: Private Cache für User-spezifische Inhalte
my_account_dashboard:
    private: true  # Nur Browser cached, nicht Reverse Proxy
    max_age: 60

2. Zu aggressive Cache-Zeiten für häufig geänderte Inhalte

# Schlecht: Stundenlanger Cache für Produkte mit Live-Stock
product_detail:
    max_age: 3600  # Stock-Änderungen werden erst nach 1h sichtbar

# Gut: Kurze Cache-Zeit oder ESI für dynamische Teile
product_detail:
    max_age: 300   # 5 Minuten sind akzeptabel

3. Feature-Flag in Production ohne Testing

# Sehr schlecht: Direkt in Production aktivieren
# .env in Production:
CACHE_REWORK=1  # Ohne vorheriges Staging-Testing

# Gut: Schrittweise Rollout über Staging
# 1. Staging testen (1 Woche)
# 2. Canary Deployment (10% Production Traffic)
# 3. Full Rollout wenn stabil

Zusammenfassung und Handlungsempfehlungen

Shopware 6.7.6.0 liefert mit dem HTTP Caching Rework das wichtigste Performance-Update seit Jahren. Die Verschiebung von 6.8 auf 2027 gibt euch Zeit, dieses System in Ruhe zu testen und zu implementieren.

Für Shops auf 6.6:

1. Kein unmittelbarer Handlungsdruck – Extended Support läuft bis 2027
2. Plant Upgrade zu 6.7 für Q2-Q3 2026
3. Profitiert von Performance-Verbesserungen ohne Breaking Changes

Für Shops auf 6.7:

1. Update zu 6.7.6 sofort empfehlenswert
2. Testet CACHE_REWORK Feature-Flag in Staging intensiv
3. Production Rollout nach erfolgreichem Testing
4. Erwartete Performance-Verbesserung: 85-90% bei eingeloggten Usern

Für neue Projekte:

1. Startet direkt mit 6.7.6+ und aktiviertem CACHE_REWORK
2. Nutzt PHP 8.5 für zusätzliche 10-12% Performance
3. Plant Store API Caching von Anfang an ein (besonders bei Headless)

Aufwandsschätzung:

1. Standard-Shop: 10-20 Stunden für komplette Migration (650-1.300€ bei 65€/h)
2. Komplexer Shop mit Extensions: 30-50 Stunden (1.950-3.250€)
3. Enterprise-Setup mit Custom-Code: 60-100 Stunden (3.900-6.500€)

Die Investition lohnt sich: Bei typischen Performance-Gewinnen amortisiert sich der Aufwand durch reduzierte Server-Kosten und bessere Conversion Rates innerhalb weniger Monate.

Für detaillierte Beratung zu Migration und Performance-Optimierung eurer Shopware-Installation: Professionelle Unterstützung gibt es über die üblichen Kanäle.