SAP Composable Storefront vs React/Next.js: Wann welche Lösung die richtige ist

Diese Frage kommt in jedem SAP Commerce Cloud Frontend-Strategie-Workshop auf. Das Projektteam setzt sich hin, zeichnet zwei Kästchen an das Whiteboard. Links: Composable Storefront, SAPs eigenes Angular-basiertes Headless-Frontend. Rechts: ein massgeschneidertes React- oder Next.js-Projekt, das dieselben OCC APIs konsumiert. Dann fragt jemand, welches die richtige Wahl sei. Und die ehrliche Antwort lautet immer gleich — es kommt auf fünf Faktoren an, die nichts mit Framework-Vorlieben zu tun haben.

Der globale E-Commerce erreichte 2024 einen Umsatz von 6,3 Billionen Dollar mit einem Wachstum von 8,4% gegenüber dem Vorjahr (eMarketer, 2025). Ihr Frontend ist kein technisches Detail. Es ist das, womit Ihre Kunden interagieren. Hier entscheidet sich, ob Umsatz entsteht oder nicht.

TL;DR: SAP Composable Storefront bringt Sie schneller auf den Markt (8-12 Wochen) mit über 200 vorgefertigten Commerce-Komponenten, SmartEdit-Integration und SEO ab Werk. Ein massgeschneidertes React/Next.js-Projekt bietet volle Designfreiheit, einen grösseren Talentpool und überlegene Performance-Optimierung — kostet aber initial 40-60% mehr und dauert 12-20 Wochen. Wählen Sie Composable Storefront für Standard-B2B/B2C, Geschwindigkeit und SAP-Ökosystem-Ausrichtung. Wählen Sie React/Next.js für differenzierte B2C-Erlebnisse, bestehende React-Teams und langfristige Flexibilität. Der Hybrid-Ansatz — Composable Storefront als Kern mit React-Micro-Frontends — liefert oft das Beste aus beiden Welten.

Die Entscheidung in 30 Sekunden

Wählen Sie SAP Composable Storefront, wenn:

• Sie schnell starten müssen (unter 12 Wochen)
• Ihr Anwendungsfall Standard-B2B- oder B2C-Commerce ist
• SmartEdit-Integration für Ihr Content-Team wichtig ist
• Ihre Entwickler Angular kennen oder sich einarbeiten können
• SAP-Ökosystem-Ausrichtung strategisch Priorität hat

Wählen Sie React/Next.js, wenn:

• UX-Differenzierung ein zentraler Wettbewerbsvorteil ist
• Sie bereits ein starkes React/Frontend-Team haben
• Sie pixelgenaue Kontrolle über jede Interaktion benötigen
• Performance-Optimierung am Edge (ISR, Streaming SSR) entscheidend ist
• Sie planen, mehrere Marken oder Kanäle aus einer Codebasis zu bedienen

Erwägen Sie einen Hybrid-Ansatz, wenn:

• Sie das Commerce-Fundament des Composable Storefront nutzen möchten, aber massgeschneiderte Erlebnisse für bestimmte Seiten brauchen (PDP, Landing Pages, Konfiguratoren)

Architekturvergleich

Beide Ansätze konsumieren dasselbe Backend. SAP Commerce Cloud stellt seine Funktionalitäten über OCC REST APIs bereit. Das Storefront ist ein reiner API-Konsument. Diese Entkopplung ist der Grund, warum diese Wahl überhaupt existiert.

Composable Storefront Architektur

Browser → Angular App (Composable Storefront)
           ├── CMS-gesteuerte Seitenzusammenstellung (SmartEdit)
           ├── NgRx State Management
           ├── 200+ vorgefertigte Commerce-Komponenten
           └── SSR via Angular Universal
                 ↕ OCC REST APIs (JSON)
           SAP Commerce Cloud (Backend)

