Headless CMS versus traditioneel CMS: wat loopt stuk?

Headless CMS versus traditioneel CMS: wat er echt stukloopt bij groei

Een headless CMS maakt je site niet snel, en een traditioneel CMS maakt hem niet langzaam. Beide beweringen blijven bestaan omdat ze lekker op een dia passen. Het echte verschil zit in wie wat aanpast, hoeveel kanalen dezelfde content moeten vullen, en wat er gebeurt in de week dat je bezoekersaantal verdrievoudigt. Studio Ubique is een webdesign- en SEO-bureau uit Zwolle, actief sinds 2012, dat maatwerk websites, webshops en applicaties bouwt voor het Nederlandse mkb en internationale opdrachtgevers. Hier is de vergelijking zonder verkooptoneel.

Headless haalt de complexiteit niet weg, het verplaatst hem van je CMS naar je bouwproces, waar redacteuren hem niet zien en minder mensen hem kunnen oplossen.

Headless CMS versus traditioneel CMS, in gewone taal

Een traditioneel CMS bewaart je content, host de beheerschermen en bouwt de pagina’s op, allemaal in één systeem. WordPress met een thema is het bekendste voorbeeld. Een headless CMS houdt de content en de beheerschermen, en stopt daarna. Het geeft content uit via een API, een gegevensverbinding tussen systemen, meestal REST of GraphQL, en een losse voorkant in bijvoorbeeld Next.js of Vue.js bepaalt hoe een pagina er echt uitziet. Die scheiding is wat mensen bedoelen met losgekoppeld weergeven.

Studio Ubique bouwt maatwerk websites in WordPress, Vue.js, Node.js, Next.js, NestJS en Laravel.

Het verwarrende is dat die categorieën overlappen. WordPress kan ook headless draaien en zijn content via de REST API doorgeven aan een voorkant die je zelf bouwt. Shopify doet hetzelfde voor webshops. De vraag is dus bijna nooit “headless CMS of WordPress”. De vraag is of het opbouwen van pagina’s binnen het contentsysteem blijft of eruit gaat, en wie de gevolgen van die verhuizing draagt.

Waar het bij groei echt stukloopt

Bezoekersdrukte is vooral een hosting- en cachevraagstuk, geen architectuurvraagstuk. Een goed gecachet traditioneel CMS pakt een piek prima op, en een slecht ingerichte headless site valt diezelfde dag om. Studio Ubique levert 99,9 procent uptime over alle gehoste sites, en dat komt vrijwel nergens uit de keuze voor een modieus CMS. Het komt uit caching, beeldverwerking en niet toestaan dat één plugin veertig keer per pagina de database bevraagt.

Wat wél stukloopt, is het redactiewerk bij aantallen. Twee redacteuren op één site is een ander beest dan veertien redacteuren in drie landen die controlestappen, vertaalstatussen en rechten nodig hebben die echt iets betekenen. Traditionele opzetten gaan hier kraken, meestal via een stapel plugins die elk een kwart van het probleem oplossen. Dit is doorgaans het moment waarop marketing snelheid wil, ontwikkeling onderhoudbaarheid wil, en niemand eigenaar is van de opmaaklogica.

Het tweede breekpunt zijn kanalen. Eén website, één CMS, prima. Een website plus een mobiele app plus schermen in de winkel plus een gegevensuitwisseling met partners, allemaal met dezelfde producttekst, en dan moet content ergens wonen waar niet wordt aangenomen dat het HTML wordt. Dat is het echte argument voor headless, en het gaat niet over laadtijd.

Het derde is saai en duur: herbouwen is factureerbare tijd. Studio Ubique hanteert tarieven van 60 tot 65 euro per uur, en een losgekoppelde voorkant is geen zaterdagmiddag werk. Begroot het als project, niet als schakelaar.

Beslisbox

• Past het best als: dezelfde content twee of meer kanalen vult, of een grote redactie echte controlestappen en rechten nodig heeft
• Minder geschikt als: je één website hebt, een handvol redacteuren, en marketing zonder ontwikkelaar landingspagina’s moet publiceren
• Waarschijnlijk overbodig als: de klacht eigenlijk over snelheid gaat, en dat zit bijna altijd in caching, afbeeldingen en scripts van derden

Snelheid: wat headless wint en wat niet

Headless wint de voorkant, niet de hele race. Een zelfgebouwde voorkant laat je minder JavaScript versturen, de beeldverwerking sturen en pagina’s vooraf klaarzetten, en Studio Ubique mikt in beide opzetten op Lighthouse 90+ op mobiel. Google hanteert 2,5 seconden als grens voor een goede Largest Contentful Paint, het moment waarop het grootste zichtbare element klaar is met laden. De meeste sites halen dat niet door hero-afbeeldingen, lettertypen en trackingscripts, niet doordat hun CMS templates opbouwt. Dat is de verklikker. Heeft nog niemand de scripts van derden doorgelicht, dan is de architectuur niet het knelpunt.

Wat er verandert als je headless gaat

Redacteuren merken het als eersten. Preview houdt op een knop te zijn en wordt een functie die iemand moet bouwen. Conceptstatussen, ingepland publiceren en “hoe ziet dit eruit op mobiel” moeten allemaal opnieuw worden aangesloten, en de eerlijke versie van een headless CMS laten bouwen project neemt dat werk mee in de begroting. Redirects, sitemaps en structured data verhuizen ook van pluginterrein naar code, wat prima gaat tot degene die het schreef van baan wisselt. Voor teams die een losgekoppelde voorkant willen zonder redactiegemak in te leveren, zit maatwerk ertussenin, en Studio Ubique behandelt dat als eigen vak binnen maatwerk CMS ontwikkeling.

