Shopware Frontends mit Vue/Nuxt: Composable UI 2026

Die klassische Shopware-Storefront auf Twig-Basis ist ein bewährtes, aber monolithisches Konzept: Template-Rendering, Controller und Shop-Logik laufen im selben PHP-Prozess. Shopware Frontends — das auf Nuxt 4 basierende Composable-UI-Projekt — trennt diese Schichten konsequent: Shopware 6 bleibt als Headless-Backend bestehen, das eigentliche Frontend wird als eigenständige Vue-/Nuxt-Anwendung entwickelt. Organisationen mit Composable-Commerce-Setup berichten zu 77% (Swell) von höherer Agilität, und für Headless-Migrationen weist derselbe Bericht +42% (Swell) Conversion gegenüber der vorherigen Plattform aus. Dieser Artikel zeigt, wie der Stack funktioniert, wie eine Migration aus einer Twig-Storefront technisch abläuft und wann sich der Aufwand wirtschaftlich rechnet. Mehr zum grundlegenden Ansatz liefert unser Beitrag zu Headless Commerce mit Shopware.

Was Shopware Frontends ist

Shopware Frontends ist das offizielle, auf Nuxt 4 basierende Composable-UI-Projekt des Shopware-Ökosystems (Shopware Dev Docs). Es stellt ein produktionsreifes Starter-Template, eine umfangreiche Bibliothek an Composables für Vue und eine typsichere Anbindung an die Store-API bereit. Die Anwendung läuft als eigenständiger Node-Dienst vor einem Shopware-6-Backend und kommuniziert ausschließlich über HTTP-JSON-Schnittstellen.

Das Projekt hat mehrere Namen durchlaufen: Aus dem ursprünglichen Shopware PWA wurde später Composable Frontends, heute firmiert es unter Shopware Frontends (Shopware). Der GitHub-Repository shopware/frontends zählt rund 225 Stars und 81 Forks bei aktuell 43 offenen Issues (GitHub). Das zentrale Paket @shopware/nuxt-module liegt in Version v1.4.3 (März 2026) nach mehr als 170 Releases (GitHub) vor — ein Indikator für kontinuierliche Weiterentwicklung.

Die Motivation für das Projekt ist klar: Storefront-Performance, Developer Experience und Composable-Commerce-Architektur sind mit Twig alleine nur schwer abbildbar. Shopware Frontends bringt Shopware in eine Liga mit Plattformen, die eine moderne Frontend-Pipeline (Vue, Vite, TypeScript, Pinia) konsequent vom Backend entkoppeln. Wer sich grundlegend mit dem Paradigma beschäftigt, findet in unserem Artikel zu Composable Commerce und modularer Architektur eine ausführliche Einordnung.

Abgrenzung zu React/Next.js: Auch Shop-Frontends auf Basis von React und Next.js sind grundsätzlich denkbar (Solution25). Shopware Frontends legt sich jedoch aus gutem Grund auf Vue und Nuxt fest — die offiziellen Composables, das Nuxt-Modul und die generierten API-Clients sind auf diesen Stack zugeschnitten, der Rollout ist dadurch spürbar schneller und risikoärmer. Wir empfehlen für Shopware-Projekte den offiziellen Pfad und betrachten React/Next.js-Setups nur, wenn bestehende Design-Systeme oder konzernweite Vorgaben eine andere Entscheidung wirtschaftlicher machen.

Technologiestack im Detail

Der Default-Stack folgt den Referenzwerten für moderne Vue-Anwendungen 2026 (Zignuts, Vue School) und ist auf Performance, Typisierung und schnelle Feedback-Schleifen im Dev-Prozess ausgelegt.

Die Reports State of Vue.js 2025 mit 1.428 Teilnehmern (91,6% Entwickler oder CTO-Profile) zeigen, dass Composition API, Vite und TypeScript-Workflows in der Vue-Community 2026 Standard sind. Vue 4 (in aktuellen Tech-Insider-Benchmarks) erreicht +15% schnellere Initial-Renderings gegenüber React 19 (Tech-Insider) — für Shop-Frontends, bei denen LCP und INP direkt auf die Conversion einzahlen, ist das relevant. Wie stark Ladezeit und Conversion zusammenhängen, zeigt unser Beitrag zu Core Web Vitals und PageSpeed 2026.

