Gutenberg, Page Builders, or Custom Blocks: What Are You Signing Up For?

The choice looks like a preference and behaves like a contract. Whichever of the three you pick, somebody will be able to publish a landing page by Friday. The difference only appears on the day you want to redesign, re-template or leave, and by then the decision is thousands of rows deep in a database nobody wants to open.

Most evaluations of WordPress page builders compare the editing experience, because that is the part a demo can show. We think that is backwards. The editing experience is a layer you can replace in a quarter. What the tool writes into the database is permanent until somebody pays to undo it, one page at a time.

So this piece compares the three on four axes, in this order: portability, performance, editor freedom and lock-in. Then it gives a rule based on team shape, because the honest answer is not that one option wins. It is that each suits a particular arrangement of people, and picking against your own arrangement is how a website build becomes an annuity for somebody else.

Three tools, three different bets

They are usually presented as three levels of sophistication. They are not. They are three different answers to the question of who controls layout, and each answer carries a cost that is paid by a different person.

What Gutenberg stores

The core block editor writes ordinary HTML into the post content, wrapped in HTML comments that describe each block and its attributes. Take WordPress away entirely and what remains is readable markup with some comments in it. That was a deliberate design decision, and it is the most underrated property of the block editor: your content is still content after the editor is gone.

What a page builder stores

A builder generally stores either shortcodes or a private structure held in post meta, then renders the visible page from that structure at request time. The layout, the spacing, the responsive rules and often the copy itself live inside a format only that plugin can read. The page you see is an output. The stored value is an instruction set for a program you are renting.

What custom blocks are

A custom block is a block you or your developer defined: a named set of fields, a fixed rendering, and no options beyond the ones you chose to expose. It uses the same storage format as core Gutenberg, so the portability property carries over, and it pairs naturally with properly structured post types instead of fighting them. The bet you are making is that a smaller set of choices produces better pages than an unlimited set, which is true more often than designers like to admit and less often than developers claim.

Portability is the axis nobody compares on

Portability is not an abstract virtue. It is the answer to one specific question: if this plugin were deactivated tomorrow, what would the page look like? Run that experiment on a staging copy before committing to anything, because the answer is rarely what a sales page implies.

With core blocks the page degrades to plain, unstyled, entirely present content. Headings are still headings, paragraphs are still paragraphs, images keep their alternative text. With most builders the page degrades to a screenful of bracketed shortcodes, or to nothing at all, because the content was never in the post body to begin with. Same word count, radically different asset.

Portability also pays out long before anybody leaves. A site whose content is plain markup can be re-themed by changing stylesheets and templates. A site whose content is builder instructions has to be rebuilt by opening every page and doing it again. The redesign you will run in three years is the same operation as the migration you may never run, which is why this matters just as much to teams who intend to stay exactly where they are.

A design is worth what it cost to make. Content is worth what it would cost to make again, which is why the storage format outlives the layout.

Builder markup is the hardest thing to migrate

This is the claim to argue with if you disagree with anything here. The difficult part of leaving a WordPress site is almost never the database, the media library or the redirects. It is that several thousand pages of copy are encoded in a private format, and no export hands the words back as words. A migration off WordPress that should have taken three weeks takes three months, and the difference is entirely the markup.

What deactivation leaves behind

Turn the plugin off on a copy and inventory what survives. The list is usually shorter than anyone expected.

• Shortcodes without a handler. They render as literal square-bracket text in the middle of the page. Every one has to be found and replaced by hand, or by a script somebody writes for your particular builder.
• Layout expressed as nesting. Rows inside sections inside containers. The visual hierarchy was carrying the meaning, and the meaning does not survive the export.
• Styling held in post meta. Per-page colours, spacing and breakpoints that were never in a stylesheet, so they cannot be re-applied by changing a theme.
• Widgets that were really features. Sliders, pricing tables, accordions, tabbed panels. Each was a module inside the builder and is now a gap, with the copy that lived in it scattered or gone.
• Forms, and everything attached to them. The builder’s form module usually owns the fields, the routing and the notification rules. That is a lot of business logic living inside a page layout tool.

That last item deserves separating out, because a form is not decoration. It is the instrument that sorts enquiries into the ones you can act on and the ones you cannot, an argument our parent company sets out in a form is a triage instrument. When the triage instrument is a module inside a layout plugin, changing your layout plugin means rebuilding how the business receives work. Those two things should never have been coupled in the first place.

