FaaS vs. Headless-CMS: Warum ein CMS allein noch kein Frontend liefert

Das Team hat sich für ein Headless-CMS entschieden, das Content-Modell steht, die Delivery-API liefert sauber strukturierte Inhalte. Kickoff-Stimmung. Dann kommt die Frage, die eigentlich zuerst hätte kommen müssen: Wer rendert das jetzt, wer betreibt es, und wer sorgt dafür, dass die Storefront in sechs Monaten noch performant und aktuell ist? Ein Headless-CMS beantwortet diese Frage nicht, weil es sie gar nicht beantworten will. Es ist Content-Backend, kein Frontend.

Diese Verwechslung ist keine Design-Frage, sondern eine Kategorie-Frage. Ein CMS und eine Frontend as a Service (FaaS) lösen unterschiedliche Probleme, auch wenn beide im selben Satz auftauchen, sobald von "Composable" die Rede ist. Dieser Beitrag zieht die Grenze klar: was ein Headless-CMS liefert, was danach fehlt, und wie du beides zusammen betreibst, ohne eine der beiden Ebenen doppelt zu bauen.

Was ein Headless-CMS wirklich liefert

Ein Headless-CMS, egal ob Contentful, Storyblok, Sulu oder Kontent.ai, liefert drei Dinge zuverlässig: ein Content-Modell für strukturierte Inhalte, eine Editing-Oberfläche für Redaktion und Marketing, und eine Delivery-API, über die diese Inhalte abgerufen werden. Das ist der Kern des "Headless"-Versprechens: Inhalte sind vom Ausgabekanal entkoppelt, ein und dasselbe Content-Modell kann Web, App und weitere Touchpoints bedienen.

Was bewusst fehlt, ist das "Head". Kein Rendering, keine Komponenten-Bibliothek, kein Routing, kein Hosting-Layer, keine Performance-Garantie. Das ist keine Lücke im Produkt, sondern die Design-Entscheidung, die Headless-CMS überhaupt erst schnell und flexibel macht. Nur bedeutet das: Sobald die Inhalte modelliert sind, fängt die eigentliche Arbeit an, nicht endet sie.

Was danach fehlt: die Storefront-Betriebsebene

Zwischen "Content-API liefert Daten" und "Kundin sieht eine schnelle, barrierefreie, gebrandete Seite" liegt eine ganze Betriebsschicht, die in Kickoff-Workshops gerne übersprungen wird:

• Rendering und Komponenten. Wer baut die Komponenten, die die Inhalte darstellen, und wer pflegt sie über Kampagnen, Locales und Brands hinweg?
• Performance und Core Web Vitals. Eine API-Antwort ist noch keine LCP-Zahl. Edge-Delivery, Caching und Bild-Optimierung passieren nicht automatisch, weil das CMS headless ist.
• Barrierefreiheit. WCAG- und BFSG-Konformität sind Frontend-Eigenschaften, keine Content-Modell-Eigenschaften.
• Live-Preview im echten Kontext. Viele CMS-Editoren zeigen eine Vorschau des Contents, nicht die tatsächliche, gerenderte Storefront-Seite mit echtem Layout und echten Nachbar-Komponenten.
• Betrieb. Hosting, CI/CD, Monitoring, Rollback, alles das, was aus einem einmaligen Build einen laufenden Service macht.

Genau diese Schicht ist der Job einer Frontend as a Service. Mehr dazu, wie visuelles Editing direkt in der Live-Storefront aussieht statt in einer isolierten CMS-Vorschau, haben wir separat aufgeschrieben: Visual Editing in einer Live-Storefront, warum CMS-Preview kein Frontend ist.

FaaS: die Betriebsebene über dem CMS

Frontend as a Service ist genau das Betriebsmodell, das die Lücke zwischen Content-API und Live-Storefront schließt, als Service statt als Einmal-Projekt. Statt dass dein Team die Rendering-, Performance- und Betriebsebene einmalig zusammenbaut und danach selbst am Laufen hält, übernimmt eine FaaS diese Schicht dauerhaft: Komponenten-Bibliothek, Live-Editor, Hosting, Performance-Monitoring, Multi-Locale-Sync. Das CMS bleibt die Wahrheit für Inhalte, die FaaS ist die Wahrheit für die Storefront-Erfahrung.