Ergänzt wird der Kern durch eine Reihe von Qualitäts-Werkzeugen, die in modernen Nuxt-Projekten Standard sind: ESLint und Prettier für Code-Qualität, Vitest oder Playwright für Unit- und End-to-End-Tests, Storybook für die Komponenten-Bibliothek, Husky und lint-staged für Git-Hooks. Deployments laufen in der Regel über GitLab CI, GitHub Actions oder Jenkins — mit separaten Staging- und Produktivumgebungen. Für den reibungslosen Betrieb ist zusätzlich ein Observability-Stack wichtig: Log-Aggregation, Fehler-Tracking (z.B. Sentry) und RUM-Messung (Real User Monitoring) für Core Web Vitals. Ohne diese Grundlage wird es schwer, nach dem Cut-over Regressionen schnell zu identifizieren.

Store-API als Brücke zwischen Frontend und Shopware

Shopware 6 ist API-first (Communicode): Die Store-API liefert Produktdaten, Kategorien, Warenkorb, Checkout und Kundendaten als strukturiertes JSON aus. Genau auf diese API setzt das Nuxt-Frontend auf — direkt oder über die von Shopware bereitgestellten Client-Pakete @shopware/api-client und die generierten Typen aus @shopware/api-gen.

{
  "apiAlias": "product",
  "id": "0a6f1d5c4b1f4e0e8f4d2b2a3c9e1f23",
  "productNumber": "SW-2026-001",
  "name": "Premium Merino Hoodie",
  "translated": {
    "name": "Premium Merino Hoodie",
    "description": "<p>Leichter Merino-Hoodie ...</p>"
  },
  "calculatedPrice": {
    "unitPrice": 129.00,
    "totalPrice": 129.00,
    "quantity": 1,
    "currencyId": "b7d2554b0ce847cd82f3ac9bd1c0dfca"
  },
  "cover": {
    "media": {
      "url": "https://shop.example.com/media/ab/cd/hoodie.webp",
      "alt": "Hoodie in anthrazit"
    }
  },
  "stock": 42,
  "seoUrls": [
    { "seoPathInfo": "hoodies/premium-merino", "isCanonical": true }
  ]
}

Das Nuxt-Frontend ruft diese Endpunkte serverseitig (im Nitro-Layer) oder clientseitig (im Browser) auf. Serverseitiges Rendering mit Store-API-Daten reduziert die Initial-Ladezeit und ermöglicht stabile Core Web Vitals. Für besonders performance-kritische Kategorie-Seiten lässt sich zusätzlich Edge-Side-Rendering einsetzen — mehr dazu in unserem Artikel zu Edge Computing und Edge-Side-Rendering im Online-Shop.

Zusätzlich zur Store-API nutzt das Frontend über useSessionContext und useUser auch Kontext-Endpunkte, die Währung, Sprache, Versandland und Kundengruppe abbilden. Bei B2B-Szenarien kommen useB2bOrder und useB2bQuoteRequest hinzu — hier zeigt sich besonders, wie eng Composables an konkrete Store-API-Ressourcen gekoppelt sind. Authentifizierung läuft über Bearer-Tokens, der Session-Kontext wird vom Nitro-Server bei jedem Request weitergereicht, damit das Frontend zwischen anonymen Besuchern, angemeldeten Kunden und B2B-Kontakten korrekt unterscheidet.

Composables: Die Bausteine der UI

Das Kernstück von Shopware Frontends sind die mehr als 50 Composables (Shopware Dev), die Shop-Funktionalität als wiederverwendbare Vue-Hooks kapseln: useCart, useProduct, useCheckout, useCustomer, useWishlist, useListing, useCmsPage und viele mehr. Jedes Composable kümmert sich um einen klar umrissenen Teil der Geschäftslogik und kann in beliebigen Komponenten verwendet werden.

<script setup lang="ts">
import { useCart, useNotifications } from '@shopware-pwa/composables-next'
import type { Schemas } from '@shopware/api-client/api-types'

const props = defineProps<{
  product: Schemas['Product']
  quantity?: number
}>()

