Headless \& Composable Commerce

Entkoppeln Sie das Frontend von der Plattform. Schneller bereitstellen, besser konvertieren.

Der Engpass, der in den meisten Projekten spät zum Problem wird

Das Problem kündigt sich selten eindeutig an. Es zeigt sich, wenn ein Sprint blockiert wird, weil eine Änderung am Checkout-Button ein Plattform-Release erfordert. Es zeigt sich, wenn ein Marketingteam einen Kampagnen-Banner nicht ohne ein Engineering-Ticket aktualisieren kann. Oder es zeigt sich in einem Performance-Audit, das belegt, dass das Standard-Rendering der Plattform für einen Largest Contentful Paint von 3,8 Sekunden verantwortlich ist, der sich durch CDN-Optimierung nicht vollständig beheben lässt. Wenn Unternehmen das Frontend als Engpass erkennen, haben sie meist bereits Umsatz durch geringere Konversion und eine langsamere Content-Bereitstellung verloren.

Dies ist kein Versagen der Plattform. Shopware und Spryker sind leistungsfähige Systeme. Es ist ein Versagen der Kopplung: Wenn die Präsentationsschicht untrennbar mit der Commerce-Engine verbunden ist, beeinflusst jede Änderung an einem Teil den anderen. Eine Headless-Architektur löst diese Kopplung auf. Es ist keine Philosophie, sondern eine technische Entscheidung mit messbaren Konsequenzen.

Was Headless im operativen Betrieb bedeutet

Entkoppeltes Frontend

Die Präsentationsschicht läuft unabhängig von der Commerce-Plattform. In der Praxis bedeutet dies, dass Frameworks wie Next.js oder Nuxt zum Einsatz kommen, die Commerce-APIs über HTTP konsumieren. Die Rendering-Strategie ist nicht einheitlich im gesamten Shop: Produktdetailseiten mit hoher Konversionssensibilität werden serverseitig gerendert, um Aktualität und Core Web Vitals-Ziele auszugleichen; Kategorie- und redaktionelle Seiten können statisch generiert und vom Edge-Server ausgeliefert werden. Lighthouse-Scores und Core Web Vitals (LCP, FID, CLS) sind die Lieferziele, nicht eine nachträgliche Überprüfung nach dem Launch. Ein Frontend, das diese Schwellenwerte nicht erreicht, ist nicht fertiggestellt.

Commerce-API-Schicht

Das Commerce-Backbone liefert die Daten: Katalog, Preise, Lagerbestand, Warenkorb, Auftragsverwaltung. Die Headless-API von Shopware stellt diese über REST- und GraphQL-Endpunkte bereit; die Glue API von Spryker tut dasselbe mit einem modularen, schema-gesteuerten Design, das für komplexe B2B-Preisstrukturen geeignet ist. Gradion ist in beiden Systemen geschult und zertifiziert. Der API-Vertrag zwischen Frontend und Plattform ist die architektonische Nahtstelle, die eine unabhängige Bereitstellung ermöglicht. Versionierung und Abwärtskompatibilität dieses Vertrags sind nicht optional.

Content-Management unabhängig von der Plattform

Redaktionelle Inhalte sollten nicht über eine Commerce-Deployment-Pipeline laufen. Eine CMS-Schicht, typischerweise Contentful oder Storyblok, sitzt neben der Commerce-Plattform und liefert strukturierte Inhalte über ihre eigene API an das Frontend. Das Ergebnis ist, dass ein Marketingteam eine Kampagnenseite veröffentlichen, einen Homepage-Hero aktualisieren oder eine Produktstory planen kann, ohne ein Code-Deployment zu benötigen. Die Commerce-Plattform verwaltet Preise und Lagerbestand; das CMS verwaltet Inhalte; keines blockiert das andere.

Composable-Architektur

