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

Diese Frage kommt in jedem Frontend-Workshop zu SAP Commerce Cloud, den wir durchführen. Links auf dem Whiteboard: der SAP Composable Storefront, das Angular-basierte Headless-Frontend von SAP. Rechts: ein eigener Build mit React oder Next.js, der dieselben OCC-APIs nutzt. Die Antwort hängt von fünf Faktoren ab, und die Vorliebe für ein Framework gehört nicht dazu.

Kurzfassung: Der SAP Composable Storefront bringt Sie schneller live (rund 8 bis 12 Wochen für einen typischen Storefront), mit einer grossen Bibliothek vorgefertigter Commerce-Komponenten, SmartEdit-Integration und serverseitigem Rendering. Ein eigener Build mit React/Next.js bietet volle Designfreiheit, mehr Rendering-Optionen und einen grösseren Talentpool, kostet im Aufbau aber typischerweise 40 bis 60 Prozent mehr und dauert 12 bis 20 Wochen. Wählen Sie den Composable Storefront für Standard-B2B und -B2C, Tempo und Nähe zu SAP; wählen Sie React/Next.js für eigenständige B2C-Erlebnisse und bestehende React-Teams. Ein hybrider Ansatz (Composable Storefront als Kern, React-Micro-Frontends für einzelne Seiten) verbindet oft beides.

Die Entscheidung in 30 Sekunden

Wählen Sie den SAP Composable Storefront, wenn:

• Sie schnell live gehen müssen (unter 12 Wochen).
• Ihr Anwendungsfall Standard-Commerce im B2B oder B2C ist.
• SmartEdit für Ihr Content-Team wichtig ist.
• Ihre Entwickler Angular kennen oder lernen können.
• Die Nähe zur Roadmap von SAP Priorität hat.

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

• Ein eigenständiges Nutzererlebnis ein zentraler Wettbewerbsvorteil ist.
• Sie bereits ein starkes React-Team haben.
• Sie volle Kontrolle über jede Interaktion brauchen.
• Edge-Rendering und inkrementelle statische Regenerierung für Sie wichtig sind.
• Sie mehrere Marken oder Kanäle aus einer Komponentenbibliothek bedienen wollen.

Erwägen Sie einen hybriden Ansatz, wenn Sie das Commerce-Fundament des Composable Storefront wollen, aber für einzelne Seiten wie Produktkonfiguratoren oder Kampagnenseiten eigene Erlebnisse brauchen.

Architekturvergleich

Beide Ansätze nutzen dasselbe Backend. SAP Commerce Cloud stellt seine Funktionen über die OCC-REST-APIs bereit, und der Storefront ist ein reiner API-Konsument. Genau diese Entkopplung macht die Wahl überhaupt erst möglich.

Composable Storefront

Browser → Angular-App (Composable Storefront)
           ├── CMS-gesteuerte Seitenkomposition (SmartEdit)
           ├── NgRx State Management
           ├── Vorgefertigte Commerce-Komponenten
           └── Serverseitiges Rendering (Angular SSR auf Node.js)
                 ↕ OCC-REST-APIs (JSON)
           SAP Commerce Cloud (Backend)

Die Komponenten des Storefront sind direkt auf die CMS-Struktur von Commerce Cloud abgestimmt, SmartEdit steuert das Layout, und das serverseitige Rendering von Angular erzeugt die erste Seite. SAP hat diese Teile so entworfen, dass sie zusammenspielen (SAP Help: About Composable Storefront).

React/Next.js

Browser → Next.js-App
           ├── Eigene Komponentenbibliothek (bauen Sie selbst)
           ├── State Management (frei wählbar: Zustand, Redux ...)
           ├── SSR / SSG / ISR / Streaming (in Next.js eingebaut)
           └── Headless CMS (Contentful, Storyblok, Sanity ...)
                 ↕ OCC-REST-APIs (JSON)
           SAP Commerce Cloud (Backend)