const { addProduct, cartItems, totalPrice } = useCart()
const { pushSuccess, pushError } = useNotifications()

async function addToCart() {
  try {
    await addProduct({
      id: props.product.id,
      quantity: props.quantity ?? 1,
    })
    pushSuccess(`${props.product.translated.name} im Warenkorb`)
  } catch (error) {
    pushError('Produkt konnte nicht hinzugefügt werden')
  }
}
</script>

<template>
  <button class="btn btn-primary" @click="addToCart">
    In den Warenkorb ({{ cartItems.length }} / {{ totalPrice }} €)
  </button>
</template>

Drei Dinge fallen auf: Erstens ist die gesamte API typsicher — der Typ Schemas'Product'] stammt aus dem generierten Store-API-Schema. Zweitens kapseln Composables sowohl Zustand (cartItems) als auch Aktionen (addProduct) — Komponenten bleiben dünn. Drittens wird der Zustand über Pinia-Stores im Hintergrund synchronisiert, sodass mehrere Komponenten konsistent denselben Warenkorb sehen. Dieser Ansatz ist vergleichbar mit dem, was Progressive Web Apps mit Offline-Fähigkeiten leisten — unsere Übersicht zu [PWA im E-Commerce vertieft diesen Punkt.

Performance-Vergleich: Twig-Storefront vs. Nuxt-Frontend

Harte Zahlen hängen immer vom konkreten Shop ab — dennoch gibt es gut belegte Tendenzen. Der folgende Vergleich bündelt typische Werte aus Migrationsprojekten und Plattformbenchmarks.

Entscheidend ist der Effekt auf die Conversion: Ein Sekunde schnellere Ladezeit (Swell) erhöht die Conversion Rate um rund 2%, während ein Anstieg von 2,4 auf 4,2 Sekunden (Swell) sie halbiert. Migrationsberichte zeigen nach einem Umstieg auf Composable-Frontends im Schnitt 67% (Swell) schnellere Ladezeiten und im Forrester TEI für Salesforce Composable Storefront +41% (Forrester TEI) Conversion. Ein Praxisbeispiel ist Photobox mit -50% (Digital4Design) Ladezeit durch den Headless-Ansatz. Wer die Performance-Seite eines Shopware-Shops grundsätzlich optimieren will, findet in unseren Artikeln zu Shopware-6-Performance und zur PHP-8.5-Migration ergänzende Ansätze auch für das Backend.

Migrationspfad: Schritte und Zeitrahmen

Eine Migration von Twig-Storefront zu Shopware Frontends ist kein Big-Bang. In der Regel empfiehlt sich ein stufenweiser Ansatz, der Risiken reduziert und schnelle Lern-Schleifen erlaubt. Typisch sind die folgenden neun Schritte:

1. Audit der bestehenden Storefront: Inventar aller Twig-Templates, Shopware-Plugins mit Frontend-Anteil, Custom-JS, Drittanbieter-Integrationen und SEO-URLs.
2. Store-API-Abgleich: Prüfen, ob alle benötigten Datenpunkte (z.B. B2B-Preislisten, CMS-Inhalte, ERP-Felder) über die Store-API erreichbar sind — gegebenenfalls eigene API-Endpoints ergänzen.
3. Projekt-Setup mit @shopware/nuxt-module: Nuxt-4-Projekt aufsetzen, Module einbinden, Design-System und Basis-Komponenten für Header, Footer, Navigation planen.
4. Typen generieren: Via @shopware/api-gen aus dem OpenAPI-Schema der eigenen Shopware-Instanz TypeScript-Typen erzeugen und in die CI-Pipeline aufnehmen.
5. Kategorie- und Produktseiten als erste Route-Gruppe umsetzen — hier liegt der größte Traffic und der größte Performance-Hebel.
6. Warenkorb- und Checkout-Flow: Composables useCart, useSessionContext, useCheckout einbinden, Payment- und Shipping-Handler anbinden.
7. Parallelbetrieb: Neues Frontend unter Subdomain ausrollen, A/B-Testing gegen bestehende Storefront.
8. SEO-Migration: 301-Redirects für URL-Änderungen, strukturierte Daten, Sitemap, Robots — ergänzend unser Beitrag zu programmatic SEO für Kategorie-Seiten.
9. Cut-over und Monitoring: Traffic komplett auf Nuxt-Frontend umschalten, Observability für Store-API-Calls, CWV, Error-Rates aufsetzen.

Realistische Zeitrahmen: Ein Midsize-Shop mit ca. 3.000 Produkten, 20 Kategorien, Standard-Payment und Standard-Versand benötigt typischerweise 4 bis 7 Monate bis zum Cut-over. Komplexe B2B-Shops mit individuellen Preislisten, CRM-Anbindung und kundenspezifischen Sortimenten können 8 bis 12 Monate Projektlaufzeit erreichen — Hintergrund dazu in unserem Artikel zu kundenspezifischen Sortimenten im B2B-Shop.

Besonders kritisch ist Schritt 8, die SEO-Migration: Bestehende URL-Strukturen, Canonical-Tags, strukturierte Daten und Hreflang-Einträge müssen sauber in das neue Frontend übertragen werden. Ein unvollständiges Redirect-Mapping kann kurzfristig zu spürbaren Traffic-Einbußen führen. Wir empfehlen daher, das Redirect-Konzept schon in Phase 1 zu erstellen und nicht erst kurz vor dem Cut-over. Ebenso wichtig: Suchmaschinen-Bots früh auf die Staging-Instanz zulassen (mit sauber gesetztem noindex in Nicht-Produktiv-Umgebungen), damit nach dem Umzug keine Überraschungen auftreten.

Apps, Themes, Plugins: Was bei der Migration ersetzt werden muss

• Themes: Vollständig neu als Vue-Komponentenbibliothek aufbauen — meist eine gute Gelegenheit, technische Altlasten aufzulösen.
• Frontend-Plugins (z.B. Produktberater, Filter-Widgets): als Vue-Komponenten oder eigene Composables neu implementieren, Backend-Logik bleibt meist bestehen.
• App-basierte Widgets: Müssen entweder über API-Endpoints bereitgestellt oder als Nuxt-Module neu verpackt werden.
• Tracking und Consent-Banner: Neu integrieren, idealerweise über einen Consent-fähigen Nuxt-Plugin-Wrapper.
• SEO-Module: Redirects, Canonicals, Sitemaps komplett in Nuxt (meta-tags, sitemap-Modul) neu aufsetzen — mehr dazu in unserem Beitrag zu headless Commerce und modularer Shop-Architektur.
• Rechtliche Komponenten: Widerrufsbutton, Checkbox-Texte und Pflicht-Hinweise sauber in Vue abbilden — der gesetzliche Rahmen ist in unserem Artikel zur Umsetzung des Widerrufsbuttons in Shopware (Juni 2026) beschrieben.

Wann Shopware Frontends sinnvoll ist

Nicht jeder Shop profitiert gleichermaßen. Die folgenden Konstellationen sprechen besonders für einen Umstieg auf Shopware Frontends:

Nicht geeignet ist der Umstieg typischerweise für sehr kleine Shops mit wenigen Hundert Produkten und Standard-Anforderungen — hier ist der Aufwand für Architektur, Hosting und Wartung im Verhältnis zum Nutzen zu hoch. In solchen Fällen ist eine saubere Twig-Storefront mit sauberem Tracking-Setup oft das pragmatischere Ergebnis.

Ein zusätzlicher Aspekt ist die Organisation: Bei einer klassischen Twig-Storefront liegen Backend- und Frontend-Entwicklung eng in einem Team. Durch die Entkopplung entstehen zwei Teilprojekte mit eigenen Release-Zyklen. Viele Teams profitieren davon — Frontend und Backend können unabhängig voneinander deployed werden — müssen aber klare Schnittstellen, API-Contracts und eine gemeinsame Teststrategie etablieren. Wer diesen organisatorischen Schritt nicht parallel geht, verschenkt einen erheblichen Teil des technischen Gewinns.

Hosting-Anforderungen für Nuxt-Frontends

Ein Nuxt-4-Frontend benötigt eine Node-Runtime (Node 20 LTS oder neuer) — das unterscheidet es grundlegend von einem reinen PHP-Hosting. Produktionsreif sind zwei Szenarien: Ein dediziertes Node-Setup mit Prozess-Manager, Reverse-Proxy und CDN vor statischen Assets — oder ein serverless Deployment auf Nitro-kompatiblen Plattformen. Auf Seiten des Shopware-Backends ändert sich wenig: PHP-Version, Datenbank und Shopware-Instanz bleiben wie gewohnt.

Wir übernehmen beide Schichten: Shopware-Backend auf unserer optimierten Infrastruktur plus ein separater Node-Runtime für das Frontend — inklusive TLS, HTTP/2, Brotli-Kompression und Monitoring. Details zu Kapazität, SLAs und Anbindung gibt es auf unserer Seite zum Hosting. Für sehr große Shops ergänzt sich das gut mit einer Cloud-Infrastruktur, in der Backend und Frontend skaliert und geografisch verteilt werden.

Kostenrahmen und ROI

Shopware Frontends ist Open Source — wer die Shopware Community Edition nutzt, zahlt keine Lizenzkosten für das Frontend-Projekt. Der Aufwand liegt in der Umsetzung: Architektur, Design-System, Composable-Anpassungen, Migration der SEO-Struktur und das anschließende Hosting. Je nach Shopgröße und Komplexität bewegen sich Migrationsprojekte typischerweise zwischen einem mittleren fünfstelligen und einem sechsstelligen Bruttobetrag.

Auf der Ertragsseite zeigen sich mehrere Hebel: Swell berichtet im Schnitt +24% (Swell) Umsatzwachstum zwölf Monate nach einer Headless-Migration. In gleichen Messungen erreichen 50% (Digital4Design) der Headless-Frontends gute Core-Web-Vitals-Werte — ein direkter Ranking- und Conversion-Faktor, wie wir im Beitrag zu Shopify-Liquid-Origins-CWV einordnen (Shopify Performance Blog nennt hier einen Vergleichswert von 59,5% Liquid-Origins mit guten CWV im September 2023). Wer die Conversion-Wirkung weiter ausspielen will, kann zusätzlich Checkout-Optimierungen und Programmatic-SEO-Kategorieseiten kombinieren — wir unterstützen das als E-Commerce-Partner und im Team der Programmierung. Begleitend zum Umstieg lohnen Themen wie Google AI Mode Traffic-Strategie, der EU Data Act für IoT-Shops und SEPA Instant Payments, damit das neue Frontend regulatorisch und strategisch auf der Höhe der Zeit ist.

Gemessen am Uplift aus Conversion, Traffic und Time-to-Market für neue Features amortisieren sich Migrationen erfahrungsgemäß innerhalb von 12-24 Monaten — vorausgesetzt, der Shop hat genug Umsatz und Komplexität, um die Investition zu rechtfertigen. Eine nüchterne ROI-Rechnung vor Projektstart ist unverzichtbar.

Composable UI als neuer Standard im Shopware-Ökosystem

Shopware Frontends ist keine Spielwiese mehr, sondern ein produktionsreifes Werkzeug mit kontinuierlicher Release-Frequenz, aktiver Community und einer klaren Rolle im Ökosystem. Wer heute eine neue Storefront plant oder einen Relaunch ansteht, sollte Nuxt 4 und die Store-API als ernstzunehmende Option mit auf den Tisch legen — auch dann, wenn die klassische Twig-Storefront kurzfristig günstiger erscheint. Die Entkopplung schafft Handlungsspielraum: für neue Touchpoints, schnellere Features und eine bessere User Experience.

Wichtig ist ein nüchterner Blick: Composable UI ist kein Selbstzweck. Der Umstieg lohnt dort, wo er konkrete Business-Ziele adressiert — schnellere Time-to-Market für Kampagnen, bessere Core Web Vitals, skalierbare Multibrand-Setups oder die Integration in ein größeres API-Ökosystem. Wir arbeiten mit unseren Kunden typischerweise zuerst entlang einer ROI-Rechnung, bevor ein einziges Stück Code entsteht: Welche Seiten bringen heute wie viel Umsatz? Wo sind die größten Ladezeit-Probleme? Welche organisatorischen Anforderungen ergeben sich? Erst wenn diese Fragen sauber beantwortet sind, werden Architektur, Timeline und Budget konkret.