De voor- en nadelen van een headless CMS

Lijkt het je wel wat, content op één plek beheren? Of wil je content in veel talen of voor veel verschillende doelgroepen dynamisch laten uitserveren op basis van metadata? Wellicht biedt een headless CMS een oplossing. Lees in deze blog wat een headless CMS is, hoe het precies werkt en wat de voor- en nadelen zijn.

Waarom een headless CMS?

Sites, apps en intranetten zijn rijk aan content. En die content wordt vaak niet alleen op één site of op één plek op het intranet gepubliceerd. Maar je wilt de content wel graag op één plek beheren. Bovendien wil je misschien niet aan één leverancier vastzitten voor je website, want met je webshop verdien je een gedeelte van je boterham en gevangen zitten bij je leverancier is dan niet handig. Misschien wil je content ook wel in heel veel talen of voor veel verschillende doelgroepen dynamisch laten uitserveren op basis van metadata? Allemaal redenen om te kiezen voor een scheiding tussen de opslag van je content in een contentmanagementsysteem (CMS) en de presentatielaag van je website, app of intranet in een ander systeem. Zo’n contentmanagementsysteem noemen we een headless CMS.

Wat is een headless CMS?

Een headless CMS is een contentmanagementsysteem dat niet beschikt over een eigen presentatielaag. De content (tekst, beeld, evt. andere multimedia) wordt opgeslagen en via een API gedistribueerd. Doordat de content helemaal los van de publicatielaag kan worden opgeslagen is het mogelijk om die via allerlei verschillende kanalen te publiceren en elk kanaal zijn eigen presentatie mee te laten geven. Voorbeelden van headless CMS’en zijn Contentful, Prismic en Directus.

Hoe werkt een headless CMS?

Je ontkomt niet aan een paar meer afkortingen bij het bespreken van een headless CMS. Een headless CMS stelt de opgeslagen content namelijk beschikbaar via een API. Een API is een set afspraken waarmee je informatie uit een database kunt opvragen. Het CMS is in dit geval de database en door de juiste dingen aan de API te vragen kun je de content uit de database halen. Het format van de content die via een API ter beschikking wordt gesteld is vaak XML of JSON. Dat zijn vaste formats die te verwerken zijn door andere software.

Om te zorgen dat content beschikbaar is voor de website of andere kanalen wordt er vaak voor gekozen om de content uit de API op te vragen en vervolgens ergens in cache op te slaan. Dat betekent dat niet voor elke pagina die een gebruiker op de website bezoekt een verzoek aan de API hoeft te worden gedaan. En dat scheelt laadtijd.

De content die je via de API uit het CMS haalt kan vervolgens door andere software gepresenteerd worden. Doordat je een headless CMS kunt inrichten zoals je zelf wilt moet je de presentatielaag zelf bouwen.

De voordelen van een headless CMS

Flexibiliteit: Het grootste voordeel van een headless CMS is de flexibiliteit om je content zo te structureren als jij wilt. Vaak klik je de structuur zo bij elkaar. Je zit in de meeste gevallen ook niet aan een leverancier vast. Een export maken van een headless CMS en importeren in een ander headless CMS is vaak relatief eenvoudig. Zo kun je content migreren, terwijl je de presentatielaag (vaak front-end genoemd) en dus het design hetzelfde laat. Of relatief eenvoudig een heel nieuw design over bestaande content gooien. Dat is bij een traditioneel CMS vaak niet mogelijk.
Publiceren naar verschillende kanalen: als dit niet één van je doelen is, dan hoef je waarschijnlijk een headless CMS niet eens te overwegen. Gebruik van één contentplatform voor alle content, faciliteert hergebruik en vereenvoudigd contentbeheer (je hoeft bijvoorbeeld openingstijden maar op één plek aan te passen om het op alle kanalen te veranderen). En die kanalen kunnen ook heel goed offline kanalen zijn. Doordat content in XML/JSON beschikbaar is, kan het makkelijk verwerkt worden, ook in printstraten. Dat maakt het eenvoudig om van documenten altijd de laatste versie te drukken.
Combineren van bronnen: Een headless CMS maakt het eenvoudiger om verschillende bronnen van informatie met elkaar te combineren. Het beheer van bijvoorbeeld productinformatie is wat anders dan het beheer van langere beschrijvende content. Doordat het headless CMS via een API bereikbaar is, kan via eenzelfde techniek ook makkelijker andere data opgehaald en samen gepresenteerd worden.
Targetting: Een goede architectuur en taxonomie van content maakt het mogelijk om in een headless CMS niet in pagina’s te werken, maar in elementen. Die elementen worden voorzien van metadata, waardoor één webpagina voor elke gebruiker er anders uit kan zien, afhankelijk van de eigenschappen van die gebruiker. Doordat een headless CMS los staat van de front-end heb je veel meer vrijheid om die architectuur en taxonomie zo vorm te geven als jij wilt.