Die Commerce-Komponenten bauen Sie selbst, CMS, State Management und Rendering-Strategie wählen Sie frei. Die OCC-APIs sind dieselben, alles andere entscheiden Sie. Die Backend-Schichten hinter den APIs beschreibt unser Überblick zu SAP Commerce Cloud.

SAP Composable Storefront: was Sie ab Werk bekommen

Der Composable Storefront (früher Spartacus) bringt viel funktionierende Funktionalität mit. Das ist sein grösster Vorteil: Sie starten mit funktionierendem Commerce, nicht mit einer leeren Leinwand.

Vorgefertigte Commerce-Komponenten. Produktlisten und Produktdetailseiten, Warenkorb, Checkout, Mein Konto, Bestellhistorie, B2B-Organisationsverwaltung, Freigabeprozesse, gespeicherte Warenkörbe, Schnellerfassung. Das sind produktive Komponenten, abgestimmt auf die Backend-Funktionen von Commerce Cloud, keine Demos.

SmartEdit-Integration. Ihr Content-Team ordnet Layouts neu, tauscht Banner und verwaltet Aktionen im visuellen Editor von SAP, ohne Code anzufassen. Das ist wichtiger, als die meisten technischen Teams zugeben. Die CMS-Architektur erklärt unser Leitfaden zum Composable Storefront im Detail.

SEO vom ersten Tag an. Meta-Tags, kanonische URLs, strukturierte Daten und serverseitiges Rendering für Crawler. Sie werden nachschärfen, aber nicht neu bauen.

Internationalisierung. Mehrere Sprachen und Währungen und länderspezifische Formate; die Inhalte je Sprache liefert das Backend.

PWA-Funktionen. Offline-Unterstützung, Installation auf dem Startbildschirm, Caching per Service Worker. Nützlich für B2B-Szenarien mit schwacher Verbindung, etwa für Mitarbeitende im Lager.

Barrierefreiheit. Die Komponenten bringen Tastaturnavigation, ARIA-Labels und Fokus-Management mit. Nicht fehlerfrei, aber ein echter Ausgangspunkt im Vergleich zum Bau von Grund auf.

Der Haken: Es ist Angular. Wenn Ihr Team React kennt und Angular nicht, ist die Lernkurve real. NgRx ist umständlicher als moderne React-State-Bibliotheken, und das serverseitige Rendering von Angular bietet pro Route weniger Strategien als Next.js. SAP hebt den Storefront einmal pro Jahr, im Februar, auf eine neue Angular-Hauptversion; mit dem Release 2211.36 etwa kam der Wechsel auf Angular 19 und Node.js 22.

React/Next.js: was Sie selbst bauen

React/Next.js bedeutet Freiheit und die Verantwortung, die damit einhergeht.

Mehr Rendering-Optionen. Next.js unterstützt statische Generierung (SSG), serverseitiges Rendering (SSR), inkrementelle statische Regenerierung (ISR) und Streaming mit React Suspense, kombinierbar pro Route. Eine Produktliste kann statisch erzeugt und jede Minute neu validiert werden, während der Warenkorb vollständig dynamisch bleibt.

Bildoptimierung. Next.js übernimmt responsive Grössen, Lazy Loading, Formatkonvertierung (WebP, AVIF) und Auslieferung über das CDN. Commerce-Seiten sind bildlastig, das summiert sich.

Edge Runtime. Deployment auf Vercel, Cloudflare Workers oder AWS Lambda@Edge, Rendering nahe bei den Nutzern. Das SSR des Composable Storefront läuft auf einem Node.js-Server; eine Edge-Rendering-Option bietet SAP dafür nicht an.

React Server Components. Datenabruf und Rendering wandern auf den Server, im Browser landet weniger JavaScript.

Breites Ökosystem. Headless-CMS-Optionen, Komponentenbibliotheken (Radix, shadcn/ui), Animations- und Testwerkzeuge. Das React-Ökosystem ist sehr gross.

