Picture the meeting. Somebody from the agency shares their screen, opens a page, and drags a block of text from the bottom of the layout to the top. Then they drop in an image. Then they change a headline color, live, while everyone watches.
And the room relaxes.
You can feel it happen. The marketing lead stops taking notes. The person who has been burned before by a site nobody could update leans back in their chair. Somebody says out loud what everybody is thinking: so we won’t have to call you every time we want to change a word.
That demo has sold more websites than any portfolio ever has. It is a genuinely good demo. It answers a real fear with a visible, physical proof. Look, it’s easy. You can do this yourself.
The trouble is that the demo is answering a question you asked, with a solution to a different problem entirely.
Two different promises wearing the same coat
“Your team can edit the site without a developer” is one promise.
“Your site is built with a page builder” is a different promise.
For about a decade the industry has treated those as the same sentence, and they are not. The first is a statement about what your team can do. The second is a statement about how the site is constructed and what gets delivered to every single person who visits it. One is about your workflow. The other is about your architecture.
The conflation is understandable. Builders were the first tools to make the first promise credible at scale, so the promise and the product fused together in everyone’s head. If you want easy editing, you get a builder. Those are the options.
Except they aren’t, and the gap between them is where the actual decision lives. Because what you were sold was your team can change things without calling a developer. What you bought was a tool that lets your team change anything — including a lot of things they should not be changing, and a lot of weight they never asked for.
The receipts come from the builders themselves
Here is the part that should settle the performance argument, and it is not coming from a developer with a grudge. It is coming from the companies that sell the builders.
Start with the measuring stick. Google’s Lighthouse has a “Reduce unused CSS” audit that compares a stylesheet against the rules actually used on a given page and reports the wasted bytes. Google’s reasoning is not mysterious: CSS has to be downloaded, parsed, and processed before anything renders. Unused CSS is not free. It is a real cost paid by a real person waiting on a real phone.
Now the vendors, in their own words:
- Elementor has been unusually candid about this. Before its conditional CSS work, Elementor Core shipped a global CSS file of roughly 120 KB, and Elementor Pro around 225 KB — including styles for widgets that weren’t on the page. Conditional loading claimed savings of up to 37 KB on Core and 171 KB on Pro depending on the page.
- By Elementor 3.24, they reported cutting the Pro base stylesheet from 471 KB down to an 11 KB frontend-lite file, with widget CSS loaded conditionally.
- Elementor 3.25 went after another one:
global.csscould reach 64.6 KB with Pro installed, carrying global styles for widgets that might not exist on that page at all. They rearchitected specifically to eliminate it. - Divi published similar math. Its older architecture carried roughly 860 KB of CSS. Its dynamic CSS system got that down to 54 KB on their example site by generating CSS based on the components actually present. That’s about a 94% reduction in delivered CSS on that site — though that shouldn’t be read as “94% of Divi’s CSS is unused everywhere.”
- WPBakery published research on exactly this in September 2026, stating that with a traditional monolithic CSS approach, up to 90% of CSS can go unused on typical pages. Which is why WPBakery 9.0 introduced split CSS loading. They tested with Chrome DevTools and Lighthouse’s Reduce Unused CSS audit, and say more percentage-based results are coming with the release.
Then there’s field data, which is different from lab data because it’s measured on actual visitors’ actual devices. A 2026 PageSpeed Matters analysis pulled CrUX data from roughly 2.1 million WordPress origins. It wasn’t an unused-CSS study, but the spread is worth sitting with. Mobile Core Web Vitals pass rates: Gutenberg 41.5%, Beaver Builder 42.7%, Divi 34.5%, WPBakery 32.7%, Elementor 30.0%.
Read those numbers charitably. Every one of those vendors is actively engineering against the problem, and the newer versions are meaningfully better than the old ones. That is to their credit. But you cannot spend years publishing engineering posts about how much weight you’re removing without also confirming how much weight was there.
Why it has to be heavy
None of this is incompetence. It’s physics, more or less.
A page builder is a general-purpose tool. It has to be ready for the carousel you might add, the pricing table you might add, the animated counter, the tabbed module, the parallax header, the sixty other things sitting in the sidebar. It cannot know in advance which handful of those you’ll actually use on this page, so historically it shipped for all of them and hoped for the best. Conditional loading is the industry’s long, ongoing correction to that original sin.
There’s also a runtime. A visual editor needs a general frontend framework capable of interpreting any page the editor could produce. That interpreter goes to the browser too.
We took the other road. We don’t use a builder that requires a generalized frontend framework to interpret every page. We build with purpose-built components. If a component is text and an image, it doesn’t need JavaScript, so we don’t send JavaScript for it. Not less. None. When something genuinely requires interaction — a carousel, a modal, an accordion — we load only the behavior that component needs.
Same principle on the CSS side. Rather than shipping a large library of styles to account for everything a builder could do, we use Tailwind to compile only the styles the project actually uses. A typical optimized Tailwind project ships under 10 KB of CSS. Our custom component system plus Tailwind lands plausibly somewhere in the 10 to 30 KB range, depending on how much custom work a project calls for.
Compare that to 120 KB. Or 225 KB. Or 860 KB.
The browser downloads less, parses less, executes less, and isn’t carrying the overhead of a visual page-builder runtime it will never use. The client still gets flexible, reusable components in WordPress. The flexibility lives in the CMS rather than being shipped to every visitor’s browser.
That sentence is the whole architecture, honestly. Flexibility in the CMS, not in the browser.
The part nobody measures: it stops looking like you
Kilobytes don’t move anyone to sign a contract. Nobody has ever approved a budget because of a stylesheet.
So let’s talk about the thing that actually costs you something, which is intentionality.
Builders tend to offer the same out-of-the-box solutions to everyone who bought the license. Same hero patterns, same card grids, same testimonial sliders, same spacing logic, same set of tasteful defaults. They are not bad solutions. They are general solutions, built to be acceptable for the widest possible range of buyers, which is a fundamentally different goal than being right for you.
So the site starts to look like the tool. Slowly, page by page, update by update. Not wrong exactly. Just generic in a way that’s hard to point at. You can usually tell which builder a site was made with, which should tell you something about how much of the visual identity belongs to the brand and how much belongs to the vendor.
The intentionality that sits above the technical layer is all brand and design decisions made custom for one client. Not for everyone who bought the builder. That’s the part that gets flattened, and it’s the part no Lighthouse audit will ever score.
It takes something from the designers, too
Here’s the half of this argument that almost never gets made, because the conversation is usually framed as marketers versus developers.
Developer control is lost with a builder, too.
You can’t cleanly tweak a global variable for a section type. You want every instance of a particular section across forty pages to shift its vertical rhythm, or pick up a new accent treatment, and there’s no single place to reach in and do it. Type styling in particular becomes very inaccessible from the tech stack. The things a designer most wants to control globally — type scale, spacing system, color tokens — are exactly the things a builder tends to bury behind an interface, or scatter across individual page instances where somebody once overrode them.
So the builder doesn’t just hand marketers too much power. It quietly takes power away from the people whose job is the system.
That’s why this isn’t a craft complaint. Most of the industry frames the anti-builder position as developers being precious about hand-coding, and that framing lets everyone dismiss it as ego. It isn’t ego. It’s governance. A builder collapses the boundary between content and layout, and when that boundary collapses, both sides lose the thing they’re actually good at.
Marketers make content. Designers make layouts.
Draw the line in the right place and the whole problem reorganizes itself.
Marketers make content. Designers and developers make layouts. Each side gets the space it’s genuinely good at, in exact proportion.
In practice that means a content model: defined fields an editor fills in, rather than a canvas they rebuild. You write the headline, choose the image, set the link, pick which of the approved sections goes where. You do not set the type size, because the type size was decided once, correctly, by someone whose job that was.
The effect on the people doing the work is the part that surprises clients. In-house marketers enjoy these sites because they don’t have to think about any of it. It just works. They never have to consider brand, because the page is simply already in brand. There’s no moment of “is this the right blue, is this heading too big, did I break the spacing.” That anxiety is gone, because those questions aren’t theirs to answer.
Brand compliance stops being a discipline problem and becomes a structural one. Which matters, because discipline is a terrible long-term strategy. Discipline works until the person who had it leaves, or gets busy, or has to ship a landing page at 4:50 on a Friday.
Constraint is the feature. That’s the part builders got backwards.
Flexibility in the CMS, not the browser
Therefore: build the flexibility where it belongs.
Our stack, plainly:
WordPress → ACF → Timber/Twig → Tailwind → Vite → purpose-built JS
No page builders. No visual editor frameworks. Every template hand-coded with Timber and Twig, Advanced Custom Fields Pro powering the content model. That’s what we specified for a construction client, for an MEP engineering firm, and for others — and it’s how we designed and developed a general contractor’s site where the team updates content through defined fields rather than rebuilding layouts every time.
What this looks like in a client meeting is more useful than the diagram. Walking a client through their new site recently: this hero element, this would be a layout that we build for you in brand, where you can update all of the content. And you can use it on any page.
That’s the deal in one sentence. The content is open. The layout is built.
On a current project we’re also replacing an inherited custom SCSS system with Tailwind grounded in shared design tokens. Not because Sass is bad — it isn’t — but because we want one predictable styling system where a component is easy to locate, understand, and maintain. Three years from now, by somebody who isn’t us. That’s the standard.
A backend genuinely easy for a non-developer to operate, and a frontend that behaves exactly as designed, without the performance drag, update fragility, or layout constraints that come with builder-based sites. You don’t have to choose between those two things. You were only ever told you did.
The last argument for builders just expired
Strip away the marketing and builders always had one honest, load-bearing argument: changes are cheap because you don’t need a developer. That was a real economic claim, and for a long time it was true. Developer time was the expensive thing. Anything that removed developer time from the loop won on cost, even if it lost on quality.
That argument is dissolving as we speak.
Moving faster with code is a necessity now, and AI agentic coding against an established component pattern library changes the math completely. An agent can read the existing Tailwind patterns in a project — how our components are structured, what the tokens are, how spacing works — and extend them consistently. It doesn’t invent a new dialect. It repeats the one already there. That’s the whole trick: the value isn’t the agent, it’s the agent working against a system coherent enough to be read.
It’s fast. Fast enough that the savings get passed on to the client. Fast enough that tweaking a design becomes cheaper than paying an in-house marketer to spend hours fighting WPBakery to get a section to sit right.
So think about what’s left of the case. The performance argument was conceded years ago by the vendors’ own engineering blogs. The brand argument was never really contested. And the cost argument — the last one standing, the one that made the whole tradeoff worth swallowing — is being undercut by the same technology that’s rewriting everything else about how software gets made.
A builder license is still a recurring cost, incidentally. The developer you were avoiding just got significantly cheaper, and the tool you bought to avoid them did not.
What you give up
We’d rather be honest than absolute, so: this approach has real limits, and you should know them before you choose it.
A wholly new layout still requires custom work. Our clients can update content endlessly, reuse components across any page, and assemble pages from a brand-correct kit without ever calling us. But if you want a section type that doesn’t exist yet, one that behaves in a way nothing in the system behaves, that’s a build. Faster and cheaper than it used to be, for the reasons above. Still a build.
There are situations where a builder is the defensible choice. If your site is genuinely low-stakes and the budget is genuinely small, a builder is a reasonable answer and we’d tell you so. If you have a large internal team that wants to be hands-on with layout every week and has the design capability to do it well, a builder gives them a playground and that may be exactly right. If you’re testing an idea and the whole thing might be gone in six months, don’t over-engineer it.
And the builders are improving. Everything in the receipts section is evidence of companies working hard on a real problem. The gap is narrower than it was in 2019.
It just isn’t closed, and the part that isn’t closed — who controls the layout — is architectural rather than a matter of shipping fewer kilobytes.
What to ask before you sign
If you’re about to approve a website build, or about to inherit one, these are worth asking out loud. They’re useful whether or not you ever talk to us.
- What exactly can my team change, and what can’t they? A good answer is specific and confident. A vague “oh, anything” is not reassurance, it’s a warning.
- If we change our brand type or a core color in two years, where does that change happen? One place, or forty?
- What gets sent to a visitor’s browser on a page that’s just text and an image? If the answer includes a JavaScript framework, ask why.
- Who is responsible for a page staying on brand — the system, or the person making it? If it’s the person, what happens when that person leaves?
- What does a small design change cost, and what does a brand new section type cost? Get both numbers. They are very different questions.
- Can you show me the admin, not the demo? Anyone can drag a block across a screen. Ask to see the actual editing experience of a site they built two years ago.
The real decision isn’t builder versus custom. It’s how you want your organization to work.
If you want to be in the weeds of every design decision, if that’s genuinely your team’s strength and appetite, keep using page builders. That’s a legitimate way to run a website and we’re not going to pretend otherwise.
But if you want to move fast, stay in brand without thinking about it, and let people wear decisive hats — then engineer something that does that. Streamline the stack for how you actually work, not for how a demo made you feel in a conference room.
