Shopware Frontends with Vue/Nuxt: Composable UI 2026

The classic Shopware storefront based on Twig is proven but monolithic: template rendering, controllers and shop logic run inside the same PHP process. Shopware Frontends — the Nuxt-4-based composable UI project — separates these concerns cleanly: Shopware 6 remains a headless backend, while the actual frontend is built as a standalone Vue/Nuxt application. Composable-commerce organisations report 77% (Swell) higher agility, and for headless migrations the same report measures +42% (Swell) conversion compared to the previous platform. This article shows how the stack works, how a migration from a Twig storefront plays out technically, and when the investment pays off economically. Our guide on headless commerce with Shopware covers the general approach.

What Shopware Frontends is

Shopware Frontends is the official, Nuxt-4-based composable UI project of the Shopware ecosystem (Shopware Dev Docs). It provides a production-ready starter template, a rich library of Vue composables and type-safe access to the Store-API. The application runs as a standalone Node service in front of a Shopware 6 backend, communicating strictly over HTTP-JSON interfaces.

The project went through several names: it started as Shopware PWA, later became Composable Frontends, and is now branded Shopware Frontends (Shopware). The GitHub repository shopware/frontends currently has around 225 stars and 81 forks, with 43 open issues (GitHub). The central package @shopware/nuxt-module ships at version v1.4.3 (March 2026) after more than 170 releases (GitHub) — a strong indicator of continuous development.

The motivation is clear: storefront performance, developer experience and composable commerce architecture are hard to achieve with Twig alone. Shopware Frontends brings Shopware into the same league as platforms that strictly decouple a modern frontend pipeline (Vue, Vite, TypeScript, Pinia) from the backend. For a deeper dive into the paradigm, see our article on composable commerce and modular architecture.

A note on React/Next.js: in principle, shop frontends on top of React and Next.js are also conceivable (Solution25). Shopware Frontends, however, deliberately commits to Vue and Nuxt — the official composables, the Nuxt module and the generated API clients are tailored to that stack, which makes rollout noticeably faster and less risky. For Shopware projects we therefore recommend the official path and only consider React/Next.js setups when existing design systems or group-wide standards make a different decision more economical.

Technology stack in detail

The default stack follows the 2026 reference for modern Vue applications (Zignuts, Vue School) and is tuned for performance, type safety and fast feedback loops in the dev process.

The State of Vue.js 2025 report with 1,428 participants (91.6% developers or CTO-level) shows that Composition API, Vite and TypeScript workflows are the standard in the 2026 Vue community. Vue 4 renders initial pages +15% faster than React 19 (Tech-Insider) — for shop frontends where LCP and INP translate into conversion, that matters. Our article on Core Web Vitals and PageSpeed 2026 explains the link in more detail.

The core stack is complemented by a set of quality tools that are now standard in modern Nuxt projects: ESLint and Prettier for code quality, Vitest or Playwright for unit and end-to-end tests, Storybook for the component library, Husky and lint-staged for git hooks. Deployments usually run through GitLab CI, GitHub Actions or Jenkins with separate staging and production environments. For smooth operations an observability stack is equally important: log aggregation, error tracking (e.g. Sentry) and RUM (Real User Monitoring) for Core Web Vitals. Without that baseline it is hard to detect regressions quickly after the cut-over.

Store-API as the bridge between frontend and Shopware

Shopware 6 is API-first (Communicode): the Store-API exposes products, categories, cart, checkout and customer data as structured JSON. The Nuxt frontend consumes that API directly or via Shopware's client packages @shopware/api-client and the generated types produced by @shopware/api-gen.

{
  "apiAlias": "product",
  "id": "0a6f1d5c4b1f4e0e8f4d2b2a3c9e1f23",
  "productNumber": "SW-2026-001",
  "name": "Premium Merino Hoodie",
  "translated": {
    "name": "Premium Merino Hoodie",
    "description": "<p>Lightweight 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 anthracite"
    }
  },
  "stock": 42,
  "seoUrls": [
    { "seoPathInfo": "hoodies/premium-merino", "isCanonical": true }
  ]
}

The Nuxt frontend calls these endpoints either server-side (inside the Nitro layer) or client-side (in the browser). Server-side rendering with Store-API data reduces initial load times and keeps Core Web Vitals stable. For especially performance-critical category pages, edge-side rendering adds another layer — covered in depth in our article on edge computing and edge-side rendering for online shops.