De nadelen van een headless CMS

Eigen code en onderhoud nodig: Het grootste nadeel van een headless CMS is dat je voor een ‘hoofdloos’ CMS wel ergens een hoofd moet hebben. Je moet zelf dus ergens een presentatielaag (front-end) bouwen en dat ook beheren. Dat betekent dat je volledig eigen code schrijft en die ook moet beheren. Als er een bug in de code blijkt te zitten na een paar maanden wordt die niet automatisch opgelost door de leverancier. Zo’n ‘patch’ (het stukje code dat de bug oplost) moet je zelf schrijven.
Flexibiliteit is ook een risico: je kunt je eigen code en je structuur ook zonder er al teveel over na te denken in elkaar zetten. Maar als je contentmodel staat en er een front-end op gebouwd is, blijkt de structuur toch maar moeilijk te wijzigen. Het is dus ook tijdens het bouwen van een site en een contentstructuur daarvoor enorm belangrijk om de hoofdlijnen van de structuur in de gaten te houden en op tijd bij te sturen. Zo voorkom je problemen achteraf.
Alles moet je zelf bouwen: Je moet niet alleen zelf de code schrijven en beheren, maar ook zelf een acceptatieomgeving bouwen. Zo’n omgeving heb je nodig om je code, maar ook je content te kunnen testen. Als je een heel nieuwe pagina maakt in wordpress kun je, voordat je het publiceert, op ‘preview’ klikken en je zien hoe je pagina eruit ziet op jouw website. Maar jouw CMS weet niet hoe je pagina eruit komt te zien, want het heeft niet een ingebouwde presentatielaag. Daar zul je dus ook zelf iets voor moeten regelen.
Overkill bij één kanaal: Het eigen werk zorgt ervoor dat een headless CMS een zware en kostbare oplossing is als je maar één kanaal hebt. Hoeft je content alleen maar gepubliceerd te worden op je website? En hoef je niet allemaal verschillende bronnen te combineren? Dan ben je waarschijnlijk beter af met een gebruikelijk CMS.

Succes van elk CMS hangt direct samen met de manier waarop het geïmplementeerd is.

Alternatief voor het headless CMS: decoupled CMS

Naar meerdere kanalen publiceren en toch eenvoudiger een presentatielaag inrichten? Dan is een decoupled CMS misschien een goed alternatief. Een decoupled CMS is namelijk een beetje een headless CMS en een beetje een traditioneel CMS: het lijkt op een headless CMS, omdat het opgeslagen content via een API ter beschikking stelt, maar het heeft ook een publicatielaag (front-end) zoals een traditioneel CMS. Voordeel is dat je beschikt over een publicatielaag en die dus niet helemaal zelf hoeft te bouwen en toch is je content via een API beschikbaar om te publiceren in andere kanalen. Het decoupled CMS is een evolutie van het traditionele CMS.

Een decoupled CMS lijkt ook op een traditioneel CMS, omdat het je vaak niet de volledige flexibiliteit geeft om je content en je front-end los van elkaar zo in te richten als je zelf wilt. Wel heb je een publicatielaag die goed is afgestemd op je content en toch de beschikking over je content om het op andere plekken te publiceren via de API.

Wat kies jij?

De keuze voor een headless CMS is dus vooral afhankelijk van complexiteit van de content en kanalen die je wilt bedienen. Hoe meer kanalen en hoe meer bronnen je wilt ontsluiten en hoe dynamischer je content moet zijn, hoe groter de kans dat een headless CMS een goede optie is.

Succes van elk CMS hangt wel direct samen met de manier waarop het geïmplementeerd is. Het contentmodel (structuur en metadata) zijn essentieel voor hoe bruikbaar én ook beheersbaar de content is.