Headless CMS: Content Schalen met Next.js

In 2015 dreef WordPress ongeveer 25% van het gehele web. Het was de standaardkeuze voor vrijwel elke website die een contentmanagementsysteem nodig had. Tien jaar later is het marktaandeel in absolute termen zelfs gegroeid — maar de relevantie voor moderne, hoogpresterende webapplicaties is sterk afgenomen.

De reden is architecturaal. WordPress is ontworpen in een tijdperk waarin een website een enkele monolithische eenheid was: één PHP-applicatie die content beheerde, HTML renderde, routing afhandelde, formulieren verwerkte en e-mails verstuurde. Dit maakte het gemakkelijk om iets werkends te bouwen. Het maakte het erg moeilijk om iets te bouwen dat snel, schaalbaar en composeerbaar was.

De headless-revolutie ontbundelt dit monoliet. Contentbeheer wordt zijn eigen systeem. Frontend-rendering wordt zijn eigen systeem. Deze systemen communiceren via API's, en elk kan onafhankelijk geoptimaliseerd worden.

Wat "Headless" Werkelijk Betekent

De term is een metafoor. Een traditioneel CMS heeft een "hoofd" — de frontendlaag die de HTML rendert die een bezoeker ziet. Het "headless"-concept verwijdert dit hoofd volledig.

Het CMS wordt een puur contentrepository: een database van gestructureerde content met een API (doorgaans REST of GraphQL) die elke client kan bevragen. Je Next.js-frontend is zo'n client. Een mobiele app is een andere. Een spraakinterface, een digitaal bewegwijzeringssysteem, of een e-mail renderengine zouden allemaal aanvullende clients kunnen zijn die dezelfde content consumeren.

Deze architectuur heeft drie fundamentele voordelen:

Performance: Je Next.js-site kan tijdens build-tijd het CMS bevragen, alle content vooraf renderen als statische HTML, en het serveren vanuit Vercel's Edge Network met een TTFB onder de 50ms wereldwijd. Er is geen PHP die uitvoert op een server, geen MySQL-query die bij elk verzoek draait, geen WordPress-plugin overhead. Alleen statische HTML, geleverd op de snelheid van een CDN.

Beveiliging: WordPress is het meest aangevallen CMS op het internet, voornamelijk omdat PHP-uitvoering, een database en een loginpaneel beschikbaar zijn op een voorspelbare URL (/wp-admin). Een headless site heeft geen server-side uitvoeringslaag om aan te vallen. Het CMS-adminpaneel is een aparte service, volledig ontkoppeld van de publieke website.

Developer experience: Bouwen in Next.js geeft je het volledige React-ecosysteem, TypeScript-ondersteuning, hot module reloading, componentisolatie en toegang tot elke moderne frontend-tool en -bibliotheek.

De Renderingstrategie Beslissing

De belangrijkste architecturale beslissing in een headless Next.js-project is het kiezen hoe en wanneer content wordt opgehaald en gerenderd.

Static Site Generation (SSG) met generateStaticParams

Voor content die niet per verzoek verandert — blogposts, case studies, servicepagina's, marketingtekst — is SSG de optimale aanpak. Tijdens next build voert Next.js generateStaticParams() uit om alle paden te inventariseren die vooraf gerenderd moeten worden, haalt de content op voor elk pad vanuit je CMS en produceert statische HTML-bestanden.

export async function generateStaticParams() {
  const artikelen = await sanityClient.fetch(
    `*[_type == "artikel"]{ "slug": slug.current }`
  );
  return artikelen.map((artikel) => ({ slug: artikel.slug }));
}

Deze statische bestanden worden uitgerold op Vercel's globale CDN. Een bezoeker in Amsterdam krijgt dezelfde respons van onder de 100ms als een bezoeker in Sydney. Er is geen server betrokken, geen databasequery, geen renderwerk op het kritieke pad.

Incremental Static Regeneration (ISR)

SSG heeft een beperking: wanneer de content in het CMS verandert, is de statische HTML verouderd totdat de volgende build. Voor drukbezochte sites met regelmatig bijgewerkte content is de hele site herbouwen bij elke content-update onpraktisch.

ISR lost dit op met een revalidate-optie in de fetch-aanroep:

const data = await fetch(cmsApiUrl, {
  next: { revalidate: 3600 } // Hervalideer elk uur
});

Met ISR wordt een verouderde pagina onmiddellijk geserveerd (geen vertraging voor de gebruiker) terwijl Next.js de pagina op de achtergrond regenereert. Na voltooiing van de achtergrondregeneratie krijgt het volgende verzoek de nieuwe versie. De gebruikerservaring is altijd snel; de content is uiteindelijk actueel.

On-demand Hervalidatie via Webhooks

Voor een meer directe aanpak configureer je je CMS om een Next.js hervalidatie-eindpunt aan te roepen wanneer content gepubliceerd wordt. Sanity ondersteunt dit native via zijn GROQ-aangedreven webhooks.

Wanneer een content-editor een nieuw artikel publiceert, stuurt Sanity een POST-verzoek naar je Next.js-eindpunt:

// app/api/revalidate/route.ts
export async function POST(req: Request) {
  const { secret, slug } = await req.json();

  if (secret !== process.env.REVALIDATION_SECRET) {
    return Response.json({ message: 'Ongeldig secret' }, { status: 401 });
  }

  revalidatePath(`/nl/journal/${slug}`);
  revalidatePath(`/en/journal/${slug}`);

  return Response.json({ gehervalideerd: true });
}

De pagina wordt on-demand geregenereerd, binnen seconden na publicatie. De site blijft statisch en snel; de content is altijd actueel.

Een Headless CMS Kiezen: Sanity vs. Contentful vs. Payload

Sanity

Sanity is onze voorkeursoptie voor de meeste projecten bij Ruberio. Sterktes zijn de developer experience (GROQ — Sanity's querytaal — is expressiever dan REST en bijna even krachtig als GraphQL), de realtime-samenwerkingsfuncties en de diepgaand aanpasbare Studio-interface.

Het schema-definitiemodel — TypeScript schrijven om je contentschema te definiëren — geeft je nauwkeurige controle over het contentmodel en zorgt voor type-veiligheid door de gehele stack. De Studio kan gehost worden binnen je Next.js-project (/studio) of als een aparte Sanity-gehoste applicatie.

Contentful

Contentful is de enterprise-standaard. Het biedt hogere beschikbaarheids-SLA's, enterprise-grade toegangscontrole en een contentmodel dat vertrouwd aanvoelt voor gebruikers die komen van traditionele CMS-tools. De belangrijkste zwakheden ten opzichte van Sanity zijn een meer beperkte querytaal en een stijvere Studio-UI.

Voor grote organisaties met meerdere contentteams, compliancevereisten en complexe content-governance-behoeften is Contentful vaak de juiste keuze.

Payload CMS

Payload is de meest interessante nieuwkomer in de headless CMS-ruimte. Het is een zelf-gehost, open-source CMS dat naast je Next.js-applicatie draait als een backend-service. Je contentschema wordt gedefinieerd in TypeScript, het genereert automatisch een volledige REST en GraphQL API, en het adminpaneel is gebouwd in React.

Het voordeel is volledige eigenaarschap: geen maandelijkse CMS-abonnementskosten, geen vendor lock-in, volledige controle over het databaseschema. Het nadeel is operationele complexiteit: je bent verantwoordelijk voor hosting, back-ups en het schalen van de Payload-server.

Het Performance Resultaat

Toen we de Ruberio-website herbouwden op Next.js met statische generatie, waren de prestatiecijfers overtuigend:

• Time to First Byte: Onder de 50ms (voorheen ~800ms op beheerde WordPress-hosting)
• Largest Contentful Paint: Onder de 1,0s (voorheen 3,2s)
• Lighthouse Performance Score: 97 (voorheen 41)
• Total Blocking Time: 0ms (voorheen 2.300ms van plugin-JavaScript)
• Cumulative Layout Shift: 0,02 (voorheen 0,34)

Deze cijfers vertalen zich direct naar zoekrangschikkingen, gebruikersbehoud en conversie. Een gebruiker die aankomt op een pagina die in minder dan een seconde laadt, blijft langer, ziet meer en converteert vaker.

Dat is de businesscase voor headless, uitgedrukt in data.