Alles over headless CMS

Vaak wordt dan ook duidelijk dat het begrip verschillend wordt gebruikt. Het leek me dan ook goed om uit te leggen wat bedoeld wordt met een headless CMS, wanneer het een goede oplossing is en wanneer niet.

Wat betekent dat precies, headless?

Met de term headless CMS doelen we op een contentmanagementsysteem dat content levert via een publieke API, in een indeling die door alle systemen verwerkt en verspreid kan worden (zo’n indeling heet ook wel agnostisch).

Andere CMS-systemen leveren hun content in een geformatteerde opmaak. Dit noemen we ook wel een traditional, coupled of non-headless CMS.

Hoe verschillen deze twee typen van elkaar? De output van een non-headless CMS bevat onder meer onze front-end-code. Dit CMS is gekoppeld aan onze stijlen en formattering.

Wanneer we een nieuwe website zouden bouwen of een mobiele applicatie zouden ontwikkelen met een ander ontwerp, lopen we tegen een probleem aan. We zouden ofwel een nieuw CMS moeten bouwen om de content te leveren voor onze nieuwe doelapplicatie, of de manier waarop het CMS zelf de content levert moeten veranderen, om te zorgen dat deze herbruikbaar is.

In mijn ervaring kiezen mensen er dan vaak voor een deel van de content te selecteren en naar het nieuwe CMS te kopiëren.

Een headless oplossing is agnostisch tot de front end. Zolang we ervoor zorgen dat de front end alles kan verwerken en stileren (op elk uniek systeem), hoeven we om content aan te passen helemaal niets in het CMS te wijzigen.

Daarbij maakt het niet uit hoeveel content het front-end gebruikt; er treden geen afhankelijkheden of belasting van het CMS op.

Dat is alles.

Als een leverancier van een CMS zegt dat deze een headless systeem heeft, betekent dat, dat de door het systeem beheerde content via een publieke API beschikbaar kan worden gemaakt.

Welke nadelen kleven er aan een headless CMS?

Het eerste – en waarschijnlijk grootste – nadeel is dat je programmeurs alle formattering bij de front-end moeten aanpakken.

Als een contenteditor bijvoorbeeld cursieve tekst aanlevert, moet het apparaat dat de content weergeeft, overweg kunnen met deze indeling en daarvoor een oplossing achter de hand hebben.

Dit is een nadeel, hoewel het voor mobiele apparaten positief kan uitpakken. Deze willen nog weleens crashen als het met een onbekende indeling te maken krijgt. Maar als een ontwikkelaar een bepaalde indeling niet heeft ondersteund, valt de schade bij een headless systeem vaak wel mee; meestal wordt de copy op het mobiele device dan gewoon als platte tekst weergegeven.

Een ander nadeel is dat je waarschijnlijk je gemaakte wijzigingen niet kunt previewen. Je CMS weet immers niet welke indeling zal volgen – en kan je dus geen voorbeeld geven van hoe de tekst eruit zal zien. Hier bestaan zeker oplossingen voor, maar de configuratie daarvan vereist behoorlijk wat werk.

Bovendien is er geen standaard indeling voor headless geleverde content. Dat betekent dat de verschillende platforms hun content op verschillende manieren zullen leveren.

Wat zijn de voordelen van headless?

Met een headless CMS kun je content op veel meer manieren gebruiken dan met een traditionele oplossing.

Een headless oplossing zorgt voor (over)draagbare content. Als je een nieuwe site of app wilt lanceren, of teksten beschikbaar wilt maken voor mensen, hoef je niets te wijzigen aan de content. Je kunt het dus waarschijnlijk heel lang volhouden voordat het woord contentmigratie valt.

Je content is onafhankelijk van je digitale producten en hun levenscyclus, en kan dus (her)gebruikt worden wanneer jij dat wilt.

Wanneer je je content headless beschikbaar maakt, krijgen je ontwikkelaars ook meer mogelijkheden.

Met de oplossingen van onder meer Gatsby en Next.js beschik je tijdens de programmeerfase over een eenvoudige workflow om content van je CMS te verzamelen en weer te geven. Dat betekent dat op het moment dat je content online staat, gebruikers niet hoeven te wachten op verzoeken aan het CMS, maar dat die content snel in statische vorm wordt geleverd.

Moet je kiezen?

Voordat je overstapt naar een aanbieder van een headless oplossing, is het verstandig om eerst te praten met je huidige aanbieder en te informeren of die je content headless kan leveren. Veel traditionele CMS-systemen zijn verbeterd en inmiddels uitgerust met een headless functie. Misschien is het enkel een kwestie van configureren, in plaats van een migratie van al je content.

Kort samengevat

Een headless CMS is in veel gevallen een buitengewoon krachtige oplossing, maar niet altijd.

De manier waarop we content verspreiden en consumeren is snel aan het veranderen. De markt voor headless systemen was in 2020 goed voor $ 328,5 miljoen USD. Naar verwachting is die waarde in 2021 $ 1,6 miljard USD.

Als je voor het eerst investeert in een systeem voor contentbeheer, zijn er steeds meer redenen om headless te gaan. Denk dus goed na over hoe je je content wilt (her)gebruiken als je nog geen CMS hebt.