The choice between a traditional CMS and a modern JavaScript framework is usually argued as a technology preference. It is more useful to argue about where content lives, who is allowed to change it, and how often the shape of a page moves. Both approaches can produce a fast, accessible, well-structured site. They differ in the cost of change, not in the quality of the result.
This article is a decision framework rather than a recommendation. If you want the reasoning behind the boundaries these decisions assume, designing scalable web applications covers it.
What 'traditional CMS' actually means
WordPress and Drupal are the reference points here, and the model is worth describing precisely because it is often described badly. Content lives in a database as pages, posts and metadata. A template assembles those into HTML on the server. Editors change content through an admin interface. Functionality arrives as plugins or contributed modules, each running inside the same server process as the site itself.
The strengths of that model are real. Publishing is decoupled from deployment, so an editor can publish without a developer. The editor is a mature, well-understood tool that non-specialists can be trained on in an afternoon. And for a site whose unit of change is the page, the model maps almost exactly onto the work.
The cost shows up when the site stops being a collection of pages. Every plugin runs with the privileges of the main process, so the extension surface is also the security surface. Templates assume a page-shaped hierarchy, and a page-shaped hierarchy is a poor fit for a section that appears on four different views. And because anything is possible in a template, consistency depends on discipline that no tool enforces.
What Next.js contributes, and what it does not
Next.js is a rendering and application layer, not a content management system. It gives you routing, server-side rendering with component composition, image and font handling, and a deployment model built around a build step and a CDN. It deliberately leaves content authoring to something else.
That division is the source of most of the confusion in this comparison. Teams adopt a framework expecting a CMS and end up storing page copy in the repository, at which point every content change needs a developer and a release. The framework was never the problem; the missing content layer was.
Rendering strategy is the decision people skip
Rendering strategy is a separate decision from CMS versus framework, and it is the one that most directly affects performance. There are three options, and most real sites end up using all three.
- Static generation: HTML is produced at build time and served from a CDN. The fastest option available, and it requires content to be known at build time. A marketing page that changes weekly fits this well.
- Server rendering: HTML is produced per request. Required where the response depends on the request, such as a signed-in dashboard or a cart. It costs you a server round trip on every view.
- Client rendering: the browser fetches data and builds the view. Appropriate behind an interaction, and a poor choice for anything a user needs to see on arrival, because it adds a round trip and a dependency on JavaScript executing.
Incremental regeneration sits between the first two: pages are generated at build time and rebuilt in the background on a schedule or on demand after an edit, so a mostly-static page can still be edited without a full release. The practical effect is that rendering strategy becomes a per-route decision rather than a per-project one, which is the strongest technical argument for a framework build.
A traditional CMS gives you server rendering by default, with page caching in front of it. That is a coarser but safer default than a framework, where rendering strategy has to be chosen deliberately and can be chosen badly. Neither is inherently better; they differ in how much you have to decide. Measurement discipline is covered in modern website performance.
The questions that actually decide it
How often does the homepage change shape?
If sections appear, disappear and reorder often, and each is largely independent, an ordered array of typed sections in a content model fits better than a page builder. Reordering becomes a field update rather than a redesign. This is the strongest signal in favour of a structured content model, whichever system hosts it.
Is the same content needed in several shapes?
If a service, product or article appears in a hero, a listing, a filterable index, a related-content rail and a sitemap, then one structured record with a defined schema is doing real work. A page-builder model tends to duplicate that content, and the copies drift out of agreement.
Does the site need application behaviour?
Client-side filtering, optimistic updates, authenticated dashboards, live data, rich inline interaction: these are application requirements. Arguing with a page builder to deliver them is where architecture debt usually starts.
Who maintains it after launch?
This is the question most often skipped, and it predicts long-term cost better than any other. If the day-to-day editor needs to publish without a deployment, both models can accommodate that, but only if the content layer is genuinely decoupled from the code layer. Verify it rather than assuming it, because projects adopt a framework and then quietly reintroduce the deployment dependency by putting page content in code.
Headless is the option most teams actually land on
The third option is to keep a familiar editor while replacing the front end. A headless CMS stores structured content and exposes it over an API; the front end is a separate application that consumes that API and renders it. The editor experience stays close to what editors already know, and the rendering layer becomes entirely yours to choose.
The trade is that you now maintain two systems with a contract between them. Content modelling has to be explicit, because the schema is the only thing holding the front end together. Preview, webhooks and cache revalidation have to be designed rather than assumed. And the front-end team carries a build and deploy pipeline it would not otherwise have needed.
For a site that behaves like a product, that cost is usually worth paying. For a brochure site with three pages, it is obvious overhead.
Where each approach tends to go wrong
The CMS that grew into an application
A site built on a page builder accumulates custom functionality over time: a plugin for one form, custom fields for one campaign, a bespoke template for one landing page. None of these decisions is unreasonable in isolation. Together they produce a system where a change to one page can affect another, updates are risky, and nobody can say which extensions are load-bearing.
The early warning sign is that publishing a page requires a developer. Once that is true, content and code are coupled, and the original advantage of the CMS has been lost without gaining the structured control a framework would have provided.
The framework that rebuilt the page builder
The opposite failure is a framework build that reinvents a CMS badly. A flexible component-plus-CMS arrangement can be excellent for genuinely varied pages and poor for a site with a stable set of section types.
The symptom is a content model with a general-purpose block editor where every page is a free-form arrangement. Designers produce bespoke layouts nobody can maintain, structural consistency is lost, and the site becomes hard to review. If the section types are known in advance, model them explicitly and save flexibility for the cases that genuinely need it.
Total cost, not build cost
Both approaches are usually compared on the build. The larger number is what happens afterwards, and it is dominated by the kind of change you will need to make.
- Adding or reordering a homepage section: cheap in a section model, a redesign in a tightly coupled template.
- Publishing a campaign page: cheap in a CMS, slower in a framework build if content lives in code.
- Adding a page type: moderate in both, but a schema keeps it consistent while templates invite divergence.
- Restructuring navigation: usually the moment the architecture shows itself.
- Handing the site to a new maintainer: where documentation and content-model clarity dominate the cost.
Write down which of these you expect to need most often. That list, rather than a general preference for a tool, is the decision.
Security and maintenance differ in kind, not degree
Both options carry real security work, but the work is different. In a traditional CMS the extension surface is the concern: plugins and themes run inside the site process, each one a dependency that needs updating, and patching is a recurring operational duty whether or not anything is wrong. The admin surface is also a login-protected attack surface, which argues for restricting who holds credentials and for keeping the admin area off public indexing.
A headless or framework build removes that particular class of risk and introduces different ones. Content API keys, preview tokens and webhook secrets all become credentials that must be scoped and rotated. The security boundary moves to your own API routes, so authorisation, rate limiting and input validation are code you own and must keep current. The dependency surface also changes shape rather than shrinking: you trade PHP plugins for a JavaScript dependency tree.
Neither model is the secure one. They are different maintenance routines, and the honest question is which routine your team can actually sustain.
Running the decision
Write the answers down before choosing, then read the two columns against your own constraints rather than in the abstract.
- Mostly pages, published by non-technical editors, no interactive requirement: a traditional CMS is a reasonable answer, and often the cheapest one.
- One structured record feeding many views, plus real interaction on first load: a framework with a headless content layer is the better fit.
- A homepage that reorders weekly, a marketing team that publishes daily, and a small engineering team: headless, with a narrow, well-modelled content schema.
- An existing structured content API already in the organisation: that fact usually settles the question on its own.
- A site that must be handed to a non-technical maintainer: weight the editorial interface above everything else in the scoring.
Two things have to have an answer before the decision is real: who owns the front-end component library after launch, and what happens to a section type when the business needs a new one.
Choosing by change rather than by fashion
A traditional CMS and a framework-based build are not competing on quality. They trade flexibility in different directions: pages versus data, general-purpose authoring versus typed composition, safer defaults versus finer control. Both produce good work. The question is which set of changes your organisation will actually make over the next two years, and whether the content layer is genuinely decoupled from deployment when you commit to it.
We build in both modes. Our platform work covers the framework side, and SaaS and product engineering covers the structured content models we reach for when a site behaves like a product. If the decision is genuinely close, that is usually a sign the content model has not been written down yet.
