Die Notifications deines Entwicklungstools klingeln wieder – dein Team diskutiert bereits seit Stunden über die Architektur eures neuen Shopware 6 Projekts. "Sollen wir headless gehen oder bei der klassischen Storefront bleiben?" Diese Frage beschäftigt aktuell viele Online-Händler und Entwicklerteams. Die Antwort ist nicht schwarz oder weiß, sondern hängt von deinen konkreten Anforderungen, Ressourcen und Zielen ab.
Während die einen von den Performance-Vorteilen und der Flexibilität von Headless schwärmen, warnen andere vor dem erhöhten Entwicklungsaufwand und der Komplexität. Lass uns gemeinsam einen praxisorientierten Blick auf beide Ansätze werfen und herausfinden, welcher für dich der richtige ist.
Bevor wir in die Details einsteigen, sollten wir klären, was "headless" in der Shopware-Welt eigentlich bedeutet. Shopware 6 wurde von Grund auf mit einer API-first Architektur entwickelt – das heißt, alle Funktionen sind über APIs zugänglich, auch die Standard-Storefront nutzt diese APIs.
Klassische Shopware Storefront:
Shopware 6 Headless:
Der entscheidende Punkt: Shopware 6 macht beides möglich, ohne dass du dich dauerhaft festlegst. Du kannst sogar hybrid vorgehen und später migrieren.
Mit einer headless Shopware 6 Implementierung eröffnen sich dir moderne Frontend-Technologien, die eine deutlich bessere User Experience ermöglichen können:
Static Site Generation (SSG):
Seiten werden zur Build-Zeit vorgerendert und als statische HTML-Dateien ausgeliefert. Besonders effektiv für Kategorie-Seiten, die sich nicht häufig ändern.
Incremental Static Regeneration (ISR):
Du servierst gecachte Inhalte und aktualisierst sie im Hintergrund. Der Nutzer bekommt sofort eine Antwort, während das System die Daten bei Bedarf erneuert.
Progressive Web App (PWA) Features:
Ein konkretes Beispiel: Ein Kunde fügt ein Produkt in den Warenkorb, verliert aber die Internetverbindung. Mit einer PWA-Implementierung bleibt der Warenkorb erhalten, und der Kauf wird abgeschlossen, sobald die Verbindung wieder steht.
Headless ermöglicht es dir, dieselben Shopware-Daten für verschiedene Touchpoints zu nutzen:
Die Store-API von Shopware 6 liefert konsistente Daten für alle Kanäle. Ein praktisches Szenario: Dein Kunde startet den Einkauf am Desktop, fügt unterwegs per App weitere Artikel hinzu und schließt den Kauf an einem Kiosk im Store ab – nahtlos und ohne Medienbrüche.
Mit headless Lösungen kannst du:
Headless bedeutet nicht automatisch "besser" – es bringt eigene Herausforderungen mit:
Doppelte Entwicklung:
Features wie Warenkorb, Login oder Checkout müssen im Frontend neu implementiert werden, obwohl sie in der Standard-Storefront bereits vorhanden sind.
Plugin-Kompatibilität:
Viele Shopware-Plugins sind für die Storefront optimiert. Bei headless Implementierungen musst du:
Erhöhte Wartungskomplexität:
Statt einem System managst du mindestens zwei:
Für eine erfolgreiche headless Implementierung brauchst du:
Frontend-Expertise:
DevOps-Kenntnisse:
Ein häufiger Fehler: Teams unterschätzen den Aufwand für scheinbar einfache Features. Ein Produktfilter kann in Twig schnell implementiert werden, erfordert aber in einem headless Setup eine durchdachte State-Management-Lösung.
In der Standard-Storefront funktioniert das CMS intuitiv:
Dein Marketing-Team kann eigenständig Landingpages für Kampagnen erstellen, ohne dass Entwickler involviert werden müssen.
Bei headless Lösungen wird CMS-Content über die Store-API als JSON ausgeliefert:
{
"type": "product-slider",
"config": {
"products": ["product-id-1", "product-id-2"],
"displayMode": "cover"
}
}Dein Frontend muss jeden Block-Typ interpretieren und entsprechende Komponenten rendern. Das bedeutet:
Praxis-Tipp: Viele Teams implementieren eine Hybrid-Lösung: CMS-Seiten über die Storefront, hochperformante Produkt- und Checkout-Seiten headless.
Headless ist nicht automatisch performanter. Die Geschwindigkeitsvorteile entstehen durch:
Optimierte Datenabfrage:
// Nur benötigte Produktdaten laden
const product = await storeApi.get('/store-api/product/{id}', {
includes: {
product: ['name', 'price', 'media']
}
});Intelligentes Caching:
Code-Splitting:
Nur der tatsächlich benötigte JavaScript-Code wird geladen.
Häufige Performance-Probleme bei headless Implementierungen:
Over-Fetching:
Composables laden mehr Daten als nötig. Ein useCart-Hook sollte nicht bei jedem Aufruf alle Produktdetails neu laden.
Fehlende Client-side-Optimierung:
Ohne ordentliches State-Management werden API-Calls unnötig wiederholt.
N+1-Probleme:
Statt einer API-Anfrage für Produktlisten werden einzelne Requests für jedes Produkt gesendet.
Shopware bietet mit "Shopware Frontends" eine Lösung, die die headless Entwicklung vereinfacht:
Vorgefertigte Komponenten:
Praxisbeispiel:
<script setup>
const { cart, addProduct, removeProduct } = useCart()
const { products } = useProductListing()
</script>
<template>
<div>
<ProductGrid :products="products" />
<CartSummary :cart="cart" />
</div>
</template>Vorteile:
Nachteile:
Viele Entwicklerteams berichten, dass sie Shopware Frontends als Startpunkt nutzen, aber bei komplexeren Anforderungen eigene Implementierungen bevorzugen.
| Szenario | Begründung |
|---|---|
| Schneller Market-Entry | Shop ist in wenigen Wochen live |
| Standard E-Commerce-Anforderungen | Katalog, Checkout, Payment funktionieren out-of-the-box |
| Kleines Team ohne Frontend-Spezialisierung | Twig-Templates sind einfacher zu maintainen |
| Plugin-abhängige Features | Viele Extensions sind nur für Storefront verfügbar |
| Content-lastige Seiten | CMS-Editor wird häufig von Non-Devs genutzt |
| Budget-Beschränkungen | Geringere Entwicklungskosten |
| Szenario | Begründung |
|---|---|
| Performance-kritische Anwendungen | Sub-Second-Loading-Times sind Geschäftsanforderung |
| Omnichannel-Strategie | Mehrere Touchpoints sollen dieselben Daten nutzen |
| Komplexe User Interfaces | Hochinteraktive Features, Configuratoren, AR/VR |
| Internationalisierung | Verschiedene Frontends für verschiedene Märkte |
| Experimentierfreudiges Team | A/B-Tests und schnelle UI-Iterationen |
| Langfristige Flexibilität | Frontend-Technologie soll unabhängig weiterentwickelt werden |
Du musst dich nicht für einen Ansatz entscheiden. Viele erfolgreiche Shopware-Projekte nutzen hybride Strategien:
API-Design planen:
// Durchdachte API-Calls
const productData = await $storeApi.invoke(
'store-api.product.search post /store-api/product',
{
filter: [
{ type: 'equals', field: 'active', value: true },
{ type: 'range', field: 'price', parameters: { gte: 10, lte: 100 }}
],
includes: {
product: ['id', 'name', 'calculatedPrice'],
product_media: ['media']
}
}
);State Management einrichten:
Für komplexe Anwendungen ist ein durchdachtes State-Management essentiell. Pinia (für Vue) oder Zustand (für React) helfen dabei, API-Calls zu minimieren und die UX zu verbessern.
Wichtige Metriken für headless Shops:
Tools für das Monitoring:
Caching-Strategien:
// Intelligentes Caching für Produktdaten
const { data: product } = await $fetch('/store-api/product/' + productId, {
key: `product-${productId}`,
server: true, // SSR-Caching
default: () => null
});Error Handling:
Robuste Fehlerbehandlung ist bei API-basierten Frontends kritisch. Plane Fallbacks für:
Standard-Storefront:
Headless Implementation:
Storefront:
Headless:
Headless lohnt sich langfristig, wenn:
Phase 1: API-First Development
Auch bei Storefront-Projekten solltest du bereits API-basiert denken:
Phase 2: Komponentenbasierte Entwicklung
Strukturiere Twig-Templates bereits komponentenbasiert:
templates/
└── storefront/
└── component/
└── product/
├── card.html.twig
├── listing.html.twig
└── detail.html.twigPhase 3: Schrittweise Frontend-Extraktion
Beginne mit weniger kritischen Bereichen:
Content-Migration:
CMS-Inhalte bleiben in Shopware, müssen aber für headless Rendering aufbereitet werden:
// CMS-Block-Mapping für headless Frontend
const blockComponents = {
'image-text': ImageTextBlock,
'product-slider': ProductSliderBlock,
'text': TextBlock
};
// Automatisches Rendering basierend auf CMS-Konfiguration
const renderCmsPage = (cmsPage) => {
return cmsPage.sections.map(section =>
section.blocks.map(block =>
createElement(blockComponents[block.type], {
props: block.config
})
)
);
};Vue.js + Nuxt 3:
React + Next.js:
Angular:
Vercel/Netlify:
Custom Infrastructure:
API-Testing:
# Shopware Store-API testen
curl -X POST "https://your-shop.com/store-api/product" \
-H "Content-Type: application/json" \
-H "sw-access-key: YOUR-ACCESS-KEY" \
-d '{
"includes": {
"product": ["id", "name", "calculatedPrice"]
}
}'Performance-Monitoring:
Ein Fashion-Startup wollte schnell einen MVP launchen:
Learnings:
Ein Industrieausrüster brauchte verschiedene Frontends für verschiedene Kundengruppen:
Frontend-Varianten:
Ein Modeunternehmen mit verschiedenen Marken nutzt eine hybride Strategie:
Vorteile:
Shopware investiert stark in die Verbesserung des headless Developments:
Kommende Store-API Features:
Zukünftige Entwicklungen könnten externe CMS-Systeme besser integrieren:
Die Wahl zwischen Shopware Storefront und headless ist keine Frage von "richtig" oder "falsch", sondern von "passend" oder "nicht passend" für deine spezifische Situation.
Wähle die Standard-Storefront, wenn:
Gehe headless, wenn:
Der Hybrid-Ansatz bietet sich an, wenn:
Wichtig ist: Du musst dich nicht sofort festlegen. Shopware 6s API-first Architektur ermöglicht es dir, mit der Storefront zu starten und später zu migrieren, oder hybrid zu arbeiten. Beginne mit dem Ansatz, der für deine aktuelle Situation am besten geeignet ist, und entwickle von dort aus weiter.
Die Entscheidung sollte auf deinen konkreten Geschäftsanforderungen, verfügbaren Ressourcen und langfristigen Zielen basieren – nicht auf dem neuesten Technologie-Trend. Beide Ansätze können zu erfolgreichen E-Commerce-Projekten führen, wenn sie richtig eingesetzt werden.