Wat is headless en Jamstack?
Bij een klassieke website doet één systeem alles: het CMS bewaart de inhoud én bepaalt hoe de pagina eruitziet. Bij een headless opzet worden die twee uit elkaar getrokken. Het CMS wordt een opslagplaats voor inhoud die zijn gegevens via een API beschikbaar stelt, en een aparte toepassing haalt die gegevens op en bepaalt hoe ze worden getoond. De presentatielaag, de kop, is eraf gehaald.
Jamstack is een verwante maar andere term. Die beschrijft een bouwwijze waarbij pagina’s vooraf worden gegenereerd tot kant en klare bestanden, die vervolgens worden uitgeleverd vanaf servers dicht bij de bezoeker. Er hoeft dan bij een bezoek niets meer berekend te worden, wat zeer snel kan zijn. Dynamische onderdelen zoals zoeken of een winkelwagen lopen via aparte diensten.
De aantrekkingskracht zit in vrijheid en snelheid. Je kiest de techniek voor de voorkant los van het CMS, je kunt dezelfde inhoud voeden aan een website, een app en een informatiescherm, en je kunt zeer hoge bezoekersaantallen aan zonder zware serverinfrastructuur. De prijs daarvoor is dat er meer losse onderdelen zijn, en elk onderdeel is iets dat kan stukgaan, updates nodig heeft en beheerd moet worden.
Wat valt er precies onder?
Een headless opzet bestaat uit meerdere samenwerkende onderdelen, die elk apart worden gekozen en ingericht.
- Headless CMS: het systeem waarin redacteuren de inhoud beheren, zonder eigen presentatielaag.
- API-laag: het aansluitpunt waarlangs inhoud wordt opgevraagd, meestal via REST of GraphQL.
- Frontend-toepassing: het programma dat de inhoud ophaalt en de pagina’s opbouwt, vaak met een framework als Next.js of Nuxt.
- Bouwproces: het genereren van pagina’s, hetzij vooraf voor alle pagina’s, hetzij alleen voor wat gewijzigd is.
- Uitleverlaag: een netwerk van servers dat de gegenereerde bestanden dicht bij de bezoeker beschikbaar houdt.
- Dynamische diensten: aparte voorzieningen voor zoeken, formulieren, authenticatie of betalingen.
- Voorbeeldweergave: een omgeving waarin redacteuren zien hoe een pagina eruitziet voordat die wordt gepubliceerd.
- Bewaking: monitoring van zowel het CMS als het bouwproces en de uitleverlaag, omdat een storing overal kan ontstaan.
Hoe verloopt een headless traject?
Een headless project vraagt meer keuzes vooraf dan een klassieke site, omdat de onderdelen los van elkaar worden gekozen.
- Bepalen of het nodig is. Er wordt vastgesteld welk concreet probleem de scheiding oplost, bijvoorbeeld meerdere kanalen of extreme bezoekersaantallen.
- Onderdelen kiezen. CMS, frontend-framework en uitleverpartij worden geselecteerd, met aandacht voor hoe gangbaar ze zijn en wat ze op termijn kosten.
- Inhoudsmodel ontwerpen. De structuur van de inhoud wordt vastgelegd los van de vormgeving, wat een andere manier van denken vraagt van redacteuren.
- Frontend bouwen. De toepassing wordt gebouwd die de inhoud ophaalt en de pagina’s samenstelt, inclusief het gedrag bij ontbrekende gegevens.
- Redactieomgeving inrichten. Er wordt gezorgd voor een bruikbare voorbeeldweergave, zodat redacteuren niet blind publiceren.
- Uitrol en bewaking. Het bouw- en publicatieproces wordt geautomatiseerd en er wordt bewaking ingericht op alle onderdelen afzonderlijk.
Wanneer heb je dit nodig?
De sterkste reden is meerdere kanalen. Als dezelfde inhoud moet verschijnen op een website, in een app en op schermen in een winkel of wachtruimte, is één centrale bron met API’s aanzienlijk efficiënter dan de inhoud op drie plekken bijhouden.
Een tweede reden is zeer hoge of onvoorspelbare bezoekersaantallen. Vooraf gegenereerde pagina’s die vanaf een verspreid netwerk worden uitgeleverd, houden een piek moeiteloos aan zonder dat er servers meeschalen.
Ook een bestaand systeem dat de inhoud al beheert kan de aanleiding zijn: als een organisatie al een productinformatiesysteem of een centraal contentplatform heeft, ligt het voor de hand de website daaruit te voeden. En bij teams met eigen frontend-ontwikkelaars geeft de scheiding vrijheid om de voorkant te ontwikkelen zonder afhankelijk te zijn van de beperkingen van een CMS.
Wat levert het op?
De opbrengst zit in flexibiliteit en in snelheid bij het uitleveren. Inhoud wordt eenmaal onderhouden en overal hergebruikt, en de voorkant kan worden vervangen zonder aan het CMS te komen. Vooraf gegenereerde pagina’s laden zeer snel en zijn ongevoelig voor pieken, en de aanvalsoppervlakte is kleiner omdat er bij een bezoek geen database wordt aangesproken.
Daar staat een reële toename van complexiteit tegenover. Er zijn meer onderdelen, van meer leveranciers, met elk hun eigen updates, storingen en kosten. Bij een probleem is de eerste vraag welk onderdeel de oorzaak is, en dat maakt storingzoeken langzamer. Redacteuren leveren doorgaans gemak in, omdat het directe verband tussen bewerken en zien verdwijnt tenzij daar apart in wordt geïnvesteerd. Bureaus die headless aanbieden als vanzelfsprekende verbetering, laten die kosten en dat gemis meestal buiten beschouwing. Voor een gewone bedrijfswebsite met één kanaal is een goed ingerichte klassieke opzet vaak eenvoudiger, goedkoper en even snel.
Waar let je op als je dit uitbesteedt?
Vraag als eerste welk concreet probleem de headless opzet oplost in jouw situatie. Als het antwoord blijft steken in snelheid of moderniteit, is dat een signaal: snelheid is ook met caching op een klassiek CMS goed te bereiken. Een overtuigend antwoord verwijst naar meerdere kanalen, naar een bestaande centrale contentbron of naar bezoekersaantallen die een klassieke opzet niet aankan.
Vraag vervolgens naar de redactieomgeving. Laat concreet zien hoe iemand een pagina bewerkt en hoe hij ziet wat het resultaat wordt. Vraag ook hoe lang het duurt voordat een wijziging live staat bij jouw aantal pagina’s. Breng verder de terugkerende kosten in kaart: een headless opzet bestaat uit meerdere abonnementen die met bezoekersaantallen of met het aantal bouwacties kunnen meegroeien. Vraag ten slotte wie eindverantwoordelijk is bij een storing, want met meerdere leveranciers verwijzen partijen makkelijk naar elkaar.
Veelgemaakte fouten
De problemen ontstaan vrijwel altijd doordat de architectuur wordt gekozen voordat het probleem is vastgesteld.
- Headless kiezen zonder aanleiding. Voor een site met één kanaal en normale bezoekersaantallen levert de scheiding vooral extra kosten en onderhoud op.
- De redactie vergeten. Zonder bruikbare voorbeeldweergave publiceren redacteuren blind, wat leidt tot fouten en tot ontevredenheid over de nieuwe site.
- Terugkerende kosten onderschatten. Meerdere abonnementen die meegroeien met verkeer of bouwacties, kunnen samen fors oplopen ten opzichte van een enkele hostingpost.
- Geen duidelijk aanspreekpunt bij storingen. Met een CMS, een hostingpartij en een uitlevernetwerk is onduidelijk wie verantwoordelijk is als iets uitvalt.
Wat bepaalt de prijs?
De prijs wordt bepaald door het aantal onderdelen dat wordt ingericht en door de mate waarin de redactieomgeving op maat wordt gemaakt. Ook de terugkerende licentiekosten wegen zwaarder dan bij een klassieke opzet.
| Wat de prijs opdrijft | Waarom het meetelt |
|---|---|
| Aantal gekoppelde systemen | Elk onderdeel vraagt eigen inrichting, eigen testwerk en eigen beheer na oplevering. |
| Maatwerk in de redactieomgeving | Een bruikbare voorbeeldweergave en prettige bewerkfuncties zijn extra bouwwerk dat er niet standaard in zit. |
| Aantal kanalen | Elke extra uitleveringsvorm, zoals een app of een scherm, vraagt een eigen presentatielaag. |
| Terugkerende licentiekosten | Abonnementen voor CMS en uitlevernetwerk groeien vaak mee met bezoekersaantallen of publicaties. |
De bouw wordt doorgaans op projectbasis aangeboden, met daarnaast een maandelijkse post voor onderhoud en voor de licenties van de gebruikte diensten. Laat die maandelijkse kosten expliciet begroten voor een realistisch bezoekersaantal, inclusief wat er gebeurt bij groei. Vraag ook of het bureau de licenties doorbelast of dat je die zelf afneemt, want dat maakt uit voor de zeggenschap als je later wilt overstappen.
Headless en Jamstack en aanverwante diensten
Headless is een architectuurkeuze en raakt daardoor aan de hele bouwketen. Headless CMS is het systeem waarin de inhoud wordt beheerd en is in feite de helft van deze opzet. Frontend-development weegt hier zwaarder dan bij een klassieke site, omdat de complete presentatielaag zelf wordt gebouwd. Koppelingen en API’s vormen de verbinding tussen de onderdelen en zijn bepalend voor de betrouwbaarheid van het geheel. Backend en maatwerk komt in beeld voor de dynamische onderdelen die niet vooraf te genereren zijn, zoals zoeken of een winkelwagen. En hosting en onderhoud verandert van karakter: in plaats van één server beheer je een keten van diensten. In Nederland bieden vooral bureaus met eigen ontwikkelcapaciteit dit aan; voor een gewone bedrijfssite raden veel van hen het zelf af.