Der Unterschied zu einem selbst gebauten Frontend-Layer ist nicht die Existenz von Komponenten, den bauen sich auch interne Teams. Der Unterschied ist, dass die Betriebsebene selbst zur Plattform-Eigenschaft wird, statt bei jedem CMS-Update, jedem Traffic-Peak und jeder neuen Locale erneut Engineering-Kapazität zu binden. Genau dieses Prinzip, ein CMS mit einem visuellen Frontend zu ergänzen statt es zu ersetzen, hatten wir bereits am Beispiel konkreter CMS-Migrationen skizziert: Headless-CMS mit einem visuellen Page Builder, die fehlende Frontend-Ebene.

CMS und FaaS sind kein Entweder-Oder

Die letzten Wochen haben eine ganze Welle an "Frontend-Optionen für [CMS]"-Vergleichen gebracht, für Contentful, Storyblok, Sulu, Kontent.ai und andere. Der rote Faden in all diesen Vergleichen ist derselbe: Das CMS ist gut in dem, wofür es gebaut wurde, Content-Modellierung, Redaktions-Workflows, API-Auslieferung. Keines davon ist als Storefront-Frontend gedacht, und das ist keine Kritik an den Anbietern, sondern schlicht Architektur.

Laioutr positioniert sich deshalb nicht als CMS-Ersatz, sondern als die Frontend-Ebene, die auf ein bestehendes Headless-CMS aufsetzt. Dein CMS bleibt Content-Backend, Content Management bei Laioutr übernimmt die Komposition, das Editing im Live-Kontext und die Brand-Konsistenz über Seiten, Locales und Kampagnen hinweg. Redaktion arbeitet weiterhin in ihrem CMS oder direkt im Studio, je nach Setup, aber die Seite, die am Ende live geht, ist eine betriebene Storefront und keine gerenderte Rohausgabe einer Content-API.

Wie du CMS-Frage und Frontend-Frage in der Praxis trennst

Vier Fragen helfen, die beiden Ebenen sauber auseinanderzuhalten, bevor ein Projekt daran scheitert, dass beide vermischt wurden:

1. Wer rendert die Seite, die die Kundin sieht? Wenn die Antwort "das macht irgendwie das CMS" lautet, ist die Frontend-Frage noch offen.
2. Wo laufen Performance, Barrierefreiheit und SEO? Diese drei gehören in die Frontend-Ebene, nicht in das Content-Modell.
3. Sieht Redaktion eine echte Live-Vorschau oder nur eine Content-Vorschau? Der Unterschied entscheidet, ob eine Kampagnen-Seite in Stunden oder in Sprints live geht.
4. Was passiert bei einer zweiten Marke oder einem zweiten Markt? Eine gute Antwort braucht eine eigene Betriebsschicht, nicht ein zweites CMS-Setup.

Wer diese vier Fragen für sein aktuelles Setup nicht klar beantworten kann, hat wahrscheinlich ein CMS, aber noch kein Frontend.

Nächste Schritte

Ein Headless-CMS zu wählen, ist eine gute Entscheidung. Zu glauben, damit sei die Frontend-Frage automatisch gelöst, ist der Denkfehler, der Projekte nach dem Kickoff ausbremst. Wenn du wissen willst, wie eine Frontend as a Service konkret über deinem bestehenden CMS aussieht, sieh dir Frontend as a Service an oder buch dir eine Demo, in der wir das an deinem Content-Modell durchgehen, statt an einer generischen Beispielseite.

Weitere Themen aus der Laioutr-Plattform

• Frontend as a Service
• Content Management
• Composable Visual Page Builder
• Was ist ein Headless CMS?

Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr. Er arbeitet mit Mid-Market-Teams in DACH an der Frage, wie CMS-Entscheidungen und Frontend-Entscheidungen sauber getrennt, aber operativ zusammengeführt werden.