Home · Page builders vs custom code
Why we don’t use page builders (Elementor, WPBakery)?
Page builders promise a fast build, but you pay for it later – a slower site, bloated code and dependence on a plugin you don’t control. We hand-code every WordPress site with clean, custom code that stays fast and stays yours.
Short answer
A page builder is worth considering if you’re building a small site yourself and design experience is limited – but the result is almost always slower and harder to maintain than hand-coded WordPress. Elementor and WPBakery add their own framework on top of every page – extra code, CSS and JavaScript the browser has to process on every load – and your content gets saved in the builder’s own format rather than as plain WordPress content. Massruum writes sites by hand, without a builder: our sites typically have sub-second load times and Lighthouse scores in the 90s on desktop, while a page-builder site is carrying a lot more weight before it can even try to match that.
The real cost
What a page builder actually costs you.
01
Performance and code bloat
Elementor and WPBakery turn every page element into a “widget” with its own CSS file, JavaScript and HTML wrapper. Even a simple page ends up loading dozens of extra files and hundreds of kilobytes of code it doesn’t actually need. That’s not a hypothesis – it’s how both tools work technically: every page carries the weight of the whole plugin framework, regardless of how little of it the page actually uses.
- Every widget ships its own CSS/JS file
- Render-blocking scripts slow down first paint
- Rendering depends on the builder’s own engine, not just WordPress
02
DOM and markup bloat
Page builders often wrap a single paragraph in dozens of nested <div>s, because every visual setting – column, spacing, alignment – needs its own layer. A deeper DOM means more work for the browser, slower rendering, and markup that’s harder for search engines and screen readers to parse.
- Dozens of extra
<div>s for one simple section - Inline styles that override your CSS
- Harder accessibility and SEO crawling
03
Vendor lock-in
Elementor and WPBakery content is saved either as expanded shortcodes or in a builder-specific JSON format, not as plain WordPress content. That means if you switch the builder off – or the builder disappears from the market one day, as has happened to other plugins – your site is left with a pile of unreadable shortcodes or a broken layout. Moving to something else usually means rebuilding the page, not migrating it.
- Content isn’t readable or editable without the builder
- Removing the builder means rebuilding the page from scratch
- Long-term dependence on one company’s continued support
04
Maintenance and update fragility
Every Elementor or WPBakery update can change how widgets behave, shift a layout, or undo an earlier customisation – on a timeline you don’t control. Updating three moving parts at once – WordPress core, the theme and the builder – creates more chances for something to break, and “why is this broken now” becomes routine. A hand-coded theme depends on WordPress core alone.
- More dependencies mean more ways to break
- A builder update can change an existing layout
- Harder to trace bugs when you don’t control the code
The fair view
When a page builder makes sense.
Honestly, page builders have their place. If you’re building a small hobby site yourself with no budget for a developer, and you want to make visual decisions by dragging and dropping, Elementor gives you a fast starting point. It also works fine for a very simple site that isn’t expected to grow for years. The problem shows up when a business site grows, needs speed, and has to carry that business for years – that’s exactly where a builder’s limits start to hurt.
Our approach
Hand-coded WordPress.
Massruum sites are written by hand – a custom FSE theme and plain Gutenberg blocks, no Elementor, no WPBakery. That means every page carries only the code it actually needs, not an entire builder framework just in case.
The result is measurable: our sites typically have sub-second load times and Lighthouse scores in the 90s on desktop. Content stays as plain WordPress content – Gutenberg blocks you can edit yourself later, with no builder required. And because we keep the plugin count low (usually just Rank Math and Google Site Kit), long-term maintenance stays simpler and cheaper too.
Frequently asked
Page builders – frequently asked.
Elementor isn’t “bad” software – it’s popular, and it works fine for plenty of people. The issue isn’t the tool itself, it’s the trade-off it inevitably brings: more code on every page, dependence on the builder’s own engine, and a harder path if you want to switch later. For a small hobby site, that trade-off is usually fine; for a growing business’s main site, usually not.
Hand-coded WordPress is almost always faster, because the site only carries the code it actually needs. Elementor adds its own framework to every page – extra CSS and JS files, render-blocking scripts and a deeper DOM – regardless of how simple the page is. Our sites typically load in under a second; page-builder sites tend to fall well short of that unless they’re heavily optimised.
Yes. We build sites with plain Gutenberg blocks, which are part of WordPress itself, not a builder-specific format. That means you can edit text, images and pages yourself later without learning Elementor or WPBakery, and we hand over a clear guide.
They share the same core problem – extra code the browser has to process, and content saved in the builder’s own format. WPBakery has a reputation for being older and heavier, often due to shortcode-based bloat (bracketed code snippets inside your text); Elementor is quicker to use visually but carries its own JavaScript framework. In our view, neither is the best long-term choice for a site that needs to carry a growing business.
It depends on the site and how well it’s optimised, but the direction is clear: more code, more requests and a deeper DOM mean slower rendering. A well-optimised Elementor site can be decent; most aren’t, because optimising on top of a builder is harder than optimising hand-written code. We measure every project with Core Web Vitals and Lighthouse, not guesswork.
Yes, but it’s usually a rebuild rather than a simple migration – Elementor content doesn’t convert automatically into plain WordPress content. We start with a technical review, carry the design across, build the site with hand-coded code, and move the content over so the result stays manageable as plain Gutenberg blocks.
Let’s start
Need a WordPress site built to last?
Tell us what your business does and where you want to go – we reply within one working day with a concrete price range.