Das Storefront liefert Komponenten, die direkt auf die CMS-Struktur von Commerce Cloud abgestimmt sind. SmartEdit steuert das Layout. Angular Universal übernimmt das serverseitige Rendering. Die Integration ist eng und bewusst — SAP hat diese Systeme für das Zusammenspiel konzipiert.

React/Next.js Architektur

Browser → Next.js App
           ├── Eigene Komponentenbibliothek (Sie bauen sie)
           ├── State Management (Ihre Wahl: Zustand, Redux, etc.)
           ├── SSR / SSG / ISR / Streaming (Next.js integriert)
           └── Headless CMS (Contentful, Storyblok, Sanity, etc.)
                 ↕ OCC REST APIs (JSON)
           SAP Commerce Cloud (Backend)

Sie bauen die Commerce-Komponenten selbst. Sie wählen Ihr eigenes CMS, State Management und Rendering-Strategie. Die OCC APIs sind dieselben. Alles andere liegt bei Ihnen.

Für einen detaillierten Blick auf die Backend-Layer von Commerce Cloud siehe unseren Commerce Cloud Architektur-Leitfaden.

SAP Composable Storefront: Was Sie ab Werk bekommen

Composable Storefront (vormals Spartacus) wird mit einem erheblichen Umfang an vorgefertigter Funktionalität ausgeliefert. Das ist sein Hauptvorteil: Sie starten mit funktionierendem Commerce, nicht mit einer leeren Leinwand.

200+ vorgefertigte Komponenten. Product Listing Pages, Product Detail Pages, Warenkorb, Checkout, Mein Konto, Bestellhistorie, B2B-Organisationsverwaltung, Genehmigungsworkflows, gespeicherte Warenkörbe, Schnellbestellung. Das sind keine Demo-Komponenten. Es sind produktionsreife Implementierungen, die direkt auf die Backend-Funktionalitäten von Commerce Cloud abgestimmt sind.

SmartEdit-Integration. Ihr Content-Team kann Seitenlayouts umordnen, Banner austauschen und Promotionen über SAPs visuellen Editor verwalten, ohne Code anzufassen. Das ist wichtiger, als die meisten technischen Teams zugeben. Für einen detaillierten Blick auf SmartEdit und die CMS-Architektur siehe unseren Composable Storefront Feature-Guide.

SEO ab Werk. Meta-Tags, kanonische URLs, strukturierte Daten, serverseitiges Rendering für Crawlability. Nicht perfekt, aber funktional ab dem ersten Tag. Sie optimieren, aber Sie bauen nicht von Grund auf.

Internationalisierung (i18n). Mehrsprachig, Mehrwährungs-fähig, lokalisierte Formatierung. Alles integriert. Das Commerce Cloud Backend verwaltet die Inhalte pro Locale; das Storefront rendert sie.

PWA-Funktionalitäten. Offline-Unterstützung, Homescreen-Installation, Service Worker Caching. Nützlich für mobile B2B-Szenarien, in denen Aussendienstmitarbeitende in Lagern mit unzuverlässiger Konnektivität arbeiten.

Barrierefreiheit (a11y). WCAG 2.1 AA-Konformität ist in die Komponentenbibliothek eingebaut. Tastaturnavigation, ARIA-Labels, Fokus-Management. Nicht fehlerfrei, aber ein solider Ausgangspunkt im Vergleich zum Aufbau von Grund auf.

Der Haken: Es ist Angular. Wenn Ihr Team React kennt, aber kein Angular, ist die Lernkurve real. NgRx State Management ist umständlicher als moderne React-State-Bibliotheken. Und Angular Universals SSR ist nicht so ausgereift wie das von Next.js für komplexe Rendering-Strategien.

React/Next.js: Was Sie selbst bauen

React/Next.js zu wählen bedeutet Freiheit — und Verantwortung. Hier ist, was Next.js bietet, das Composable Storefront nicht hat, und was Sie selbst bauen müssen.