Was Sie selbst bauen: jede Commerce-Komponente. Produktlisten, Detailseiten, Warenkorb, Checkout, Mein Konto, B2B-Abläufe, gespeicherte Warenkörbe, Freigabeprozesse. Sie nutzen dieselben OCC-APIs, schreiben aber jede Komponente, jede API-Anbindung und jedes State-Muster selbst, die der Composable Storefront fertig mitbringt. Zur grundsätzlichen Architekturfrage lesen Sie unseren Beitrag zu Composable Commerce im B2B.

Funktionsvergleich

Dimension	Composable Storefront	React/Next.js
Time-to-Market	Rund 8 bis 12 Wochen (typisches B2B/B2C)	12 bis 20 Wochen
Vorgefertigte Commerce-Komponenten	Grosse Bibliothek, produktionsreif	Von Grund auf gebaut
SmartEdit / CMS	Native Integration	Headless CMS nötig (Zusatzkosten und Integration)
SEO	SSR, Meta-Tags, kanonische URLs eingebaut	Mehr Optionen: SSG, ISR, Edge-SSR, Streaming
Core Web Vitals	Gut mit Standard-Tuning	Hervorragend bei guter Optimierung
Rendering-Strategien	SSR (Angular)	SSR, SSG, ISR, Streaming, Edge
Talentpool	Kleiner (Angular)	Grösser (React)
Anpassungsgrenze	Hoch, innerhalb der Angular-Muster	Unbegrenzt
Mobile / PWA	PWA-Funktionen eingebaut	PWA manuell, Option React Native
Barrierefreiheit	Barrierearme Komponenten als Basis	Selbst bauen (oder Radix, Headless UI)
State Management	NgRx (inklusive)	Frei wählbar (Zustand, Redux, Jotai)
Nähe zu SAP	Voll: Roadmap, Support, Patches von SAP	Keine: alles liegt bei Ihnen
CDN / Edge-Deployment	Node.js-Server	Vercel, Cloudflare, AWS Edge
Upgrade-Pfad	Releases von SAP	Framework und eigener Code: Sie verantworten beides
Initiale Baukosten	Tiefer	Typischerweise 40 bis 60 Prozent höher

Performance-Vergleich

Bei der Performance wird das Argument für React/Next.js stark, sofern gut umgesetzt.

Core Web Vitals. Der Composable Storefront liefert ab Werk ordentliche Werte. Das Angular-Bundle ist schwerer als eine gut optimierte React-Anwendung, und die Hydration kostet zusätzlich. Ein sorgfältig optimierter Next.js-Build mit React Server Components, Streaming und Edge-Rendering kann weiter kommen. Für Storefronts mit Endkunden zählt dieser Unterschied, weil Core Web Vitals zu den Signalen gehören, mit denen Google Search die Nutzererfahrung einer Seite bewertet.

Erster Seitenaufbau. Dank statischer Generierung kann Next.js vorgefertigtes HTML aus dem CDN ausliefern, ohne auf ein Server-Rendering zu warten; das verkürzt den First Contentful Paint meist spürbar.

Largest Contentful Paint. Bildlastige Produktdetailseiten sind der eigentliche Test. Die Bildbehandlung von Next.js mit priorisiertem Laden und Formataushandlung schneidet in der Regel besser ab als ein Standard-Setup mit Angular.

Arbeit im Hauptthread. Die Change Detection von Angular und NgRx verursachen mehr Arbeit im Hauptthread als ein schlankes React-Setup; React Server Components reduzieren genau diese Last.

Der Vorbehalt. Eine schlecht gebaute Next.js-Site ist langsamer als ein gut konfigurierter Composable Storefront. Das React-Ökosystem gibt Ihnen mehr Stellschrauben, aber Sie müssen sie auch drehen.

Der Faktor Talent

