Page builder: title card beside a flat illustration of stacked page panels with one marked in scarlet

Comparisons of WordPress page builders tend to list the same three or four products, describe their features in the vendors’ own words, and stop. For a business owner the interesting question arrives later: a page builder is chosen once, usually by whoever builds the site, and then lived with for years. What does it cost over those years?

Two things, and only one of them is visible on launch day. The first is weight on every page. The second is that leaving one is not a migration — it is a rebuild.

What does a page builder load on pages that do not use it?

Its stylesheet and its JavaScript, generally everywhere. A builder cannot know in advance which page will use its accordion or its slider, so the usual approach is to enqueue the lot site-wide. Your contact page, which is a heading and a form, carries the machinery for a parallax hero it does not have.

Chrome’s own Lighthouse documentation is unusually direct about where this comes from. On unused JavaScript it says plainly that “Unused JavaScript can slow down your page load speed”, flags every file carrying more than 20 kibibytes of unused code, and notes that sending unused code over the network is wasteful for people without unlimited data. Its recommended fix names the culprit outright: consider reducing, or switching, the number of WordPress plugins loading unused JavaScript on your page.

The stylesheet side is the same story. Lighthouse notes that “Unused CSS also slows down a browser’s construction of the render tree”, that each external stylesheet has to be fetched over the network, and — again — recommends reducing or switching the WordPress plugins loading unused CSS. When Google’s own performance tooling names your plugin stack twice, that is worth more than any vendor comparison.

Google’s performance documentation names WordPress plugins as the fix. Twice.

What that costs a Malaysian visitor on a mid-range phone is the subject of whether three seconds is really the limit, and whether the result is usable under a thumb is in is your website easy to use on a phone.

A labelled diagram headed WHAT SHIPS ON EVERY PAGE showing a stack of four layers — your content at the bottom in black, then theme CSS, then builder CSS, then builder JavaScript — with the top two layers tinted scarlet and a bracket labelling them Loaded whether the page uses them or not
A wide labelled comparison headed LEAVING IS NOT A MIGRATION with two rows: the upper row marked Moving host shows three boxes reading Copy files, Copy database and Done, and the lower row marked Leaving a builder shows four boxes reading Content comes out as markup, Layout does not survive, Rebuild every page and Re-check every link, all four outlined in scarlet

What happens when you want to leave?

This is the part nobody mentions at the start, and it is the larger cost. Moving a WordPress site between hosts is ordinary work: copy the files, copy the database, repoint the domain, as set out in migrating a website without breaking it. Moving off a page builder is a different category of job.

In the sites we migrate, builder content does not come out as clean content. It comes out as the builder’s own markup, and once the plugin is gone the layout does not survive it. In practice that means rebuilding every page by hand, which is why a “simple theme change” quoted at a few days turns into a project. We are describing what we see rather than citing a study, because no official documentation says this — but it is consistent enough that we now ask which builder a site uses before quoting any redesign.

It is worth being even-handed here. WordPress itself now ships a block editor, and its documentation describes it in familiar terms: “Blocks are the content elements that you add to create content layouts”, with blocks for all common content elements and more available through plugins. For a brochure site, core blocks plus a well-built theme now cover a great deal of what a builder was bought for in 2019. That is not an argument to rip anything out today; it is an argument to ask the question before the next build.

A labelled square checklist headed ASK BEFORE YOU COMMIT with five questions each preceded by an empty checkbox, above a scarlet caption reading You are choosing this for the next five years, not for launch week

So is a page builder the wrong choice?

No — it is a trade, and the trade is reasonable when you know you are making it. The honest summary:

It buys youIt costs you
A faster, cheaper first buildWeight on every page, including pages that use none of it
Edits without a developerA skill tied to one product rather than to WordPress
Layouts your theme cannot doContent that does not leave cleanly
A licence you keep renewingA dependency on the vendor staying in business

The left column is real value, especially for a small business that needs to change a page on a Friday afternoon without raising a ticket. The mistake is not choosing a builder; it is choosing one without being told there is a right column at all.

Questions worth asking before the build starts

  • Who else will edit this site, and will they still be able to in two years if the person who built it moves on?
  • What loads on a page that uses none of the builder’s features? A developer can answer this in a minute with Lighthouse.
  • What happens when the licence lapses? Some builders stop receiving updates; the site keeps working but stops being patched, which is its own problem — see what happens when a WordPress site breaks.
  • Can my content come out without a rebuild? Ask for a straight answer before, not after.

What should you do with the site you already have?

Usually nothing dramatic. A builder-based site that is fast enough, patched and editable is fine, and replacing it for purity would be a poor use of money. The things worth doing are smaller: switch off the builder’s modules you never use, check whether its assets can be loaded only on the pages that need them, and keep it updated. That is routine maintenance, covered in what a care plan actually covers.

The decision changes when the site is due for a revamp anyway. At that point the builder is a live question rather than a sunk one, and the answer feeds into what carries over — the subject of what to keep in a website revamp — and how to do it without going dark, in revamping without downtime. If the builder is the reason every change is slow and expensive, that pattern is the one described in a website becoming expensive to maintain.

A WordPress conference talk on recovering speed without rebuilding the site.

Frequently asked questions

Will removing a page builder make my site faster?

Usually yes, and sometimes substantially, because the builder’s stylesheet and script stop loading on every page. But the gain is not free: rebuilding the pages is the real cost, so it rarely makes sense on its own. It makes sense as part of a revamp that was happening anyway. Measure first with Lighthouse so the decision is based on your site rather than a general claim.

Is the WordPress block editor a replacement?

For many brochure sites now, largely yes. Its documentation describes blocks for all common content elements, with more available through plugins, and a decent theme fills most of the rest. For a site with complex custom layouts the answer is less clear, and the honest test is to rebuild one representative page in blocks before committing to anything.

Our agency chose the builder without asking us. Is that normal?

It is common, and it is not sinister — agencies standardise on one tool so their team is fast and consistent. The problem is only that the trade-off is rarely explained, and it is your business that lives with it. Asking the four questions above before the next build costs nothing and changes what you are agreeing to.

Where iRevamps fits

When we quote a revamp, which page builder a site uses is one of the first things we check, because it determines whether we are editing a site or rebuilding one. Our web development and design service will tell you which of the two you are looking at before any work starts, including when the answer is that the existing build is fine and should be left alone. If the question is bigger than the builder, our guide to choosing between a revamp and a full rebuild sets out how to decide.