A setup in which the CMS only manages the content and delivers it through an API, while a separate frontend builds the pages.

Is headless always faster?

Not by itself. The speed comes from pages that are ready before anyone asks for them. A monolith with good caching can be fast too.

Can an editor still make pages in a headless Drupal?

Yes. The editor works in Drupal and places blocks on a page; the frontend decides how those blocks look.

Is headless more expensive?

Usually: you build and maintain two systems, and part of what Drupal does as standard you rebuild in the frontend.

Headless or monolith: the pros and cons

Two ways to build a site

In a monolith one application does everything. Drupal stores the content, and with its theme Drupal also turns it into the HTML pages. One system, one server, one update.

In headless, the CMS is only the place where the content lives. It delivers that content through an API, and a separate frontend builds the pages. On this site that is Drupal with GraphQL as the API, and Next.js as the frontend. The editor works in Drupal as always; the visitor only sees what Next.js makes.

Follow one page view

What happens when someone requests this page, and what happens when an editor changes it afterwards.

A page on brandbrand.nl

A visitor requests a page. Next.js already has it ready and sends it back at once. Drupal is not involved.
When a page is requested for the first time, Next.js asks Drupal for the content through GraphQL.
Next.js turns it into HTML, sends that to the visitor and keeps the page for the next one.
An editor changes the text in Drupal and saves.
Drupal tells Next.js which pages changed. Those are made again; the rest stays as it is.

What headless gives you

Speed. Pages are ready before anyone asks for them. The CMS does not have to do work on every visit.
Frontend freedom. The pages are built with modern components, with their own design system and interactive parts, without the limits of a CMS theme.
One source for more channels. The same content can go to the site, an app or another system.
Separate parts. The frontend and the CMS are updated and scaled separately. The visitor does not talk to the CMS directly.

What headless costs

Two systems. Two servers, two sets of updates, two things that can break. Everything you maintain once in a monolith, you do twice here.
What Drupal gave you for free, you build yourself. Previewing before publishing, menus, forms, redirects, metadata for search engines: in a monolith it is built in, headless the frontend has to take it over.
A cache you have to understand. When does a change show, and which pages have to be made again? That has to be right, or a visitor sees old content.
Order during an update. The frontend needs the CMS to build pages. If both go through an update at the same time, one can end up waiting for the other. It happened on this site: the new frontend could not be built while Drupal was in maintenance.
More knowledge in the team. PHP for Drupal, JavaScript for the frontend, and someone who oversees the whole.

When to choose which

Choose a monolith for a content site with ordinary needs, a team that wants to work in one system, and a budget that should go to content rather than technology. Drupal with a good theme is then quicker to build and cheaper to maintain.

Choose headless when speed weighs heavily, when the same content has to go to more places, or when the frontend has to do things a theme does not do well: lots of interaction, a design system of its own, parts you also use elsewhere.

Why this site is headless

brandbrand.nl is built to show how we work. The content lives in Drupal, in Dutch and English. Next.js builds the pages and keeps them ready. The interactive parts, such as the steps above, are frontend components that an editor places on a page in Drupal as a block. We know the price: two systems to maintain. For a site that has to be fast and has parts a theme does not do well, we think it is worth it.