Serverseitiges Rendering, besser gelöst. Next.js 15 unterstützt Static Generation (SSG), Server-Side Rendering (SSR), Incremental Static Regeneration (ISR) und Streaming mit React Suspense. Sie können Strategien pro Route kombinieren. Eine Product Listing Page kann statisch generiert und alle 60 Sekunden revalidiert werden. Eine Warenkorbseite kann voll dynamisch sein. Diese Granularität gibt es bei Composable Storefronts Angular-Universal-Ansatz nicht.

Bildoptimierung. Next.js Image verwaltet responsive Grössen, Lazy Loading, Formatkonvertierung (WebP/AVIF) und CDN-Integration automatisch. Commerce-Sites sind bildlastig. Das summiert sich.

Edge Runtime. Deploy auf Vercel, Cloudflare Workers oder AWS Lambda@Edge. Rendering-Logik nahe am Nutzer ausführen. Composable Storefronts SSR läuft auf einem Node.js-Server — keine Edge-Deployment-Option.

React Server Components. Client-seitiges JavaScript reduzieren, indem Data Fetching und Rendering auf den Server verlagert werden. Weniger JS an den Browser ausliefern. Schnellere Time to Interactive.

Ökosystem-Breite. Headless CMS (Contentful, Storyblok, Sanity, Builder.io), Komponentenbibliotheken (Radix, shadcn/ui), Animation (Framer Motion), Testing (Playwright, Testing Library) — das React-Ökosystem ist riesig.

Was Sie selbst bauen: jede einzelne Commerce-Komponente. PLP, PDP, Warenkorb, Checkout, Mein Konto, B2B-Flows, gespeicherte Warenkörbe, Genehmigungsworkflows. Sie konsumieren dieselben OCC APIs, aber Sie schreiben jede Komponente, jede API-Integration, jedes State-Management-Pattern. Das sind über 200 Komponenten, die Composable Storefront kostenlos mitliefert.

Für eine breitere Perspektive zu Headless- und Composable-Patterns lesen Sie unseren Headless vs Composable Commerce Leitfaden.

Funktionsvergleich

Performance-Vergleich

Performance ist der Punkt, an dem das React/Next.js-Argument überzeugend wird. Wenn es richtig gemacht wird.

Core Web Vitals. Composable Storefront liefert gute Werte ab Werk. Typische Lighthouse-Performance liegt bei 70-85 für eine Standard-Implementierung. Das Angular-Bundle ist schwerer als eine gut optimierte React-App, und Angular Universals Hydration erzeugt Overhead. Ein optimierter Next.js-Build mit React Server Components, Streaming SSR und Edge-Rendering erreicht routinemässig 90+ bei Lighthouse. Das ist ein relevanter Unterschied für konsumentengerichtete Storefronts. Google hat bestätigt, dass Core Web Vitals ein Ranking-Signal bleiben, und Händler mit schnelleren Sites verzeichnen 15-20% höhere Conversion Rates (Google Web.dev, 2024).

First Contentful Paint (FCP). Composable Storefront: typisch 1,5-2,5s. Next.js mit SSG/ISR: typisch 0,5-1,2s. Der Unterschied kommt durch Static Generation — Next.js kann vorgefertigtes HTML von einem CDN ausliefern, ohne auf einen Server-Render zu warten.

Largest Contentful Paint (LCP). Product Detail Pages mit bildlastigen Inhalten sind der Prüfstein. Next.js Image mit Priority Loading und Format-Negotiation übertrifft Angulars Ansatz konsistent. Einsparungen von 0,5-1,5 Sekunden sind üblich.

Total Blocking Time (TBT). Angulars Change Detection und NgRx State Management erzeugen mehr Main-Thread-Arbeit als ein schlankes React-Setup. React Server Components zielen genau darauf ab, indem Rendering vom Client verlagert wird.

