If you've ever had a WordPress website built, there's a good chance it was built with a page builder. Elementor is the most common one. Divi, WPBakery, and Beaver Builder also have large user bases.
They're popular for a reason. Page builders let you build pages visually, dragging and dropping elements without writing code. For agencies, they speed up production. For clients, they seem to offer flexibility.
We don't use them. Here's why.
What page builders actually produce
When you build a page with a page builder, the tool generates the HTML and CSS for you. The problem is that it generates a lot more of it than the page actually needs.
A simple section that displays a heading, some text, and a button might need fifty lines of clean code. The same section built in Elementor might produce five hundred lines, with wrapper divs nested inside wrapper divs, inline styles scattered throughout, and scripts loaded on every page whether they're needed or not.
All of that code has to be downloaded and processed by the browser before the page appears. On a fast connection, the difference is noticeable. On mobile data, it's significant.
The maintenance problem
There's a second issue that shows up over time.
Page builder pages are fragile. When a plugin updates and something breaks, the fix often isn't straightforward. When you want to change one element without changing another, the visual editor sometimes doesn't give you precise enough control. When you hand the site over to the client's team, the editing experience depends entirely on the page builder's interface - which may or may not make sense to a non-technical person.
We've rebuilt sites originally built in Elementor where the client had been paying developers to make basic changes because the page builder had made the site so complicated to edit that they couldn't do it themselves.
What we do instead
We build custom WordPress themes. The code does exactly what the page needs and nothing else. It's faster because there's no unnecessary overhead. It's easier to maintain because the structure is clear. And it's easier for clients to update because we build an editing experience around how they actually work, not around what the page builder defaults to.
For pages where the client needs to make regular updates - news pages, team pages, service listings - we set up flexible content areas using WordPress's native block editor, which is capable, well-maintained, and doesn't require a third-party dependency to function.
When we might use something else
If a client has an existing Elementor site and needs incremental improvements rather than a rebuild, we'll work within that. Burning it down and starting over isn't always the right answer, and a pragmatic improvement is usually better than an ideologically pure rebuild.
But for new builds, we start clean. The result is a site that loads faster, is easier to maintain, and doesn't create problems the moment a plugin has a bad update.
If you've been told your WordPress site needs rebuilding because it's slow or hard to edit, the page builder is often the actual cause. Get in touch and we'll tell you honestly whether that's the case and what fixing it would involve.