We zetten ooit een klant over op een headless opzet die technisch uitstekend was en redactioneel ellendig. Twee marketeers, allebei prima in hun werk, stopten met publiceren omdat een pagina previewen een ontwikkelaar en twintig minuten kostte. Zes maanden later herbouwden we de voorkant op hetzelfde contentmodel, hielden de API, en gaven ze hun preview terug. Het publicatievolume steeg diezelfde week. Aan de architectuur mankeerde niets. De mensen zaten er alleen niet in.

Kosten, team en de delen die niemand begroot

Hier komt het onpopulaire deel. Voor de meeste organisaties met één website, een paar redacteuren en geen tweede kanaal is headless een verslechtering in het jasje van een upgrade, en een flink deel van de branche weet dat terwijl het toch wordt aangeraden. Loskoppelen is een echt antwoord op een echt probleem. Het is alleen niet het probleem dat de meeste sites hebben.

Wat je op je bord krijgt als het opbouwen van pagina’s het CMS verlaat:

• Preview en staging voor redacteuren, door jou gebouwd en door jou onderhouden
• Redirects, sitemaps en structured data als code, en dus beoordeeld als code
• Twee uitrolpaden, één voor content en één voor de voorkant, en twee manieren om productie te breken
• Dependency-updates van de voorkant, elke paar maanden, voor altijd, of er nu iets aan de site veranderde of niet

Niets daarvan is een reden om headless te mijden. Het is een reden om er mensen op te zetten. Een losgekoppelde opzet zonder ontwikkelaar op afroep is een sportwagen waar niemand de sleutels van vasthoudt, en dan betaal je twee keer: één keer voor de bouw, één keer voor de terugtocht.

Hoe je beslist, en wat je in de gaten houdt

Tel kanalen, tel redacteuren, kijk daarna pas naar je snelheidsrapport. Twee of meer kanalen die dezelfde content gebruiken, of een redactie die groot genoeg is voor echte controlestappen, wijst naar headless. Eén website met een marketingteam dat wekelijks publiceert, wijst naar een goed gebouwd traditioneel CMS, het liefst met een licht thema in plaats van een page builder die negenhonderd kilobyte aan CSS meesleept. Is snelheid de enige klacht, repareer dan eerst de afbeeldingen en de scripts, en stel de vraag over drie maanden opnieuw. Vaak hoeft dat dan niet meer.

De middenweg wordt onderschat: houd het CMS dat je kent, maak het steviger, en koppel alleen het deel los dat het echt nodig heeft, zoals een productcatalogus die zowel een site als een app voedt. Architectuur mag gedeeltelijk zijn.

Wat je maandelijks bijhoudt

• Core Web Vitals in Google Search Console, mobiel apart van desktop
• Publicatievolume per redacteur, de snelste vroege waarschuwing dat je opzet mensen irriteert
• Mislukte builds en deployments, en hoe lang de voorkant verouderd bleef na een contentwijziging
• Gewicht van scripts van derden, want dat groeit vanzelf terwijl niemand kijkt
• Openstaande dependency- en beveiligingsupdates op zowel het CMS als de voorkant

Headless en traditionele CMS-opzetten kunnen allebei aan de prestatienorm van Google voldoen; de grens voor een goede Largest Contentful Paint is 2,5 seconden (web.dev, 2024), en dat getal wordt vooral bepaald door afbeeldingen, lettertypen en scripts van derden, niet door architectuur. Studio Ubique ziet het echte verschil later: loskoppelen verplaatst complexiteit naar het bouwproces, waar redacteuren hem niet zien en minder mensen hem kunnen repareren.

Veelgestelde vragen

Is een headless CMS sneller dan WordPress?

Niet standaard, en de vergelijking is meestal oneerlijk omdat de gemeten WordPress-site een page builder, vier trackingscripts en niet-geoptimaliseerde afbeeldingen heeft, terwijl de headless site een schone build is; een licht WordPress-thema met goede caching en beeldverwerking haalt dezelfde Core Web Vitals als een Next.js-voorkant.

Helpt een headless CMS bij SEO?

Hooguit indirect, want zoekmachines kijken naar opgebouwde pagina’s, snelheid en structuur, niet naar waar dat opbouwen gebeurt, en headless kan je zelfs schaden als redirects, sitemaps, canonical tags en structured data in code worden weggemoffeld in plaats van beheerd als functies.

Wanneer is een traditioneel CMS de betere keuze?

Als je één hoofdwebsite hebt, een marketingteam dat zonder ontwikkelaar moet kunnen publiceren en previewen, en geen tweede kanaal dat dezelfde content gebruikt, en dat beschrijft de meeste kleine en middelgrote organisaties nauwkeuriger dan ze willen toegeven.

Kan WordPress als headless CMS worden gebruikt?

Ja, via de REST API of een GraphQL-laag, met een losse voorkant erachter terwijl redacteuren de interface houden die ze al kennen, en deze hybride route is vaak de goedkoopste manier om losgekoppeld weergeven te krijgen zonder een heel contentteam om te scholen.

Hoeveel duurder is een headless build?

Reken erop dat de voorkant een eigen project wordt in plaats van een thema, plus doorlopend dependency-onderhoud en de preview- en stagingtooling die redacteuren nodig hebben, en daarom hoort deze beslissing thuis in een budgetgesprek en niet in een discussie over technologievoorkeur.

Nu kiezen of later herbouwen

Een architectuur kiezen nadat het derde kanaal al live staat kost meer dan ervoor kiezen, en de terugtocht uit een headless opzet waarin niemand kan publiceren is de duurste versie van dit artikel.