Composable bedeutet nicht, dass alles ein Microservice ist. Es bedeutet, dass Best-of-Breed-Komponenten plattform-eigene Funktionalitäten ersetzen, wenn die native Implementierung der Plattform tatsächlich unterlegen ist. Die Suche ist der häufigste Fall: Algolia oder OpenSearch ersetzen die integrierte Suche der Plattform, wenn Kataloggröße und Anforderungen an die Relevanzoptimierung die Möglichkeiten der Plattform übersteigen. Dieselbe Logik gilt für Zahlungen (Stripe, Adyen, Mollie), Bewertungen (Bazaarvoice) und Loyalitätsprogramme. MACH-Prinzipien werden dort angewendet, wo sie Kopplung und operatives Risiko reduzieren, nicht als ideologisches Ziel.

Hier ist Zurückhaltung geboten: Jedes zusätzliche System im Stack erhöht den Integrationsaufwand, das Vertragsmanagement und die operative Angriffsfläche. Die richtige Composable-Architektur verwendet die minimale Anzahl von Komponenten, die die Plattform in ihrem Bereich tatsächlich übertreffen.

Performance Engineering

Die Performance auf Seitenebene umfasst Entscheidungen zum Server-Side Rendering, Pipelines zur Bildoptimierung, die Konfiguration von Edge-Caching und die CDN-Strategie. Diese Elemente sind nicht isoliert zu betrachten; sie interagieren miteinander. Eine SSR-Seite, die nicht am Edge gecacht wird, eliminiert den Großteil des Latenzvorteils. Eine Bildoptimierungspipeline, die auf Mobilgeräten Assets in voller Auflösung ausliefert, negiert die LCP-Verbesserung durch SSR. Der Erfolg liegt im Detail, und die Messung ist transparent: Core Web Vitals-Scores sind in der Google Search Console und über Felddaten verfügbar, was die Ergebnisse überprüfbar macht.

Der entscheidende Kompromiss

Eine Headless-Architektur erhöht die technische Komplexität. Die Frontend-Codebasis ist nun ein separates System mit eigener Deployment-Pipeline, eigenen Abhängigkeiten und eigenen Fehlerquellen. Fällt das CMS aus, kann das Frontend veraltete Inhalte anzeigen oder dynamische Bereiche nicht rendern. Ändert die Commerce-API ihr Schema, bricht das Frontend. Die Verwaltung dieser Schnittstellen erfordert eine technische Disziplin, die ein monolithisches Plattform-Frontend nicht benötigt.

Diese Architektur ist dann die richtige Wahl, wenn die Frontend-Einschränkungen der Plattform messbar die Konversion, die Personalisierungstiefe oder die Content-Geschwindigkeit limitieren. Erfüllt das bestehende Plattform-Frontend die Performance-Ziele und ist der redaktionelle Workflow akzeptabel, verursacht Headless zusätzliche Kosten ohne proportionalen Nutzen. Nicht jedes Projekt benötigt es. Die Entscheidung sollte auf spezifischen, dokumentierten Einschränkungen basieren.

Beweis in der Praxis

Shopmacher, Gradions Partner seit fast acht Jahren, betreibt Headless- und Composable-Architekturen für E-Commerce-Unternehmen in ganz Deutschland. Ihre hybriden Teams, darunter über 20 Gradion-Ingenieure aus Vietnam, managen Produktionssysteme für Kunden wie Bergfreunde und BVB. Dieses Modell funktioniert, weil die technische Disziplin auf beiden Seiten konsequent ist.

Für Detlev Louis, Europas führenden Händler für Motorradausrüstung, entwickelte Gradion die neue Spryker-basierte Plattform, wobei Performance Engineering von Anfang an oberste Priorität hatte. Das Ergebnis war eine 40%ige Verbesserung der Seitenladezeit, die während der Migration ohne SEO-Beeinträchtigungen aufrechterhalten wurde, sowie die Einführung neuer internationaler Stores in nur 20 Tagen. Solche Ergebnisse entstehen nicht durch eine einfache Plattformkonfiguration; sie sind das Resultat präziser Frontend-Entwicklung, die auf jeder Ebene des Stacks angewendet wird.

Handlungsaufforderung

Beschreiben Sie uns Ihre Plattform und die Performance- oder Flexibilitätseinschränkungen, mit denen Sie konfrontiert sind. Wir prüfen, ob Headless die passende Lösung ist und welche realistischen Kompromisse sich für Ihren Kontext ergeben.