Der Vorbehalt. Eine schlecht gebaute Next.js-Site performt schlechter als ein gut konfiguriertes Composable Storefront. Diese Zahlen setzen kompetente Implementierung auf beiden Seiten voraus. Das React-Ökosystem gibt Ihnen mehr Performance-Hebel, aber Sie müssen sie bedienen.

Der Talent-Faktor

Das ist der Faktor, den die meisten Architekturdokumente überspringen. Oft ist er der entscheidende.

Der Stack Overflow Developer Survey 2025 platziert React als populärstes Web-Framework bei 39,5% der professionellen Entwickler, während Angular bei 17,1% steht (Stack Overflow, 2025). Das ist ein 2,3-facher Unterschied im Entwickler-Talentpool.

Was das in der Praxis bedeutet:

• Rekrutierung. Eine React-Frontend-Entwickler-Stelle zieht rund doppelt so viele Bewerbungen an wie eine vergleichbare Angular-Stelle. In wettbewerbsintensiven Märkten (Zürich, München, London) ist das relevant.
• Gehälter. Spezialisierte Angular-Entwickler mit SAP-Erfahrung erzielen einen Aufpreis. React-Entwickler sind breiter verfügbar, was Marktpreise kompetitiver hält.
• Externe Verfügbarkeit. Wenn Sie schnell mit externen Contractors oder Agenturen skalieren müssen, ist der React-Pool wesentlich tiefer.
• Wissenstransfer. Neue Teammitglieder arbeiten sich schneller in React-Projekte ein, weil sie mit höherer Wahrscheinlichkeit Vorerfahrung haben.

Das Gegenargument. Angular-Entwickler tendieren dazu, mehr Erfahrung mit Enterprise-Patterns mitzubringen (Dependency Injection, typisierte Services, RxJS). Wenn Ihr Team bereits Angular beherrscht, ist ein Wechsel zu React, nur um einem Markttrend zu folgen, teuer und riskant. Nutzen Sie, was Ihr Team kennt.

Kostenvergleich

Reale Zahlen aus vergleichbaren Commerce Cloud Frontend-Projekten. Die Annahmen: ein Standard-B2B- oder B2C-Storefront mit 50-100 Produkten, Standard-Checkout, Mehrsprachigkeit und Integration eines Zahlungsanbieters.

Die Nuance. React/Next.js kostet initial und im ersten Jahr mehr. Aber wenn Sie mehrere Storefronts betreiben, amortisiert sich die geteilte Komponentenbibliothek über alle Properties. Nach drei Jahren kann eine gut verwaltete React-Komponentenbibliothek, die drei Storefronts bedient, pro Storefront günstiger sein als drei separate Composable Storefront-Anpassungen.

Der Hybrid-Ansatz

Hier ist, was wir in 2025 und 2026 häufiger empfehlen: beides nutzen. Nicht durcheinander. Strategisch.

Das Pattern: Composable Storefront übernimmt die Commerce-Kernstrecke — Product Listing, Product Detail, Warenkorb, Checkout, Mein Konto. Dort verdienen die 200+ Komponenten ihren Einsatz. Dann bauen Sie spezifische, wirkungsvolle Erlebnisse in React und mounten sie als Micro-Frontends innerhalb der Storefront-Shell.

Wo React-Micro-Frontends passen:

• Produktkonfiguratoren. Komplexe 3D-Konfiguratoren oder Custom Product Builder, bei denen Reacts Komponentenmodell und Ökosystem (Three.js, React Three Fiber) einen klaren Vorteil haben.
• Landing Pages. Kampagnenspezifische Seiten mit massgeschneiderten Animationen, interaktivem Storytelling oder content-lastigen Layouts, bei denen Designfreiheit am meisten zählt.
• Mobile Apps. React Native teilt Komponentenlogik mit Ihrem Web-React-Code. Composable Storefront hat keine native Mobile-Story.
• Personalisierungs-Engines. Echtzeit-Empfehlungswidgets oder KI-gesteuerte Erlebnisse mit Streaming React Server Components.

