Commercetools und Storyblok sind zwei Tools die zusammen eine saubere, skalierbare Architektur ergeben. Der eine kümmert sich um Commerce, der andere um Content. Beide sind API-first, beide verstehen sich gut mit modernen Frontends wie Nuxt oder Next.js. Das ist nicht Zufall, sondern Architektur.
Wir kennen diesen Stack aus unserer täglichen Arbeit mit Headless-Architekturen und sagen dir, was funktioniert, was nicht und für wen dieser Stack wirklich die beste Wahl ist.
Inhalt
- Warum diese Kombination?
- Wie die Architektur aussieht
- Nuxt oder Next.js: Welches Frontend?
- Content und Commerce verbinden
- Performance: Was ist möglich?
- Die echten Kosten
- Für wen passt dieser Stack?
- Was wir gelernt haben
Warum diese Kombination?
Stell dir vor du brauchst einen E-Commerce-Shop mit komplexen Content-Anforderungen. Ein klassisches Setup würde alles in eine Plattform quetschen. Shopware mit vielen individuellen Apps für Content-Verwaltung. Oder Shopify mit Zusatz-Tools die nie ganz passen. Das funktioniert, aber die Naht bleibt sichtbar.
Commercetools und Storyblok sind anders. Sie respektieren die Grenzen ihrer Verantwortung.
Commercetools verwaltet den Shop: Produkte, Kategorien, Carts, Orders, Payments, Versand. Alles über APIs. Keine vordefinierte Frontend-Architektur, keine Templates die dir im Weg stehen.
Storyblok verwaltet Content: Landingpages, Blog, SEO-Texte, Marketing-Kampagnen-Landing-Pages, alles was Marketing und Content-Manager:innen selber anfassen wollen. Visual Builder inklusive, keine Code-Kenntnis nötig.
Das Ergebnis: Zwei spezialisierte Systeme statt eines das alles und nichts richtig macht.
Wie die Architektur aussieht
Die Architektur ist überraschend einfach. Drei Ebenen.
Backend-Ebene: Commercetools und Storyblok laufen beide als Headless-Systeme. Das bedeutet sie sind reine APIs. Keine eingebaute UI, keine vordefinierte Struktur die du ertragen musst. Du baust dir genau die Struktur die du brauchst.
Commercetools hat (für Commerce-Dinge) ein ausgefeiltes API-Schema: Product Types, Channels, Carts, Payments. Storyblok hat eine flexible Story-Struktur wo du Komponenten selbst definierst.
Integration-Ebene: Zwischen Frontend und diesen zwei Services passiert die Magie. Dein Frontend spricht beide APIs an. Bei Produkten fragt es Commercetools. Bei Content-Seiten fragt es Storyblok. Das ist nicht kompliziert, aber es verlangt dass dein Frontend-Code das verstehen kann.
Frontend-Ebene: Nuxt oder Next.js. Oder Remix, Astro, was auch immer. Der Stack ist egal, solange er SSG oder SSR kann und du ISR (Incremental Static Regeneration) nutzen kannst. Mehr dazu später.
Das Schöne: Jede Ebene lässt sich unabhängig aktualisieren. Commercetools bekommt ein API-Update? Dein Frontend bricht nicht. Storyblok ändert etwas bei den Komponenten? Dein Checkout ist nicht betroffen.
Nuxt oder Next.js: Welches Frontend?
Das ist die Frage die fast jeden neuen Projekt-Lead trifft. Und wieder: Es kommt drauf an.
Next.js (React + TypeScript im Standard):
- Größeres Ökosystem, mehr Third-Party-Libraries
- Vercel hat alles für Deployments vorbereitet
- App Router (neu) vs Pages Router (alt) kann verwirrend sein
- Wenn du React-Developer:innen hast, ist das der Weg
Nuxt (Vue 3 + TypeScript):
- Schlanker, weniger Boilerplate nötig
- API Routes und SSR sind einfacher zu verstehen
- Weniger aber hochqualitative Bibliotheken
- Wenn dein Team mit Vue anfangen kann, ist das schneller zum Launch
Für Commercetools + Storyblok machen beide Sinn. Der Unterschied ist nicht architektur-bedingt, sondern team-abhängig.
Was wir in der Praxis beobachten: Next.js wird häufiger gewählt wenn das Team groß ist oder extern erweitert werden muss (mehr Entwickler:innen auf dem Markt). Nuxt wird gewählt wenn der Launch schnell gehen muss und die Codebase klein bleiben soll.
Das wichtigere Thema ist weniger Next vs Nuxt, sondern ob du ISR nutzen kannst. Das ist das Feature das diese Architektur wirklich schnell macht.
Content und Commerce verbinden
Die Frage die bei fast jedem Projekt kommt: Wie sprechen Commercetools und Storyblok miteinander?
Kurze Antwort: Das tun sie nicht direkt. Und das ist OK.
Dein Frontend orchestriert das. Wenn du eine Produktseite rendern willst, fragt das Frontend:
- Storyblok: "Gib mir die Story mit Slug /produkt/deine-neue-jacke"
- Commercetools: "Gib mir das Produkt mit SKU xyz"
Beide Responses werden zusammengeführt und als HTML ausgegeben.
Das klingt aufwendig, ist aber in der Praxis elegant gelöst. Weil beide Systeme RESTful APIs haben und moderne Frontends Async/Await verstehen, ist das ein paar Zeilen Code.
Ein praktisches Beispiel: Deine Marketing-Abteilung hat eine Kampagnen-Landingpage in Storyblok erstellt. Diese Seite soll 5 Produkte anzeigen. Storyblok enthält die Komponente "Produkt-Teaser" mit dem Feld "Product IDs". Das Frontend lädt diese Story, sieht die IDs und fragt dann Commercetools nach den Produktdetails. Fertig.
Das ist nicht nur praktisch, es ist auch technisch sauber: Wenn sich ein Produkt-Preis bei Commercetools ändert, sieht man das sofort bei der nächsten Seiten-Anfrage. Du brauchst keine Webhooks, keine komplexe Event-basierte Synchronisation.
Performance: Was ist möglich?
Hier wird's interessant.
Mit einem monolithischen Shop (Shopware, Shopify) brauchst du SSR (Server-Side Rendering) um dynamischen Content zu liefern. Das ist ein Server der bei jedem Request arbeitet. Das ist Mehraufwand.
Mit Commercetools + Storyblok + ISR wird das völlig anders.
Was ist ISR? Incremental Static Regeneration. Dein Build generiert am Deployment statische HTML-Dateien. Diese werden auf einem CDN (z.B. Vercel, Netlify) deployed. Das ist schnell wie statisches HTML sein kann. Aber was ist wenn sich Produkte ändern?
ISR sagt: "Regeneriere diese Seite automatisch nach X Sekunden wenn jemand drauf zugreift."
Das bedeutet: Eine Produktseite wird erstmal statisch ausgeliefert (extrem schnell, unter 100ms). Lädt sich der nächste Besucher die Seite nach 5 Minuten, wird sie im Hintergrund neu generiert. Der Besucher bekommt die aktuelle Version, der nächste bekommt die neu generierte Version.
Das ist nicht nur fast so schnell wie Caching, es ist auch günstiger als ständiges SSR.
Praktische Zahlen:
- Statische Seite vom CDN: 50-100ms (Nordeuropa)
- ISR-Regeneration: 300-800ms im Hintergrund (je nachdem was dein Frontend machen muss)
- SSR bei jedem Request: 1000-3000ms (weil der Server arbeitet)
Für einen Shop mit 1000 Produkten bedeutet das: 999 Seiten werden schnell vom CDN ausgeliefert. 1 Seite wird vielleicht gerade regeneriert. Das ist gut handhabbar.
Die echten Kosten
Das ist der Teil wo wir ehrlich werden.
Commercetools:
Die aktuellen Preise findest du direkt bei commercetools (zum aktuellen Zeitpunkt). Je nach Volumen und Edition variieren die Lizenzkosten stark. Rechne mit monatlichen Kosten die mit deinem Shop-Volumen wachsen. Pay-as-you-go für API-Calls kommt dazu wenn du über Limits gehst.
Storyblok:
Die aktuellen Pläne findest du direkt bei Storyblok (zum aktuellen Zeitpunkt). Es gibt kostenlose Einstiegsoptionen sowie bezahlte Pläne für professionelle Anforderungen und Enterprise.
Frontend-Hosting (Nuxt/Next.js):
Vercel oder Netlify starten günstig und skalieren mit dem Traffic. Selbst gehostete Server sind ebenfalls möglich und oft günstiger bei höherem Volumen.
Entwicklung für den Launch:
- Kleine Projekte (einfacher Shop, wenige individuelle Features): ab 40.000+ EUR
- Mittlere Projekte (200+ Produkte, mehrere Integrationen): ab 80.000+ EUR
- Große Projekte (1000+ Produkte, komplexe B2B-Logik): ab 150.000+ EUR
Das ist kein "ab 5.000 EUR" wie manche Agenturen behaupten. Eine saubere Headless-Architektur kostet, weil es Spezialistenwissen braucht.
Laufende Kosten (monatlich):
- Commercetools: je nach Volumen und Edition
- Storyblok: je nach Plan
- Hosting: je nach Traffic
- Support/Wartung: je nachdem ob du interne Teams hast
Warnung: Diese Kosten sind günstiger als ein monolithischer Shop nur wenn du die Infrastruktur wirklich nutzt. Wenn du nach dem Launch vier Jahre lang nichts änderst und die Codebase verwahrlost, ist dieser Stack nicht günstiger als Shopify. Wenn du aktiv neue Features baust und Content-Manager:innen eigenständig arbeiten sollen, amortisiert sich das schnell.
Für wen passt dieser Stack?
Ehrlich gesagt nicht für jeden. Die Entscheidung ist wieder: "Ist die Komplexität so groß dass spezialisierte Services Sinn machen?"
Der Stack passt wenn:
- Du B2B brauchst oder Multi-Market. Commercetools ist für diese Komplexität gebaut (Kundengruppen-Preise, Kataloge, Freigabeprozesse) – mehr dazu in unserem Artikel zu Commercetools im B2B-Einsatz. Single-Market D2C ist meistens zu viel.
- Dein Shop kontinuierlich weiterentwickelt wird. Nicht ein Relaunch alle 5 Jahre, sondern neue Features regelmäßig. Dann rechtfertigt sich die Trennung der Verantwortlichkeiten.
- Content und Commerce sollen unabhängig sein. Marketing baut schnell Kampagnen-Seiten in Storyblok. Developer arbeiten am Backend ohne zu blockieren.
- Dein Team ist groß genug (6+ Developer). Frontend-Team, Backend-Team, Content-Team, alle parallel. Spezialisierung bringt Vorteil.
- Ein großes Content-Portfolio mit redaktionellen Workflows. Nicht nur Produktseiten, sondern echte Editorial-Prozesse.
Der Stack passt nicht wenn:
- Dein Projekt unter 100 Produkte und unter 500k EUR Jahresumsatz hat. Shopify ist schneller und günstiger.
- Dein Team ist klein (unter 3 Developer). Spezialisierung bringt nur Komplexität, keinen Vorteil.
- Du brauchst "fertige" Features. Mit Commercetools schreibst du selbst. Mit Shopware kommt vieles vorgefertigt.
- Dein Budget ist begrenzt. Der Stack kostet 80.000+ EUR am Anfang. Unter 100k EUR besser einfach.
- Deine Anforderungen sind Standard D2C. Dann reicht Shopware oder Shopify.
Was wir gelernt haben
Nach Jahren mit Headless-Projekten in dieser Kombination ein paar echte Erkenntnisse.
Governance ist wichtiger als Technologie. Das technische Setup ist handhabbar. Schwierig ist: Wer darf in Storyblok was ändern? Wer hat die Verantwortung für die Produktdaten in Commercetools? Wenn dein Team nicht klar ist, wird die schönste Architektur zum Spaghetti-Code.
ISR ist nicht optional, es ist zentral. Wer diesen Stack mit reinem SSR aufbaut, verschenkt den Hauptvorteil. Du musst ISR verstehen und nutzen. Wenn dein Hosting ISR nicht kann, nimm Vercel oder Netlify. Das ist nicht verhandelbar.
Entwickler:innen brauchen ein anderes Onboarding. Mit Shopware ist klar was ein Projekt ist. Mit Commercetools + Storyblok + Frontend brauchst du ein mentales Modell von drei Systemen. Zwei Tage Onboarding ist das Minimum. Neue Entwickler die keine Headless-Erfahrung haben, sind bei Shopware schneller produktiv.
Storyblok ist nicht optional für diesen Stack. Man könnte denken, man könnte Storyblok durch etwas anderes ersetzen. Das ist technisch möglich, aber praktisch fragwürdig. Der Visual Editor von Storyblok ist das einzige Tool das eine Marketing-Abteilung wirklich selbst bedienen kann. CMS-freie Setups funktionieren nur wenn alle Änderungen durch Entwickler gehen.
Commercetools hat Stärken im B2C. Das ist nicht falsch, aber wichtig zu wissen. Wenn du echte B2B mit Freigabeprozessen, individuellen Preisen pro Kunde und Reservierungen brauchst, ist Shopware in manchen Szenarien schneller zum Launch.
Fazit: Die Technologie ist das Leichte
Commercetools und Storyblok sind zwei sehr gute Systeme. Wenn die zusammenkommen, entsteht eine Architektur die sauber, skalierbar und flexibel ist. Das ist unbestritten.
Das Schwierige ist alles darum. Ein Frontend das diese APIs versteht. Deployment-Pipelines die ISR richtig nutzen. Teams die nicht nur Code schreiben, sondern auch verstehen warum die Architektur so gewählt wurde. Governance die sicherstellt dass die Trennung der Verantwortlichkeiten nicht verwässert.
Wenn du das alles hast, dann ist dieser Stack eine starke Wahl. Wenn du das nicht hast, dann ist es auch OK. Shopware oder Shopify können für dein Projekt die bessere Lösung sein.
Die Technologie ist niemals die alleinige Entscheidung.