Web

Headless Websites: Mehr Freiheit für Frontend und Content

Ein Laptop steht auf einem Holzoberfläche und zeigt eine Webseite mit dem Titel "Hybrid". Der Text hebt die Verbindung zwischen zwei Welten hervor und betont die besten Eigenschaften dieser Kombination.

// Artikel

Bei einer klassischen Website gehören Content-Management-System und sichtbare Website eng zusammen. Redakteure pflegen Inhalte im CMS, das System erzeugt daraus die Seiten im Browser. Für viele Websites ist das eine gute und bewährte Architektur.
Headless ist ein Ansatz, der digitale Erlebnisse neu denkt. Inhalte und Gestaltung werden voneinander getrennt – und genau dadurch entsteht mehr Raum für beides. Redaktionen pflegen ihre Inhalte unabhängig von Design oder Ausgabemedium, während Entwickler und Designer sich ganz auf Performance, Usability und Erlebnis konzentrieren können. Ob Website, App oder interaktiver Screen: Inhalte werden einmal erstellt und überall konsistent ausgespielt. Das Ergebnis ist ein flexibles, zukunftssicheres System, das mit den Anforderungen einer Marke wächst – statt sie zu begrenzen.

Das CMS bekommt mehr Möglichkeiten

Der Begriff Headless klingt radikaler, als die Architektur eigentlich ist. Inhalte werden weiterhin zentral im CMS gepflegt. Über eine API (Programmierschnittstelle) stellt das System sie einem oder mehreren Frontends zur Verfügung.

In unseren TYPO3-Projekten kann das beispielsweise bedeuten: TYPO3 verwaltet Seiten, Inhalte, Sprachen, Rollen und redaktionelle Prozesse. Ein separates Frontend auf Basis von Next.js übernimmt die Darstellung und Interaktion im Browser. Damit können beide Seiten stärker auf ihre jeweilige Aufgabe ausgerichtet werden.

TYPO3 bleibt eine leistungsfähige redaktionelle Plattform. Das Frontend bekommt gleichzeitig mehr Freiheit bei Technologie, Darstellung und Weiterentwicklung.

Die Freiheit wird interessant, wenn das Frontend mehr leisten soll

Eine klassische Unternehmenswebsite besteht längst nicht mehr nur aus Textseiten. Produktfinder, Konfiguratoren, interaktive Anwendungen, personalisierte Bereiche oder komplexe Datenvisualisierungen können Teil derselben digitalen Plattform sein. Die Grenze zwischen Website und Webanwendung wird dadurch fließender.

Ein separates Frontend bietet für solche Projekte viel gestalterischen und technischen Spielraum. Komponenten können unabhängig vom CMS entwickelt werden. Interaktionen müssen sich weniger an dessen Ausgabemechanismen orientieren. Frontend-Technologien können gezielt danach ausgewählt werden, was für die digitale Anwendung sinnvoll ist.

Content für mehr als nur eine Anwendung

Die zweite Stärke der Trennung liegt auf der anderen Seite: beim Inhalt. Solange Content ausschließlich für eine Website produziert wird, fällt kaum auf, wie eng Inhalt und Darstellung häufig miteinander verbunden sind. Eine Überschrift gehört zum Hero. Ein Text steckt in einem bestimmten Seitenelement. Ein Produktinhalt wurde für genau eine Darstellung geschrieben. Sollen dieselben Informationen zusätzlich in einer App, einem Kundenportal, auf einem Display oder in einer anderen digitalen Anwendung erscheinen, verändert sich die Aufgabe.

Inhalte müssen stärker als strukturierte Daten gedacht werden. Ein Produkt besteht dann beispielsweise aus Bezeichnung, Beschreibung, Eigenschaften, Medien und weiteren Informationen. Das Frontend entscheidet anschließend, welche davon es für den jeweiligen Kontext benötigt und wie sie dargestellt werden. Dieses Content Modeling, also die strukturierte Modellierung von Inhalten, ist eine wichtige Grundlage guter Headless-Projekte.

Ein Laptop und ein Smartphone liegen auf einem grauen Sofa. Beide Bildschirme zeigen eine Website, die ein Auto präsentiert, mit dem Text „Ready for the next car.“ Der Hintergrund ist dunkel, und es gibt Lichtreflexionen auf den Geräten.

Ein Tablet steht schräg auf einer Oberfläche und zeigt eine digitale Benutzeroberfläche, die eine 3D-Ansicht eines Grundrisses oder Möbelanordnung präsentiert. Auf dem Bildschirm sind Anweisungen oder Optionen zur Gestaltung sichtbar.

Ein Laptop steht auf einem Tisch und zeigt eine Webseite mit dem Titel "DEIN DACH." Die Seite enthält verschiedene Abschnitte zu Themen wie Dachsanierung und Neubau. Ein Bild von Dächern ist ebenfalls sichtbar.

