Why a headless CMS beats building on WordPress or Wix

A page builder decides your performance ceiling before you write a word.

That is the argument in one line. Everything below is the reasoning, including the cases where I think a builder is the correct choice and a custom build would be a waste of your money.

The coupling problem

WordPress, Wix, Squarespace and Webflow all bundle three separate jobs into one product. They store your content. They decide how it looks. They serve it to visitors. When those three are welded together, a change to one drags the others along.

You see it the first time you try to redesign. The content is stored inside layout markup, so a new design means re-entering content or writing a migration script against a schema you do not control. You see it again when you try to reuse the same content somewhere else, in an app, in a newsletter, on a partner site. There is no clean way to get it out, because it was never stored as content. It was stored as a page.

Where builders cost you

The cost is mostly paid in bytes and in requests. A builder has to support every feature any customer might use, so it loads a runtime capable of all of them. Your page uses four of those features and downloads the framework for forty.

Three specific things happen on nearly every builder site I audit:

• A large JavaScript bundle loads on pages that need almost none of it. A text only about page still pays for the slider, the lightbox and the animation engine.
• CSS arrives as one enormous stylesheet covering every block type the builder offers, and the browser has to parse all of it before it can paint.
• Third party scripts get injected through the visual interface, because that is the only place to add them, which means they land in the head and block rendering.

The main thread number is the one that hurts most and gets discussed least. Every millisecond the browser spends parsing and running JavaScript is a millisecond it cannot spend responding to a tap. That shows up in your Interaction to Next Paint score, and builders are structurally bad at it because they ship interactive machinery for components you are not using.

The decoupled shape

Decoupled means the content lives in one system with an API, and something else turns it into pages. The something else can be Next.js, and the content system can be Sanity, Contentful, Payload, or WordPress with its front end switched off.

Because the renderer runs at build time, the visitor gets HTML that is already finished. There is no database query on the request path and no template engine assembling the page. You can only make a page faster than that by sending less of it.

// This function runs when you build, not when someone visits.// The visitor receives a finished HTML file from the nearest edge server.export default async function HomePage() {  const page = await cms.getPage('home');   return (    <main>      <h1>{page.heading}</h1>      {page.blocks.map((block) => (        <Block key={block.id} {...block} />      ))}    </main>  );}

The other half of the benefit is that you decide what ships. If a page needs no JavaScript, it gets none. A builder cannot make that promise because it does not know in advance what you will put on the page.

Why content sites feel it most

A five page brochure site can survive a slow stack. Nobody is comparing it against alternatives on a search results page. A content marketing site is in a completely different position, because its whole purpose is to win organic traffic against competitors doing the same thing.

Three reasons the pain compounds as you publish more:

Volume multiplies every mistake

A 200 KB overhead on one page is annoying. The same overhead across 400 articles is your entire crawl budget and your entire mobile experience. Whatever your template does badly, it does badly several hundred times.

Search visibility depends on the numbers you are worst at

Google measures real visits at the 75th percentile, so your score reflects your slower visitors rather than your fastest. Builder sites tend to have a long tail of slow sessions on mid range phones, which is exactly the group that decides your rating.

Content outlives designs

An article you publish this year should still earn traffic in four years, through two redesigns. If your content is welded to a layout, every redesign puts that archive at risk. Stored as structured content, it survives redesigns untouched.

Ownership and portability

This part is boring until the day it matters. On a hosted builder, your content sits in a database you cannot query, behind an export button somebody else designed. Your pricing is whatever they decide next year. Your performance ceiling is whatever their runtime allows.

With a decoupled setup you hold the repository, and content comes out over an API you can call yourself in whatever shape you want.

# Content you can actually take with you, as structured datacurl "https://cms.example.com/wp-json/wp/v2/posts?per_page=100&_fields=slug,title,content,date" \  > backup-$(date +%F).json

I am not claiming migrations become free. They become possible, and possible at a known cost, which is different from being locked in.

The honest tradeoffs

A decoupled build is worse than a builder in several real ways, and pretending otherwise would make this article useless.

There is also a real maintenance difference. A decoupled site has two systems, a build pipeline and a deploy target. Somebody has to own that. If nobody on your side can, the architecture is wrong for you no matter how fast it renders.

The switch point, in my experience, is when content becomes a channel rather than a brochure. Once you are publishing regularly and organic search matters to revenue, the coupled setup starts costing more than it saves.

Resources

• web.dev: Core Web Vitals

  The metrics and thresholds Google uses, including the 75th percentile rule.

• Chrome DevTools: Coverage panel

  Shows how much of the CSS and JavaScript a page loads but never uses.

• HTTP Archive: Web Almanac

  Yearly analysis of real page weight and CMS usage across millions of sites.

• Next.js: static exports and rendering

  How the App Router decides what renders at build time and what stays dynamic.