Beyond the Store-API, the frontend also uses context endpoints via useSessionContext and useUser, covering currency, language, shipping country and customer group. In B2B scenarios, composables like useB2bOrder and useB2bQuoteRequest come into play — which illustrates how closely composables are tied to specific Store-API resources. Authentication runs through bearer tokens, and the session context is forwarded by the Nitro server on every request so the frontend can distinguish correctly between anonymous visitors, logged-in customers and B2B contacts.

Composables: the building blocks of the UI

The heart of Shopware Frontends is the library of more than 50 composables (Shopware Dev), which package shop functionality as reusable Vue hooks: useCart, useProduct, useCheckout, useCustomer, useWishlist, useListing, useCmsPage and many more. Each composable covers a clearly bounded slice of business logic and can be used in any component.

<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} added to cart`)
  } catch (error) {
    pushError('Could not add product')
  }
}
</script>

<template>
  <button class="btn btn-primary" @click="addToCart">
    Add to cart ({{ cartItems.length }} / {{ totalPrice }} €)
  </button>
</template>

Three things stand out: first, the entire API is type-safe — the Schemas'Product'] type comes from the generated Store-API schema. Second, composables encapsulate both state (cartItems) and actions (addProduct), keeping components slim. Third, state is synchronised via Pinia stores in the background, so multiple components always see the same cart. That pattern is closely related to what Progressive Web Apps achieve with offline capabilities — see our overview on [PWAs in e-commerce for more.

Performance: Twig storefront vs. Nuxt frontend

Hard numbers always depend on the specific shop — but there are well-documented tendencies. The table below summarises typical values from migration projects and platform benchmarks.

What matters most is the effect on conversion: one second of faster loading (Swell) lifts conversion rate by about 2%, while a jump from 2.4 s to 4.2 s (Swell) cuts it in half. Migration reports show an average 67% (Swell) faster load times after moving to composable frontends, and Forrester's TEI for Salesforce Composable Storefront measures +41% (Forrester TEI) conversion. A well-known example is Photobox with -50% (Digital4Design) loading time after going headless. For the broader performance picture, see our articles on Shopware 6 performance and PHP 8.5 migration for complementary backend strategies.

Migration path: steps and timelines

A migration from Twig to Shopware Frontends is never big bang. A staged approach reduces risk and enables fast learning loops. The following nine steps are typical:

1. Audit the existing storefront: inventory of Twig templates, Shopware plugins with a frontend part, custom JS, third-party integrations and SEO URLs.
2. Store-API gap analysis: verify that all required data points (B2B price lists, CMS content, ERP fields) are reachable via the Store-API — add custom endpoints if needed.
3. Project setup with @shopware/nuxt-module: bootstrap a Nuxt 4 project, wire in modules, plan the design system and foundational components for header, footer and navigation.
4. Generate types: use @shopware/api-gen against your Shopware OpenAPI schema to produce TypeScript types and wire them into CI.
5. Category and product pages as the first route group — highest traffic, biggest performance lever.
6. Cart and checkout flow: wire up useCart, useSessionContext, useCheckout; connect payment and shipping handlers.
7. Parallel rollout: deploy the new frontend under a subdomain, A/B-test against the existing storefront.
8. SEO migration: 301 redirects for URL changes, structured data, sitemap, robots — see also our article on programmatic SEO for category pages.
9. Cut-over and monitoring: switch traffic fully to the Nuxt frontend, add observability for Store-API calls, CWV and error rates.

Realistic timelines: a mid-size shop with roughly 3,000 products, 20 categories, standard payment and standard shipping typically needs 4 to 7 months until cut-over. Complex B2B shops with custom price lists, CRM integration and customer-specific product ranges can reach 8 to 12 months of project duration — see our article on customer-specific product ranges in B2B shops for background.

Step 8, the SEO migration, deserves particular attention: existing URL structures, canonical tags, structured data and hreflang entries must carry over cleanly into the new frontend. An incomplete redirect map can cause noticeable short-term traffic drops. We recommend drafting the redirect plan as early as phase 1, not right before cut-over. Equally important: allow search engine bots onto the staging instance early (with a clean noindex on non-production environments) so the switchover itself holds no surprises.

Apps, themes, plugins: what has to be rebuilt

• Themes: rebuild as a Vue component library — usually a welcome chance to clear out technical debt.
• Frontend plugins (product advisors, filter widgets): reimplement as Vue components or dedicated composables, backend logic usually remains.
• App-based widgets: either serve them via API endpoints or repackage them as Nuxt modules.
• Tracking and consent banners: re-integrate, ideally via a consent-aware Nuxt plugin wrapper.
• SEO modules: set up redirects, canonicals and sitemaps from scratch in Nuxt — more in our article on headless commerce and modular shop architecture.
• Legal components: withdrawal button, checkout checkboxes and mandatory notices must be mapped cleanly in Vue — the legal frame is described in our article on the withdrawal button in Shopware (June 2026).

When Shopware Frontends is the right fit

Not every shop benefits equally. The following constellations especially call for a move to Shopware Frontends:

The migration typically does not pay off for very small shops with a few hundred products and standard requirements — the effort for architecture, hosting and maintenance is out of proportion. In those cases, a well-maintained Twig storefront with clean tracking is often the more pragmatic choice.

There is also an organisational angle: in a classic Twig storefront, backend and frontend development sit closely in one team. Decoupling creates two sub-projects with their own release cycles. Many teams benefit — frontend and backend can be deployed independently — but they have to establish clear interfaces, API contracts and a shared test strategy. Teams that skip that organisational shift give up a large part of the technical upside.

Hosting requirements for Nuxt frontends

A Nuxt 4 frontend needs a Node runtime (Node 20 LTS or newer) — fundamentally different from plain PHP hosting. Two production-ready scenarios work well: a dedicated Node setup with process manager, reverse proxy and CDN in front of static assets — or a serverless deployment on Nitro-compatible platforms. On the Shopware side not much changes: PHP version, database and Shopware instance stay as they are.

We operate both layers: the Shopware backend on our optimised infrastructure plus a separate Node runtime for the frontend — including TLS, HTTP/2, Brotli compression and monitoring. Details on capacity, SLAs and connectivity can be found on our hosting page. For especially large shops, this combines well with a cloud infrastructure that scales and geographically distributes backend and frontend.

Cost framework and ROI

Shopware Frontends is open source — anyone running the Shopware Community Edition pays zero license costs for the frontend project. The effort is in the implementation: architecture, design system, composable adjustments, SEO migration and subsequent hosting. Depending on shop size and complexity, migration projects typically range from the mid five-figure to low six-figure groß range.

On the revenue side, several levers kick in: Swell reports an average +24% (Swell) revenue growth twelve months after a headless migration. In the same studies 50% (Digital4Design) of headless frontends achieve good Core Web Vitals — a direct ranking and conversion factor, as outlined in our Core Web Vitals article (Shopify's performance blog reports a comparable 59.5% Liquid-origins with good CWV in September 2023). To amplify the conversion impact, checkout optimisation and programmatic SEO category pages can be combined — we support that as an e-commerce partner and through our programming team. Companion topics worth considering during the switch: Google AI Mode traffic strategy, the EU Data Act for IoT shops and SEPA Instant Payments, so the new frontend is strategically and regulatorily up to date.

Measured against the uplift in conversion, traffic and time-to-market for new features, migrations typically pay back within 12-24 months — provided the shop has enough revenue and complexity to justify the investment. A sober ROI model before project start is mandatory.

Composable UI as the new default in the Shopware ecosystem

Shopware Frontends is no longer a playground but a production-ready tool with continuous release cadence, an active community and a clear place in the ecosystem. Teams planning a new storefront or a relaunch should put Nuxt 4 and the Store-API on the short list — even if the classic Twig storefront appears cheaper in the short term. Decoupling creates room to move: for new touchpoints, faster features and a better user experience.

That said, a sober view is important: composable UI is not an end in itself. The switch pays off where it addresses concrete business goals — faster time-to-market for campaigns, better Core Web Vitals, scalable multibrand setups or integration into a larger API ecosystem. With our clients, we typically start with an ROI model before writing a single line of code: which pages drive which share of revenue today? Where are the biggest performance issues? Which organisational requirements arise? Only once those questions are answered cleanly do architecture, timeline and budget become concrete.