HQ

Ruberio
Burgemeester ter veerstraat 15
5066 GK Moergestel (Nederland)

Socials

Let's
Build
Greatness
Back to Overview
Development2025-09-22Ruberio Team

Headless CMS: Scaling Content with Next.js

Headless CMS: Scaling Content with Next.js

In 2015, WordPress powered approximately 25% of the entire web. It was the default choice for virtually every website that needed a content management system, from personal blogs to Fortune 500 marketing sites. Ten years later, its market share has actually grown in raw terms — but its relevance for modern, high-performance web applications has declined sharply.

The reason is architectural. WordPress was designed in an era when a website was a single monolithic unit: one PHP application that managed content, rendered HTML, handled routing, processed forms, and sent emails. This made it easy to build something that worked. It made it very difficult to build something that was fast, scalable, and composable.

The headless revolution unbundles this monolith. Content management becomes its own system. Frontend rendering becomes its own system. These systems communicate through APIs, and each can be optimized independently.

What "Headless" Actually Means

The term is a metaphor. A traditional CMS has a "head" — the frontend layer that renders the HTML a visitor sees. WordPress's head is its template system (PHP + WP-theming). The "headless" approach removes this head entirely.

The CMS becomes a pure content repository: a database of structured content with an API (typically REST or GraphQL) that any client can query. Your Next.js frontend is one such client. A mobile app is another. A voice interface, a digital signage system, or an email rendering engine could all be additional clients consuming the same content.

This architecture has three foundational advantages:

Performance: Your Next.js site can query the CMS at build time, pre-render all content as static HTML, and serve it from Vercel's Edge Network with TTFB under 50ms globally. There is no PHP executing on a server, no MySQL query running on every request, no WordPress plugin overhead. Just static HTML, delivered at the speed of a CDN.

Security: WordPress is the most attacked CMS on the internet, primarily because PHP execution, a database, and a login panel are exposed at a predictable URL (/wp-admin). A headless site has no server-side execution layer to attack. The CMS admin panel is a separate service, typically behind authentication, entirely decoupled from the public website.

Developer experience: Building a frontend in Next.js gives you the full React ecosystem, TypeScript support, hot module reloading, component isolation, and access to every modern frontend tool and library. Building in WordPress templates means PHP, functions.php, plugin dependencies, and the constant risk of plugin conflicts.

The Rendering Strategy Decision

The most important architectural decision in a headless Next.js project is choosing how and when content is fetched and rendered.

Static Site Generation (SSG) with generateStaticParams

For content that does not change per request — blog posts, case studies, service pages, marketing copy — SSG is the optimal approach. During next build, Next.js runs generateStaticParams() to enumerate all the paths that need to be pre-rendered, fetches the content for each path from your CMS, and produces static HTML files.

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

These static files are deployed to Vercel's global CDN. A visitor in Tokyo gets the same sub-100ms response as a visitor in Amsterdam. There is no server involved, no database query, no rendering work on the critical path.

Incremental Static Regeneration (ISR)

SSG has a limitation: when the content in the CMS changes, the static HTML is stale until the next build. For high-traffic sites with frequently updated content, rebuilding the entire site on every content update is impractical.

ISR solves this with a revalidate option in the fetch call:

const data = await fetch(cmsApiUrl, {
  next: { revalidate: 3600 } // Revalidate every hour
});

With ISR, a stale page is served immediately (no delay for the user) while Next.js regenerates the page in the background. After the background regeneration completes, the next request gets the fresh version. The user experience is always fast; the content is eventually consistent.

On-Demand Revalidation via Webhooks

For a more immediate approach, configure your CMS to call a Next.js revalidation endpoint whenever content is published. Sanity supports this natively via its GROQ-powered webhooks.

When a content editor publishes a new article, Sanity sends a POST request to your Next.js endpoint:

// 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: 'Invalid secret' }, { status: 401 });
  }

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

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

The page is regenerated on-demand, within seconds of publication. The site remains static and fast; the content is always current.

Choosing a Headless CMS: Sanity vs. Contentful vs. Payload

Sanity

Sanity is our preferred choice for most projects at Ruberio. Its strengths are its developer experience (GROQ — Sanity's query language — is more expressive than REST and nearly as powerful as GraphQL), its real-time collaboration features, and its deeply customizable Studio interface.

The schema definition model — writing TypeScript to define your content schema — gives you precise control over the content model and ensures type safety throughout the stack. The Studio can be hosted within your Next.js project (/studio) or as a separate Sanity-hosted application.

Sanity's @sanity/image-url library handles automatic image optimization, format conversion, and CDN delivery, making it a complete asset management solution.

Contentful

Contentful is the enterprise standard. It offers higher availability SLAs, enterprise-grade access control, and a content model that feels familiar to users coming from traditional CMS tools. Its main weaknesses relative to Sanity are a more limited query language (REST-based, though GraphQL is available) and a more rigid Studio UI.

For large organizations with multiple content teams, compliance requirements, and complex content governance needs, Contentful is often the correct choice.

Payload CMS

Payload is the most interesting new entrant in the headless CMS space. It is a self-hosted, open-source CMS that runs alongside your Next.js application as a backend service. Your content schema is defined in TypeScript, it generates a full REST and GraphQL API automatically, and the admin panel is built in React.

The advantage is complete ownership: no monthly CMS subscription, no vendor lock-in, full control over the database schema. The disadvantage is operational complexity: you are responsible for hosting, backups, and scaling the Payload server.

For projects where budget and data sovereignty are priorities, Payload is worth serious consideration.

Structured Content and the SEO Advantage

The SEO benefits of headless architecture compound when you structure your content with SEO metadata as first-class fields.

In a Sanity schema, you can define a seo object that content editors fill in alongside the article:

defineField({
  name: 'seo',
  type: 'object',
  fields: [
    defineField({ name: 'title', type: 'string' }),
    defineField({ name: 'description', type: 'string' }),
    defineField({ name: 'ogImage', type: 'image' }),
    defineField({ name: 'noIndex', type: 'boolean' }),
  ]
})

These fields flow directly into Next.js's generateMetadata function, producing perfectly structured <title>, <meta> and Open Graph tags on every page. Content editors control SEO metadata directly, without touching code or a plugin.

Combined with Schema.org JSON-LD structured data (also generated programmatically from the content fields), this creates an SEO implementation that is fundamentally superior to what any WordPress SEO plugin can produce.

The Performance Outcome

When we rebuilt the Ruberio website on Next.js with static generation, the performance numbers were stark:

  • Time to First Byte: Under 50ms (previously ~800ms on managed WordPress hosting)
  • Largest Contentful Paint: Under 1.0s (previously 3.2s)
  • Lighthouse Performance Score: 97 (previously 41)
  • Total Blocking Time: 0ms (previously 2,300ms from plugin JavaScript)
  • Cumulative Layout Shift: 0.02 (previously 0.34)

These numbers translate directly into search rankings, user retention, and conversion. A user who arrives at a page that loads in under a second stays longer, sees more, and converts more often. That is the business case for headless, expressed as data.

The Right Choice For Your Project

Headless is not the right architecture for every project. A small business owner who needs to update their own content without any developer assistance may be better served by a well-maintained WordPress installation with a simple, fast theme.

But for any business where the website is a significant commercial asset — where organic search traffic, brand perception, and conversion rate are measurable and meaningful — the headless + Next.js architecture is the current standard for professional results.

We have built it. We have measured the difference. The data is unambiguous.