Diesen Faktor lassen die meisten Architekturpapiere aus, dabei ist er oft der entscheidende.

In der Stack Overflow Developer Survey 2024 nutzten 39,5 Prozent der Befragten React und 17,1 Prozent Angular (Stack Overflow Developer Survey 2024), ein Verhältnis von mehr als zwei zu eins.

Was das praktisch heisst:

• Rekrutierung. Auf React-Stellen melden sich in der Regel deutlich mehr Bewerbende als auf vergleichbare Angular-Stellen, was in engen Märkten wie Zürich oder München zählt.
• Honorare. Angular-Entwickler mit SAP-Erfahrung sind gefragt und entsprechend teurer; React-Entwickler sind leichter verfügbar.
• Externe Unterstützung. Wer schnell mit externen Entwicklern aufstocken muss, findet im React-Umfeld deutlich mehr Angebot.
• Einarbeitung. Neue Teammitglieder bringen React eher schon mit.

Das Gegenargument. Angular-Entwickler sind mit Enterprise-Mustern (Dependency Injection, typisierte Services, RxJS) oft vertrauter. Wenn Ihr Team Angular bereits beherrscht, ist ein Wechsel zu React, nur um einem Markttrend zu folgen, teuer und riskant. Setzen Sie auf das, was Ihr Team kann.

Kostenvergleich

Richtwerte für die Planung eines Standard-Storefronts im B2B oder B2C mit moderatem Sortiment, Standard-Checkout, mehreren Sprachen und einem Zahlungsanbieter. Es sind Schätzungen zur Orientierung, keine Offerten.

Kostenkategorie	Composable Storefront	React/Next.js
Initialer Aufbau	CHF 120’000 bis 180’000	CHF 180’000 bis 300’000
Lizenz Headless CMS	Enthalten (SmartEdit)	CHF 6’000 bis 24’000 pro Jahr
Jährliche Wartung (Entwicklung)	CHF 40’000 bis 60’000 (1 bis 2 Entwickler)	CHF 60’000 bis 100’000 (2 bis 3 Entwickler)
SAP-Lizenz	In Commerce Cloud enthalten	In Commerce Cloud enthalten
Hosting / CDN	Node.js-Server auf SAP Commerce Cloud	Vercel/Cloudflare (CHF 2’400 bis 12’000 pro Jahr)
Total über drei Jahre	CHF 240’000 bis 360’000	CHF 370’000 bis 600’000

Die Nuance. React/Next.js kostet im Aufbau und im ersten Jahr mehr. Bei mehreren Storefronts verteilt sich eine gemeinsame Komponentenbibliothek jedoch auf mehrere Auftritte, und im dritten Jahr kann sie pro Storefront weniger kosten als mehrere einzeln angepasste Composable Storefronts. Das Gesamtbudget der Plattform schlüsselt unser Leitfaden zu Preisen und TCO von SAP Commerce Cloud auf.

Der hybride Ansatz

Was wir seit 2025 häufiger empfehlen: beides nutzen, und zwar gezielt.

Das Muster: Der Composable Storefront übernimmt die Commerce-Kernstrecke: Produktlisten, Produktdetails, Warenkorb, Checkout, Mein Konto. Dort zahlen sich seine vorgefertigten Komponenten aus. Ausgewählte, besonders wirkungsvolle Erlebnisse werden in React gebaut und als Micro-Frontends in die Storefront-Hülle eingebettet.

Wo React-Micro-Frontends passen:

• Produktkonfiguratoren. 3D-Konfiguratoren oder individuelle Produktbaukästen, bei denen das React-Ökosystem (Three.js, React Three Fiber) klar im Vorteil ist.
• Kampagnenseiten. Seiten mit eigenen Animationen, interaktivem Storytelling oder inhaltsreichen Layouts, bei denen Designfreiheit am meisten zählt.
• Mobile Apps. React Native teilt Logik mit Ihrem Web-React-Code; der Composable Storefront hat keine eigene native App.
• Personalisierung. Empfehlungs-Widgets in Echtzeit oder KI-gestützte Erlebnisse.

