Native blocks vs page builders: the real cost over five years

We will maintain an Elementor or WPBakery site you already own. We will not start one. That is a firm position, and it is worth explaining rather than asserting, because for some projects a builder genuinely is the right call and I will name those cases below.

The argument is not about craft or purity. It is about where the layout is stored and what happens to it when the plugin is gone.

What each one actually is

A page builder (Elementor, Divi, WPBakery, Beaver Builder) stores layout as its own markup inside the post content or in its own tables, then renders it through the plugin at request time. The layout only exists while the plugin is installed.

Native blocks are WordPress core’s editor. Layout is stored as HTML with comment delimiters in post_content. Remove every plugin and the content is still HTML, and still renders.

The difference is visible if you look at what is actually in the database. A block looks like this:

<!-- wp:heading {"level":2} -->
<h2>Our approach</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>We start with the content model.</p>
<!-- /wp:paragraph -->

Strip the comments and you have valid HTML that any browser, any CMS and any migration script understands. A shortcode-based builder stores something closer to this:

[vc_row][vc_column width="1/2"][vc_custom_heading text="Our approach"
font_container="tag:h2|text_align:left" use_theme_fonts="yes"]
[vc_column_text]We start with the content model.[/vc_column_text]
[/vc_column][/vc_row]

Deactivate the plugin and a visitor sees that, literally, on the page. Newer builders store JSON in their own tables instead, which is tidier and no more portable.

That difference, where the layout lives and what survives without the plugin, is the whole argument. Everything below follows from it.

The five-year sum

For a mid-size business site of roughly 40 pages, one designer, occasional developer time. Indicative numbers; your host and licence tier will differ, and the point is the shape rather than the totals.

Page builder route

Native block route

The builder is cheaper for about eighteen months. The crossover arrives the year the performance work lands, and the gap widens permanently at the point you want to redesign.

Two assumptions worth arguing with, because they are the ones that move the answer:

The performance remediation line. If your site does not depend on organic traffic and nobody measures Core Web Vitals, that $3,000 never gets spent and the builder stays cheaper for longer. Plenty of businesses are in that position honestly.

The year-five rebuild. If you genuinely never redesign, the largest line on the builder side disappears. In practice most business sites get redesigned every three to five years, and the ones that do not are usually sites nobody is investing in anyway.

Change either assumption and the arithmetic changes. That is fine. What is not fine is making the decision without doing the sum at all, which is what usually happens.

The part that is not on the invoice

You cannot take the markup with you

This is the real lock-in. Content written in a builder is stored as that builder’s shortcodes or JSON. Deactivate it and the pages become unusable, not merely unstyled. Any future redesign is therefore a content migration, and content migration is priced per page.

We quote a redesign of a 40-page builder site at roughly double a 40-page block site, and the whole difference is rebuilding content that could not be carried across. On a 200-page site that difference stops being a line item and starts being the reason the redesign does not happen.

There are conversion plugins that claim to translate builder content into blocks. They work on simple pages and produce a mess on anything using nested rows, custom widgets or the builder’s own dynamic content features, which is every page that was worth building in a builder. Budget them as a way to save 30% of the work, not as a solution.

The performance cost is structural

Builders ship a CSS and JS framework on every page, because they cannot know which widgets a page uses until it renders. Typical numbers from our audits: 300 to 600KB of extra CSS and JS, and 40 to 80 extra DOM nodes per section from wrapper divs.

Both of those hit the metrics that matter. The payload delays Largest Contentful Paint directly. The DOM depth makes style recalculation slower, which shows up on mid-range phones far more than on the laptop the site was designed on.

You can claw some of it back. Asset optimisation, critical CSS, disciplined widget use and turning off the features you do not need will get a builder site into respectable territory, and that is a perfectly reasonable piece of work to buy. What you cannot do is reach where a block theme starts, because the framework is the product. You are optimising against the thing you paid for.

It is a permanent dependency with a security surface

The builder is usually the largest plugin on the site and it runs on every page, including on requests from people who are not logged in. When it has a vulnerability, and the major builders have all had serious ones, you patch immediately or you are exposed everywhere at once.

That is manageable with a maintenance retainer and unmanageable without one. The sites that get compromised are not the ones running a builder. They are the ones running a builder that nobody updated for fourteen months.

What the builder vendors get right

It would be dishonest to write all of the above without acknowledging why builders won as much of the market as they did.

They solved a real problem: WordPress core had no layout tooling for a decade, and the alternative to a builder was a developer for every content change. They made a whole category of site possible for people with no budget for engineering time. And they are genuinely pleasant to use, which is more than can be said for the block editor in its first three years.

Blocks have closed most of that gap, and the argument in this guide only works because they have. If you had asked me this question in 2019 the answer would have been different.

Where the builder is genuinely right

Not a rhetorical concession. Three real cases.

A small site with no developer, ever. Fifteen pages, a marketing person who needs to change things, no budget for developer time now or later. A builder is correct here and blocks are not, because blocks still assume somebody set up the patterns and the theme. Without that setup the block editor gives a non-technical user a blank canvas and no guardrails, which is worse.

A campaign site with a life measured in months. Lock-in does not matter if the site is being deleted after the campaign. Build it fast and cheaply, and do not spend anything on a content model that will never be used again.

A site that already has one and works. Migrating a functioning builder site to blocks for purity is not a business case. Keep it patched, keep it fast, and spend the money on something that earns. We will happily maintain a builder site rather than talk you into replacing one that works.

What “built properly with blocks” means

