Die Vorteile eines Headless-CMS: Flexibilität und Skalierbarkeit im Blick
Ein Vortrag auf Website und App macht verständlich, was ein Headless-CMS ermöglicht, was Redaktionen brauchen und wie sich der gesamte Veröffentlichungsablauf prüfen lässt.
Dieselben Inhalte, unterschiedliche Darstellungen. Jede Website und jede App muss dennoch entwickelt und angebunden werden.
Stellen Sie sich vor, Sie veröffentlichen die Ankündigung eines Vortrags. Titel, Foto, Beschreibung und Beginn sollen auf Ihrer Website und in einer mobilen App erscheinen. Wenn sich die Uhrzeit ändert, möchten Sie sie nur einmal korrigieren müssen. Zugleich soll die Website wie eine Website aussehen und sich die App wie eine App anfühlen.
Ein Headless-Content-Management-System trennt diese beiden Aufgaben: Informationen geordnet zu verwalten und festzulegen, wie sie den Lesern angezeigt werden. Diese Trennung kann sinnvoll sein. Ihr Nutzen hängt davon ab, was Sie veröffentlichen müssen und wer die Anbindungen entwickelt und pflegt.
Was bedeutet „headless“ eigentlich?
Ein CMS ist der Ort, an dem Redakteure Inhalte schreiben, organisieren und veröffentlichen. In einer herkömmlichen Konfiguration liefert es auch die Vorlagen, die aus diesen Inhalten Webseiten machen. Ein Headless-CMS überlässt die Darstellung einer separaten Website, App oder einer anderen Benutzeroberfläche.
Die beiden Seiten kommunizieren über eine API: eine vereinbarte Schnittstelle, über die eine Software Informationen von einer anderen anfordern kann. Die Website könnte Titel, Uhrzeit und Foto des Vortrags abfragen und in ihr eigenes Layout einsetzen. Die App kann dieselben Informationen anfordern und anders anordnen.
Strapi ist ein Beispiel dafür. Es stellt eine Bearbeitungsoberfläche, Inhaltsmodelle und APIs bereit, die Anwendungen nutzen können. Die API verschafft Entwicklern Zugang zu den Inhalten; die Gestaltung des Leseerlebnisses nimmt sie ihnen nicht ab.
Wo die Flexibilität nützlich wird
Ein Inhalt kann an mehreren Stellen verwendet werden. Die Uhrzeit des Vortrags kann in einem einzigen Feld stehen, statt auf mehrere unabhängig gepflegte Seiten kopiert zu werden. Jede Anwendung braucht weiterhin eine funktionierende Anbindung und eine Möglichkeit, Änderungen zu übernehmen. Eine alte Seite im Zwischenspeicher kann veraltet bleiben, bis sie aktualisiert wird.
Ein neues Design muss nicht bedeuten, jeden Artikel neu zu schreiben. Wenn Titel, Absätze, Bilder und Bildunterschriften unabhängig von einem bestimmten Seitenlayout gespeichert werden, kann ein neues Frontend sie wiederverwenden. Das funktioniert am besten, wenn das Inhaltsmodell das Material klar beschreibt, statt es als einen großen Block aus layoutspezifischem Markup zu speichern.
Unterschiedliche Leser können unterschiedliche Darstellungen erhalten. Ein Smartphonebildschirm, ein langer Artikel und eine Veranstaltungsanzeige stellen unterschiedliche Anforderungen. Dieselben zugrunde liegenden Informationen können für alle drei genutzt werden, ohne sie in dieselbe Vorlage zu zwängen.
Was Ihnen die Architektur nicht abnimmt
Headless bedeutet nicht automatisch schnell. Eine Seite kann im Voraus vorbereitet und rasch ausgeliefert werden. Sie kann aber auch erst eine Reihe langsamer Abfragen durchlaufen, bevor überhaupt etwas erscheint. Bilder, Zwischenspeicherung, Hosting und die Umsetzung des Frontends prägen weiterhin das Ergebnis. Die Trennung der Komponenten gibt einem Team die Wahl, an welchen Stellen es die Leistung verbessert und Kapazität ergänzt. Jemand muss diese Entscheidungen treffen und überprüfen.
Auch Redakteure brauchen mehr als ein Feld zum Tippen. Sie müssen einen Entwurf in der Vorschau ansehen, Links und Bilder prüfen, die richtige Sprachfassung veröffentlichen und eine frühere Version wiederherstellen können. Entwickler müssen diese Aufgaben mit dem neuen Frontend verbinden. Ein System, das im Architekturdiagramm elegant aussieht, kann die tägliche Veröffentlichungsarbeit dennoch umständlich machen.
Die gleiche Unterscheidung gilt für die Kontrolle über das System. Eine API legt nicht fest, wer die Regeln ändern darf, ob Sie alles exportieren können oder ob Sie weiter veröffentlichen können, wenn ein Anbieter seine Leistungen für Sie einstellt. Diese Fragen hängen von der Software, der Hostingvereinbarung, den Berechtigungen und einem praktisch gangbaren Weg zu einem anderen System ab.
Erproben Sie einen vollständigen Veröffentlichungsablauf
- Wählen Sie einen repräsentativen Inhalt, zum Beispiel einen Vortrag mit Foto, Datum, Beschreibung und einer zweiten Sprachfassung.
- Bitten Sie die Person, die ihn später bearbeiten wird, einen Entwurf anzulegen und sich die tatsächlichen Layouts von Website und App in der Vorschau anzusehen.
- Veröffentlichen Sie den Inhalt, ändern Sie die Uhrzeit und prüfen Sie, wann die Korrektur an jedem Ausgabeort erscheint.
- Stellen Sie die vorherige Version wieder her. Exportieren Sie Inhalte und Medien und prüfen Sie anschließend, was erforderlich wäre, um sie anderswo zu verwenden.
Dieser kleine Versuch verrät mehr als eine Funktionsliste. Er zeigt, ob die Architektur Ihrem Team nützliche Freiheiten verschafft und ob sich die tägliche Arbeit gut bewältigen lässt.
Wählen Sie die Architektur nach Ihrem Veröffentlichungsbedarf
Headless kann sehr gut passen, wenn mehrere Anwendungen dieselben strukturierten Inhalte benötigen oder wenn das Leseerlebnis umfangreiche individuelle Entwicklung erfordert. Für eine einfache Website mit nur einem Veröffentlichungsziel kann ein System, das Bearbeitung und Darstellung verbindet, weniger Arbeit bedeuten. Gehen Sie von der Arbeit aus und wählen Sie danach die Architektur.
Einen breiteren Vergleich bietet der Beitrag Wie Sie ein CMS nach Veröffentlichungsaufwand und Wechselmöglichkeiten auswählen.