Technisch: Das CMS von Commerce Cloud unterstützt eigene Komponenten. Sie registrieren ein React-Micro-Frontend als CMS-Komponente, und SmartEdit kann es auf jeder Seite neben Standardkomponenten platzieren. Das Micro-Frontend lädt unabhängig und kommuniziert mit der Hülle über Custom Events oder einen gemeinsamen State-Kanal.

So bleibt der grösste Teil des Zeitvorteils des Composable Storefront erhalten, und React bringt seine Flexibilität dort ein, wo sie zählt.

Entscheidungsraster

Gehen Sie diese fünf Fragen der Reihe nach durch. Jede grenzt die Wahl weiter ein.

1. Wie sieht Ihr Zeitplan aus? Weniger als 12 Wochen bis zum Go-live: Composable Storefront. Seine Komponenten und die SmartEdit-Integration sparen gegenüber einem eigenen Build mehrere Wochen, und kein React-Talent gleicht das aus, wenn die Zeit knapp ist.

2. Was kann Ihr Team? Ein Angular-Team mit SAP-Erfahrung: Composable Storefront. Ein React-Team ohne Angular: React/Next.js. Umschulung kostet: Rechnen Sie mit einigen Monaten geringerer Produktivität, während Entwickler ein neues Framework, ein neues State-Muster und einen neuen Testansatz lernen. Ein gemischtes Team: Prüfen Sie den hybriden Ansatz.

3. Ist der Storefront ein Markenerlebnis oder ein funktionales Werkzeug? B2B-Bestellportale, Self-Service und Wiederbestellungen deckt der Composable Storefront mit wenig Anpassung ab. Ein Markenerlebnis für Endkunden, bei dem jede Interaktion gestaltet ist, spricht für React/Next.js. Die meisten B2B-Storefronts sind funktionale Werkzeuge, die meisten ambitionierten B2C-Erlebnisse Markenauftritte.

4. Wie wichtig ist SmartEdit? Wenn das Marketing Inhalte, Layouts und Aktionen ohne Entwickler pflegen soll, ist SmartEdit ein erheblicher Vorteil. Ein Headless CMS kann es ersetzen, ist aber ein weiteres System mit eigener Lernkurve, Lizenz und Integration.

5. Wie sieht Ihr Dreijahresplan aus? Ein einzelner Storefront, stabile Anforderungen und eine Investition in SAP: Die an SAP ausgerichtete Roadmap des Composable Storefront ist ein Vorteil. Mehrere Storefronts, schneller Wandel im Frontend oder ein möglicher späterer Frameworkwechsel: React/Next.js mit gemeinsamer Komponentenbibliothek lässt Ihnen mehr Spielraum.

Was wir in der Praxis sehen

Wir haben Commerce-Cloud-Frontends mit beiden Ansätzen umgesetzt. Das Muster ist konstant: Der Composable Storefront gewinnt bei Tempo und Kosten im Standard-Commerce, React/Next.js bei Flexibilität und Performance für eigenständige Erlebnisse, und der hybride Ansatz, wenn Sie beides brauchen. Bei Distrelec hat die Entkopplung des Frontends von SAP Commerce über eine saubere API-Schicht die Time-to-Market um 70 % verkürzt.

Der häufigste Fehler: React/Next.js wählen, weil das Team React bevorzugt, und dann Monate damit verbringen, Komponenten nachzubauen, die der Composable Storefront ab Werk liefert. Eine Vorliebe für ein Framework ist legitim, sie sollte aber keinen sechsstelligen Betrag an doppeltem Aufwand kosten.