Frontend und CMS mit unterschiedlichen Veränderungszyklen

Bei einer eng gekoppelten Architektur beeinflussen Veränderungen an CMS und Frontend einander stärker. Headless schafft hier eine klare Schnittstelle.

Das Frontend kann weiterentwickelt werden, ohne bei jeder gestalterischen Veränderung tief in das CMS einzugreifen. Umgekehrt können redaktionelle Strukturen und Prozesse im Backend bestehen bleiben, während sich die sichtbare Anwendung verändert.

Das kann besonders für Plattformen interessant sein, die sich kontinuierlich entwickeln. Eine neue Kampagnenwelt, ein zusätzlicher digitaler Service oder eine Weiterentwicklung des Frontends muss dann nicht automatisch bedeuten, dass auch das Content-Management grundsätzlich neu gedacht wird.

Für uns ist das einer der wesentlichen Vorteile des Headless-Ansatzes: Er trennt unterschiedliche Veränderungsgeschwindigkeiten voneinander.

Das Diagramm zeigt die Beziehung zwischen Inhalten, einer Datenbank und einer API, die miteinander verbunden sind. Von der API führen mehrere Pfeile zu einem Frontend, das eine Website, einen Shop und eine App umfasst.

Performance lässt sich gezielt im Frontend gestalten

Die Entkopplung eröffnet auch bei der technischen Auslieferung neue Möglichkeiten.

Moderne Frontend-Frameworks wie Next.js können Seiten beispielsweise bereits vor einer Anfrage erzeugen, Inhalte zwischenspeichern und über leistungsfähige Content Delivery Networks ausliefern. Je nach Anwendung können unterschiedliche Rendering-Strategien kombiniert werden.

Damit lässt sich sehr gezielt steuern, wie Inhalte beim Nutzer ankommen. Headless allein macht eine Website allerdings noch nicht schnell. Große Bilder, unnötiges JavaScript, Drittanbieter-Skripte oder aufwendige Funktionen können auch ein modernes Frontend ausbremsen.

Der Vorteil liegt deshalb an anderer Stelle: Das Frontend-Team bekommt mehr Kontrolle über die technische Auslieferung und kann Performance als eigenständige Aufgabe behandeln.

Ein Mann sitzt an einem Schreibtisch und arbeitet an einem Computer. Er trägt ein weißes T-Shirt und eine Brille. Das Licht fällt sanft von der Seite, und im Hintergrund sind Holzlamellen sichtbar.

Mehrere Ausgabekanäle sind eine Möglichkeit – keine Voraussetzung

Headless wird häufig mit Omnichannel begründet: Ein CMS liefert Inhalte an Website, App, Shop, Portal und weitere digitale Kanäle. Das ist ein starkes Anwendungsszenario, aber nicht das einzige.

Auch eine einzelne Website kann von Headless profitieren, wenn beispielsweise ein anspruchsvolles Frontend, viele interaktive Funktionen oder eine unabhängige Weiterentwicklung von CMS und Frontend gefragt sind. Umgekehrt braucht ein Unternehmen mit einer klassischen Corporate Website nicht automatisch eine Headless-Architektur.

Wenn Inhalte ausschließlich für diese Website produziert werden, die Anforderungen gut mit einer klassischen TYPO3-Architektur abbildbar sind und keine besondere Trennung benötigt wird, kann die direkte Lösung sogar die passendere sein.

Eine Person betrachtet einen Computerbildschirm mit einer Suchoberfläche. Auf dem Bildschirm sind Fotografien von modernen Gebäuden zu sehen. Es gibt ein Suchfeld und eine Schaltfläche zur Durchführung der Suche.

Schnell & flexibel

HEADLESS

Headless schafft neuen Spielraum

Eine Headless-Architektur muss nicht zwingend mit einem kompletten Neubau beginnen.
Ein bestehendes TYPO3 kann weiterhin die redaktionelle Basis bilden, während das Frontend neu entwickelt und schrittweise entkoppelt wird. Ob ein solcher Weg sinnvoll ist, hängt stark von der vorhandenen Installation und den Zielen des Projekts ab.

Gerade bei einer ohnehin anstehenden technischen Modernisierung lohnt es sich deshalb, die Architektur mit zu betrachten. Soll die bestehende Website im Wesentlichen erhalten bleiben, kann ein klassisches TYPO3 Upgrade vollkommen ausreichend sein. Stehen gleichzeitig neue digitale Anwendungen, ein neues Frontend oder eine stärkere Wiederverwendung von Content an, kann der Versionswechsel Anlass sein, über eine Entkopplung nachzudenken.

Projekte