What each one costs at render time

The performance differences here are structural rather than incidental, so they do not disappear with better hosting. A builder ships its framework, its icon set, its animation helpers and its grid to every page that uses it, including the page that is one heading and two paragraphs. That cost is fixed, and the visitor pays it.

Core blocks load styles per block, so a simple page stays simple. Custom blocks can be tighter still, because you control exactly what each one emits and nothing arrives speculatively. None of this makes a badly built custom-block site fast; a developer can absolutely produce something slower than a builder. The ceiling is just far higher. And the largest element on a landing page is usually an image or a hero, which no editor choice fixes on your behalf.

There is a second cost that only shows up later. A builder is a large dependency you now update on somebody else’s schedule, and a major version of it can change how existing pages render. The pages most likely to break are the oldest ones, built by whoever left. That is the ordinary shape of a dependency you shipped but did not write, and custom blocks move the risk rather than removing it, because the code becomes yours to keep current when WordPress changes underneath it.

The honest concession: for a brochure site of a dozen pages with no ambitions beyond that, the render cost of a builder is a real but modest problem, while the time it saves is immediate and large. Do not let a performance argument talk a two-person company out of shipping.

Editor freedom, and the freedom worth refusing

Builders sell total control: any element, any spacing, any breakpoint, no developer required. That is genuinely liberating for one person who is designer, marketer and publisher at once. It is corrosive for a team of five, because every page becomes a fresh set of decisions and nobody is ever required to make the same decision twice.

A year of that produces a site with nine heading sizes, four button styles and a spacing system that exists only in the sense that spacing exists. The fix is never another redesign. It is removing options until the wrong page is hard to build. Custom blocks do this by construction: three layout choices rather than thirty, and the ones you never exposed cannot be used at two in the morning before a campaign goes out.

Gutenberg sits between the two and lands wherever your theme configuration puts it. A block theme with a tight palette, a fixed type scale and a small library of patterns behaves almost like custom blocks. The same editor with its defaults untouched behaves like a builder with fewer features. This is why two teams report opposite experiences of one editor, and why configured matters more than which editor got installed.

The comparison that shows up in year three

Feature grids compare what each tool can do. These are the differences that decide what your next project costs.

The rule: choose by team shape

Not by page count, not by budget, and certainly not by which option a comparison article rated highest. The right tool is the one that matches whoever is actually going to touch the site next year.

1. One person doing everything, no developer at all. Use a builder, and use it without guilt. Portability is a cost you pay later; having no website is a cost you pay now. Keep the forms outside it.
2. A small marketing team with occasional developer time. Core Gutenberg on a properly configured block theme. Lock the palette and the type scale, ship six patterns, and let the constraint do the work a style guide never does.
3. A marketing team with a developer around every week. Custom blocks for the page types that repeat, core blocks for prose. This arrangement ages best, and it is the one we would default to.
4. Many contributors and a real design system. Custom blocks, and fewer of them than feels comfortable. Every option you expose will eventually be used by somebody in a hurry.
5. Planning to leave WordPress within two years. Do not adopt a builder now. Whatever it saves this quarter, it charges back with interest during the move.

Two clarifications on that list. Team shape means who has time, not who has a job title: a developer who is fully allocated to the product is not a developer the marketing site has. And shapes change, so the choice deserves revisiting when yours does. The most common version of this mistake is a company that hired its first developer two years ago and is still publishing through the builder it picked when it had none, because nobody scheduled the conversation.

Where we would start

Start by writing down the page types you actually publish. Most sites have five or six that repeat and a handful of one-offs. If that list is short and stable, custom blocks pay for themselves quickly, because a block is only worth building when it is going to be used forty times. If the list is long, unstable or unknown, you are not ready to build blocks and pretending otherwise produces a library nobody uses.

The deeper version of the question is whether WordPress should hold this content at all, which is the subject of the twelve questions that separate a CMS shortlist. Content stored as typed fields can be rendered into any design later. A structured workspace such as Acrosite takes that further by generating the files and committing them to a repository, which is the same portability argument arriving from the other direction.

If you are already carrying a builder on a large site, the answer is not a weekend rewrite. Freeze new pages onto blocks, convert the templates with the most traffic, and let the long tail age out. Slower, and the only version that survives a budget review. More of this thinking sits in our WordPress writing, and if you would rather have someone look at the actual site, tell us what is installed.