Wie es technisch funktioniert: SAP Commerce Clouds CMS unterstützt Custom Components. Sie registrieren ein React-Micro-Frontend als CMS-Komponente, und SmartEdit kann es auf jeder Seite neben Standard-Composable-Storefront-Komponenten platzieren. Das Micro-Frontend lädt unabhängig und kommuniziert mit dem Parent über Custom Events oder einen Shared State Bus.

Dieser Ansatz sichert Ihnen 80% des Time-to-Market-Vorteils von Composable Storefront und bewahrt gleichzeitig Reacts Flexibilität dort, wo sie am meisten zählt.

Entscheidungs-Framework

Gehen Sie diese fünf Fragen der Reihe nach durch. Jede verengt die Wahl.

1. Was ist Ihre Timeline? Unter 12 Wochen bis Go-live? Composable Storefront. Die vorgefertigten Komponenten und SmartEdit-Integration sparen 4-8 Wochen gegenüber einem Custom Build. Kein React-Talent kompensiert das, wenn Zeit die Restriktion ist.

2. Was kennt Ihr Team? Bestehendes Angular-Team mit SAP-Erfahrung? Composable Storefront. Bestehendes React-Team ohne Angular-Erfahrung? React/Next.js. Die Umschulungskosten sind real: 2-3 Monate reduzierte Produktivität, während Entwickler ein neues Framework, State-Management-Pattern und Testing-Ansatz lernen. Gemischtes Team? Erwägen Sie den Hybrid.

3. Ist das Storefront ein Markendifferenzierer oder ein funktionales Werkzeug? B2B-Bestellportal, Kunden-Self-Service, Nachbestellfunktion? Composable Storefront bewältigt das mit minimaler Anpassung. Konsumentengerichtetes Markenerlebnis, bei dem jede Interaktion gestaltet ist? React/Next.js gibt Ihnen die pixelgenaue Kontrolle. Die Unterscheidung zählt. Die meisten B2B-Storefronts sind funktionale Werkzeuge. Die meisten ambitionierten B2C-Erlebnisse sind Markendifferenzierer.

4. Wie wichtig ist SmartEdit? Wenn Ihr Marketing-Team Inhalte, Layouts und Promotionen ohne Entwicklerbeteiligung verwalten muss, ist die SmartEdit-Integration ein erheblicher Vorteil. Das mit einem Headless CMS (Contentful, Storyblok) nachzubilden funktioniert, aber es ist ein separates System mit eigener Lernkurve, Lizenzkosten und Integrationsaufwand.

5. Was ist Ihr 3-Jahres-Plan? Einzelnes Storefront, stabile Anforderungen, SAP-Ökosystem-Investition? Composable Storefronts SAP-abgestimmte Roadmap ist ein Vorteil. Mehrere Storefronts, schnelle Frontend-Weiterentwicklung, potenzielle Framework-Migration? React/Next.js mit einer geteilten Komponentenbibliothek gibt Ihnen mehr Flexibilität.

Was wir in der Praxis sehen

In den letzten drei Jahren haben wir Commerce-Cloud-Frontends mit beiden Ansätzen umgesetzt. Das Muster ist klar: Composable Storefront gewinnt bei Geschwindigkeit und Kosten für Standard-Commerce. React/Next.js gewinnt bei Flexibilität und Performance für differenzierte Erlebnisse. Der Hybrid gewinnt, wenn Sie beides brauchen.

Der häufigste Fehler, den wir sehen: React/Next.js wählen, weil das Team «React bevorzugt», und dann 16 Wochen damit verbringen, Komponenten nachzubauen, die Composable Storefront ab Werk liefert. Framework-Präferenz ist legitim. Aber sie sollte nicht CHF 100’000 an dupliziertem Aufwand kosten.