The failure mode on the block side is real and worth naming. A block theme built badly is worse than a builder, because editors get a blank canvas and no guardrails, and the result is forty pages that each look slightly different.

Doing it properly means four things.

A content model before any visual work. Post types, taxonomies and fields decided first. This is the difference between a site your editors use and one they fight, and it is the single most skipped step in WordPress projects at every budget level.

A pattern library, not just blocks. Editors should compose pages from pre-built sections (a hero, a two-column feature, a testimonial row) rather than raw columns and spacers. Patterns are the guardrail, and they are what makes the block editor feel like a builder in the way that matters.

theme.json doing the work. Colours, spacing scale and typography defined once, so an editor cannot produce a page in the wrong brand colours.

{
  "version": 3,
  "settings": {
    "color": {
      "custom": false,
      "palette": [
        { "slug": "brand", "color": "#1B4DFF", "name": "Brand" },
        { "slug": "ink",   "color": "#0B1220", "name": "Ink" }
      ]
    },
    "spacing": { "customSpacingSize": false, "spacingScale": { "steps": 7 } },
    "typography": { "customFontSize": false }
  }
}

The three false values are the important part. They remove the colour picker, the arbitrary spacing input and the free-text font size, which is how you stop a site drifting away from its own design over two years of edits.

Locked templates where it matters. Block locking stops somebody deleting the header on the pricing page, or dragging the pricing table out of a template while trying to edit the text above it.

Skip those four and you have rebuilt the builder’s problems without the builder’s convenience, which is the worst available outcome and one we have been called in to fix more than once.

What editors actually complain about

Worth separating, because the block editor’s reputation is largely from 2019 and the complaints we hear now are different.

The complaints that are still fair: nested block selection is fiddly, the list view is essential and not obvious, and pasting from Word still produces surprises.

The complaints that are really content model problems: “I can’t find where to change that”, “there are too many options”, “it looks different on every page”. None of those are fixed by switching to a builder. They are fixed by defining fields, building patterns and locking templates, and if you switch to a builder without doing that work you will have the same three complaints in a different interface within a year.

How to find out what yours is costing

If you already run a builder site and want a number rather than an argument, this is a half day of work and it settles the question with your own data.

Measure the payload the builder is responsible for. Open the network tab on a typical page, filter to CSS and JS, and sort by size. Identify the files served from the builder’s plugin directory and its add-ons. On the audits we have run, that figure lands between 300KB and 600KB, and it is present on every page including ones with no builder content on them at all.

Check the field data, not the lab score. The Core Web Vitals report in Search Console shows what real visitors on real devices experienced over the last 28 days. A lab test on a fast connection will tell you the site is fine when a third of your mobile users are waiting four seconds.

Count the DOM. In the console, document.querySelectorAll('*').length on a content page. Above 1,500 elements on an ordinary page is a signal, and builder sites routinely reach two to three thousand because every section carries four or five wrapper divs.

Price the exit. Take your page count, deactivate the builder on a staging clone, and look at ten representative pages. Estimate how long rebuilding each would take and multiply. That number is your lock-in, expressed in money, and it grows with every page you publish.

Do those four and you will have a version of the five-year table above filled in with your own figures, which is far more persuasive internally than anything a developer tells you.

The migration question

If you have a builder site and are wondering whether to move, the honest trigger is a redesign, not a principle. You will touch every page anyway, so that is when the content migration is nearly free.

Doing it as a standalone project means paying to rebuild content that currently works, for benefits that are mostly future. Hard case to make, and we usually advise against it.

The exceptions, where it stands on its own:

• Core Web Vitals failing on a site where organic traffic matters. Now it is a revenue problem with a number attached.
• A licence you can no longer renew, or a builder whose maintainer has gone quiet. This is a real risk with several smaller builders.
• A page count that is still small. Twenty pages is a manageable migration. Two hundred is a project. If you are going to move, moving while the site is small is much cheaper than moving later.

One test before you decide

Open the site, deactivate the builder on a staging clone, and look at a page.

If what you see is recoverable, with headings, paragraphs and images in order, you have less lock-in than you feared, and a future migration is mostly styling. If what you see is a wall of shortcodes, you now know exactly what a future redesign will cost, and you can plan for it rather than discover it in a quote three years from now.

Either way you will know something concrete about your own site, which is more than any general argument about builders can give you.

Common questions

Is Elementor bad?

No. It is a well-built product that solves a real problem, and the team behind it ships continuously. The objection here is architectural rather than about quality: any builder that stores layout in its own format creates lock-in, and that cost lands years after the decision, on somebody who did not make it.

What about Bricks, Oxygen or Breakdance?

The newer builders are considerably better engineered and ship far less bloat, so the performance half of the argument weakens. The portability half does not. They still store layout in their own format, and you still cannot leave without rebuilding pages.

Is Full Site Editing ready?

For most business sites, yes, and it has been for a while. Where it is still awkward is complex conditional layouts and anything needing genuinely dynamic templates, which is where a classic theme with block content or a hybrid approach remains reasonable.

Do we still need ACF if we use blocks?

Often, yes, and there is no contradiction. Blocks are for layout that editors compose. ACF is for structured data that has a defined shape: a product’s specifications, an event’s date and venue, a case study’s metrics. Using blocks for structured data is the same mistake as using postmeta for transactions.

How much more does a block build cost?

On our card, a fixed-scope WordPress build starts at $8,500, and the difference between a builder site and a properly built block site is mostly the content model and pattern library work at the start. Roughly a third more up front, and it is the third that makes the site cheap to own afterwards.