There is a familiar conversation in the WordPress world that goes something like this. Someone shows their site is slow, or hard to maintain, or full of layout quirks. A more experienced developer looks at it, sees a page builder in the stack, and says “well, there’s your problem.” The case rests on the page builder. The site owner walks away convinced the next rebuild needs to be “page-builder-free.”
This is the wrong diagnosis, and it has been the wrong diagnosis for some years now. Page builders are not the problem. The way most people use them is. The distinction matters because acting on the wrong diagnosis leads to expensive rebuilds that fix the wrong thing — and to sites that, six months later, suffer from the same underlying problems in a different costume.
The case against page builders is mostly out of date
The “page builders are bloated” argument has its roots in software that no longer really exists. Five or six years ago, the leading page builders shipped enormous CSS files, loaded a tangle of legacy scripts on every page, used inline styles aggressively, and produced HTML that no human would have written by hand. The performance penalty was visible without measurement.
That was then. The current generation of page builders is genuinely better. The output is leaner. Stylesheets are loaded conditionally. Scripts are tree-shaken. Most builders produce a final page that, on a sensibly configured site, is within a few hundred milliseconds of a hand-coded equivalent.
This does not mean every builder is fast, or that every page built in a builder is fast. It means the structural argument — that a page builder fundamentally cannot produce a performant page — no longer holds. The problem has migrated from the tool to the operator.
What “undisciplined use” actually looks like
Most slow page-builder sites are slow for reasons that have nothing to do with the builder itself. They are slow because, in the course of using the builder, somebody made decisions that would have made the site slow regardless of how it was built.
The pattern is familiar to anyone who has audited these sites. A homepage with eight different fonts, each loaded as a full family with all weights. A hero section with a 4MB background image, uncompressed, served at full resolution to mobile devices. A dozen plugins added to enable individual features that the theme could have handled with a small amount of custom code. Animations on every section, each running its own script. A carousel that loads twenty images on first paint, of which only three are visible.
None of those decisions are forced by the builder. They are made by the person using it, often under pressure to ship something that looks like the design brief, with limited time and limited awareness of the performance consequences. The builder enables the work — but it also enables the over-work, and that is a different thing.
The convenience trap
The deeper issue with page builders is that they make adding things very easy. Drag, drop, configure, save. A new section is on the page in a minute. That convenience is the headline feature; it is also the source of most of the trouble.
When adding things is easy, things get added. The temptation to “just add a section here” becomes harder to resist. Six months in, the homepage has grown by half its original height, the load time has crept up by a couple of seconds, and nobody can point to the specific change that caused it because every individual change was small.
This is not unique to page builders. It is the same problem that produces bloated codebases in any other context. But page builders accelerate it, because the cost of adding something is so low that the friction normally provided by writing code is gone.
Discipline, in this context, means treating the build experience as if there were friction even when there is not. Reviewing additions critically. Removing things as well as adding them. Keeping a sense of the total weight of the page rather than the merit of the latest element on it.
Where the real performance work happens
If a site built in a page builder is slow, the first place to look is almost never the builder. The usual suspects are the same as on any WordPress site.
Images. Oversized, uncompressed, not lazy-loaded, in the wrong format. Image weight typically accounts for more than half the total page weight on a content-heavy WordPress site, regardless of how the page was built.
Fonts. Multiple families, each with multiple weights, each loaded synchronously. A single restraint here — one display family and one body family, two weights each — can shave hundreds of kilobytes off a page.
Plugins. Each plugin tends to add at least one CSS file and one script, often on every page whether they are needed or not. Plugin sprawl is a death by a thousand cuts.
Hosting. Cheap shared hosting genuinely is slow, in ways no amount of front-end optimisation can fix. If the time-to-first-byte is high, the host is the bottleneck.
Caching. A page that gets generated from scratch on every request will always be slower than the same page served from cache.
Notice what is not on that list. The builder is not on the list. In any honest audit of a slow page-builder site, the builder might be contributing a small amount to the total weight — but it is almost never the principal cause.
The case for keeping the page builder
There is a real cost to abandoning a page builder that has been working well. The clients, content editors, or non-technical staff who edit the site every day have learned how to use it. They can update pages without engineering involvement. They can launch a new landing page in an hour. They can fix a typo without raising a ticket. Stripping the builder out means stripping that capability out, too.
That capability is often more valuable to the business than the small performance gain the rebuild would produce. A site that loads 200 milliseconds faster but now requires a developer for every change is, in most cases, a worse outcome than the one it replaced.
This is where the “builders are bloat” position gets its main argument backwards. It assumes the cost of using the builder is high and the cost of not using it is low. For most working teams, the reverse is true. The builder costs a small amount of weight; the absence of the builder costs ongoing developer hours.
What disciplined use looks like
The route to a fast, maintainable, page-builder-based site is not to remove the builder. It is to use it like a craftsperson would.
That means restraining the global styles — a single typeface family, a tight colour palette, a constrained set of section patterns. It means establishing a library of reusable blocks rather than building each page from scratch. It means optimising images at upload, not as an afterthought. It means auditing the plugin list every few months and removing the ones that have stopped justifying their weight. It means setting a performance budget — a target page weight, a target load time — and refusing to ship pages that bust it without good reason.
This is not the kind of work that gets demonstrated in marketing copy. It is the kind of work that separates a site that performs well after a year from a site that does not, regardless of which tool produced the underlying HTML.
The argument under the argument
Underneath the page builder debate is a broader pattern in how the WordPress community talks about tools. Each generation of WordPress workers tends to disapprove of the way the next generation does the work. Hand-coders distrust theme frameworks. Theme framework users distrust page builders. Most of this disapproval is about taste, dressed up as a technical objection. The technical objection — bloat, speed, maintainability — is rarely the actual driver of the complaint.
That is a fair preference to hold, and there are real arguments to be made about the craft of hand-coded sites. But “page builders are bloated” is not one of them, in 2025. The tool is fine. What matters is whether the person using it knows what they are doing.
The short version
Page builders take a lot of criticism for problems they did not cause. Most slow, hard-to-maintain page-builder sites are slow and hard to maintain because of decisions made by the person building them, not because of the builder itself. The fix is not a rebuild. The fix is discipline — restraint with fonts and images, a controlled plugin list, a budget for weight, and a habit of removing things as readily as adding them. The tool is rarely the problem. The discipline is what’s usually missing.