Der zweithäufigste: den Composable Storefront wählen und dann monatelang gegen Angular ankämpfen, um ein stark individuelles Erlebnis zu bauen, das mit React natürlicher gelänge. Wenn Ihr Designteam Entwürfe liefert, die mit einem Standard-Storefront nichts gemein haben, werden dessen Komponenten zur Einschränkung statt zur Abkürzung.

Wählen Sie das Werkzeug passend zur Aufgabe, nicht umgekehrt. Ist die Storefront-Entscheidung Teil eines grösseren Projekts, ordnet unser Beitrag darüber, was in einer Commerce-Cloud-Implementierung wirklich passiert, sie ein.

---

Brauchen Sie Unterstützung bei der Entscheidung? Wir führen Frontend-Architektur-Assessments für SAP Commerce Cloud durch, die Ihr Team, Ihren Zeitplan und Ihre Anforderungen prüfen und den Ansatz empfehlen, der am schnellsten Nutzen bringt. Sprechen Sie mit unseren Commerce-Architekten. Mehr zu unserer Arbeit mit Commerce Cloud finden Sie auf der Lösungsseite zu SAP Commerce Cloud.

Häufige Fragen

Ist der SAP Composable Storefront dasselbe wie Spartacus?

Ja. Seit Release 5.0 veröffentlicht SAP die offiziellen Spartacus-Bibliotheken als «SAP Commerce Cloud, composable storefront». Es ist dieselbe Angular-Codebasis mit derselben OCC-API-Anbindung; seit Version 2211.19 folgen die Versionsnummern denen von Commerce Cloud. Viele Entwickler sagen weiterhin Spartacus, die Dokumentation von SAP spricht vom Composable Storefront.

Kann ich React mit SAP Commerce Cloud verwenden?

Ja. Commerce Cloud stellt die OCC-REST-APIs (Omni Commerce Connect) bereit, die jedes Frontend-Framework nutzen kann: React, Next.js, Vue und andere. Sie verzichten auf das fertige Seiten-Rendering aus SmartEdit und die vorgefertigten Commerce-Komponenten von SAP und gewinnen volle Kontrolle über die Frontend-Architektur.

Welcher Ansatz ist schneller umgesetzt?

Der Composable Storefront ist bei Standardszenarien im B2B und B2C schneller: rund 8 bis 12 Wochen für einen typischen angepassten Storefront, gegenüber 12 bis 20 Wochen für einen eigenen Build mit React/Next.js. Die meiste Zeit sparen die vorgefertigten Komponenten und das bestehende CMS-Mapping. Bei stark individuellen Erlebnissen, bei denen die Standardkomponenten ohnehin stark umgebaut werden, wird der Abstand kleiner.

Welcher Ansatz ist teurer?

Ein eigenes Frontend mit React/Next.js kostet im Aufbau typischerweise 40 bis 60 Prozent mehr, weil jede Commerce-Komponente geschrieben werden muss und meist ein separates Headless CMS nötig ist. Der Composable Storefront ist in der Commerce-Cloud-Lizenz enthalten und im Aufbau günstiger, kann für ein sehr eigenständiges Nutzererlebnis aber viel Anpassung brauchen. Über drei Jahre schrumpft der Unterschied, wenn mehrere Storefronts eine React-Komponentenbibliothek teilen; für einen einzelnen Storefront ist der Composable Storefront meist günstiger.

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

Nein. Angular wird von Google getragen, erscheint alle sechs Monate in einer neuen Hauptversion und ist in Unternehmen weit verbreitet; SAP hebt den Storefront einmal pro Jahr auf eine neue Angular-Version. React hat zwar einen grösseren Talentpool, das betrifft aber Rekrutierung und Verfügbarkeit externer Entwickler, nicht die Zukunftsfähigkeit des Frameworks. Wenn Sie bereits Angular-Entwickler haben, gibt es keinen Grund zu wechseln; wenn Sie ein Team neu aufbauen, ist der grössere React-Talentpool ein praktischer Vorteil.