Der zweithäufigste Fehler: Composable Storefront wählen und dann 6 Monate gegen Angular kämpfen, um ein hochgradig massgeschneidertes Erlebnis zu bauen, das React nativ bewältigen würde. Wenn Ihr Design-Team Figma-Files liefert, die nichts mit einem Standard-Storefront zu tun haben, werden Composable Storefronts Komponenten zur Einschränkung, nicht zum Beschleuniger.

Passen Sie das Werkzeug der Aufgabe an. Nicht umgekehrt.

Brauchen Sie Unterstützung bei der Entscheidung? Wir führen Frontend-Architektur-Assessments für SAP Commerce Cloud durch, die Ihr Team, Ihre Timeline und Ihre Anforderungen evaluieren — und den Ansatz empfehlen, der am schnellsten Mehrwert liefert. Sprechen Sie mit unseren Commerce-Architekten.

Für mehr zu SAP Commerce Cloud besuchen Sie unsere E-Commerce-Lösungsseite.

Häufig gestellte Fragen

Ist SAP Composable Storefront dasselbe wie Spartacus?

Ja. SAP hat Spartacus 2023 in «SAP Composable Storefront» umbenannt. Gleiches Produkt, gleiche Angular-Codebasis, gleiche Commerce Cloud OCC API-Integration. Der Name hat sich geändert; die Technologie nicht. Die meisten Entwickler sagen im Gespräch weiterhin Spartacus. SAPs Dokumentation verwendet ausschliesslich «Composable Storefront».

Kann ich React mit SAP Commerce Cloud verwenden?

Ja. Commerce Cloud stellt OCC (Omni Commerce Connect) REST APIs bereit, die jedes Frontend-Framework konsumieren kann. React, Next.js, Vue, Svelte — alles, was HTTP-Requests senden kann, funktioniert. Die OCC API-Schicht ist framework-agnostisch by Design. Sie verlieren SmartEdits visuellen Seiteneditor und die vorgefertigten Commerce-Komponenten, gewinnen aber die volle Kontrolle über die Frontend-Architektur.

Welcher Ansatz ist schneller umzusetzen?

Composable Storefront ist bei Standard-B2B/B2C-Szenarien schneller: 8-12 Wochen gegenüber 12-20 Wochen für einen massgeschneiderten React/Next.js-Build. Die über 200 vorgefertigten Komponenten, SmartEdit-Integration und das bestehende Commerce Cloud CMS-Mapping sparen erhebliche Entwicklungszeit. Der Abstand verringert sich bei hochgradig massgeschneiderten Erlebnissen, bei denen Composable Storefronts Komponenten ohnehin stark modifiziert werden müssen.

Welcher Ansatz ist teurer?

Ein massgeschneidertes React/Next.js-Projekt kostet initial 40-60% mehr, weil jede Commerce-Komponente von Grund auf gebaut wird. Ausserdem benötigen Sie eine separate Headless CMS-Lizenz (CHF 6’000-24’000/Jahr). Composable Storefront beinhaltet SmartEdit und die Komponentenbibliothek. Über drei Jahre verringert sich der Kostenunterschied, wenn Sie mehrere Storefronts mit einer geteilten React-Komponentenbibliothek betreiben — aber für ein einzelnes Storefront ist Composable Storefront konsistent günstiger.

Stirbt Angular aus? Sollte mich das Framework des Composable Storefront beunruhigen?

Angular stirbt nicht aus. Es wird von Google unterstützt, sieht aktive Weiterentwicklung (Angular 18 hat signalbasierte Reaktivität eingeführt) und hat eine grosse Enterprise-Nutzerbasis. Allerdings ist Reacts Talentpool laut Entwicklerumfragen 2,3-mal grösser. Das beeinflusst Rekrutierungsgeschwindigkeit und Contractor-Verfügbarkeit, nicht die Tragfähigkeit des Frameworks. Wenn Sie bereits Angular-Entwickler haben, gibt es keinen Grund zu wechseln. Wenn Sie ein Team von Grund auf aufbauen, ist Reacts grösserer Talentpool ein praktischer Vorteil.