We have never built a website with Elementor. We have never used Divi, WPBakery, Beaver Builder or any other page builder. Every site we ship is hand-coded from scratch as part of our WordPress development approach — PHP, HTML, CSS, JavaScript, nothing else. And after years of watching what happens to clients who come to us from page builder agencies, we would make the same choice every time.
This is not tribalism or snobbery. It is a straightforward technical argument backed by measurable outcomes. Here is the case against page builders that the agencies selling them will never make.
What a page builder actually does to your website
A page builder works by wrapping every element of your website in its own layer of markup, CSS and JavaScript. A simple button in Elementor does not output a button. It outputs a widget container, a widget wrapper, an inner wrapper, a content box, a link wrapper — and then a button. Five nested divs where one would do.
Multiply that across every element on every page of your website and you end up with thousands of lines of unnecessary code that the browser has to download, parse and render before your visitor sees anything. Google measures exactly how long that takes. So do your visitors — consciously or not.
The numbers are not subtle. A typical Elementor page loads two to four times more CSS and JavaScript than an equivalent hand-coded page. In a world where Google’s Core Web Vitals directly influence your search rankings and where 53% of mobile visitors abandon a page that takes longer than three seconds to load, that is not a minor inconvenience. It is a measurable hit to both your rankings and your revenue.
The performance gap in practice
When clients come to us from page builder agencies, we run their existing site through Google PageSpeed Insights before we start the rebuild. The pattern is consistent enough that we have stopped being surprised by it.
Page builder sites typically score between 30 and 65 on mobile PageSpeed. That range covers everything from poor to mediocre. The causes are almost always the same: render-blocking JavaScript from the builder and its add-ons, unused CSS that the browser loads anyway, unoptimised images wrapped in builder markup that prevents proper lazy loading, and a DOM size that is three to five times larger than it needs to be.
After a custom rebuild on the same content and hosting, those scores move to 90-100. Not because we do anything exotic — but because there is no unnecessary code in the way. The browser gets a clean document, loads only what it needs, and renders the page in a fraction of the time.
That difference in load time correlates directly with better rankings, lower bounce rates and higher conversion rates. The relationship is well documented. Faster pages rank higher. Faster pages convert better. Faster pages retain visitors longer. Every improvement in performance compounds into better business outcomes.
The security problem nobody mentions
Page builders ship with extensive JavaScript and PHP code bases. Every line of that code is a potential attack vector. And because these tools are used on millions of websites, they are high-value targets for security researchers and malicious actors alike.
Elementor alone has had dozens of publicly disclosed security vulnerabilities over the years — some of them critical, allowing remote code execution or privilege escalation on affected sites. The same is true of every major page builder and the add-on ecosystems that surround them.
A hand-coded theme has none of this exposure. There is no third-party code base to exploit. The only code on the server is code we wrote, code we understand completely, and code we can audit in its entirety. When a vulnerability is discovered in a popular plugin, sites built with it need urgent patching. Sites built without it are simply not affected.
The lock-in problem that nobody warns you about
Here is the conversation we have repeatedly with new clients. They want to switch from their current agency. They want a faster, better website. Simple enough — except when we look at their existing site, it is built entirely in Elementor or Divi.
The content is not in WordPress. It is in the page builder. Every heading, paragraph, image and layout choice is stored as serialised builder data in the database. It cannot be exported cleanly. It cannot be migrated to a different theme. The only way to leave is to rebuild everything from scratch — which is exactly what the client has to pay for again.
A hand-coded WordPress theme stores your content in WordPress. The standard post content field. The standard custom fields. Clean, portable, independent of any specific tool. If you ever want to change agency, change theme or change platform, your content comes with you. That is what genuine ownership of your website looks like.
What you lose in flexibility
The promise of page builders is flexibility — the ability to change anything about your site without a developer. In practice it rarely works out that way. Changing the font size on one section breaks the styling of three others. Moving a widget resets its settings. Adding a new section in the wrong place triggers layout issues that cascade down the page.
Hand-coded sites can be built with equally intuitive editing interfaces through WordPress’s native block editor or custom metaboxes. The editing experience can be designed specifically for the content you need to edit — without the hidden complexity, the layout drift and the performance overhead that page builders bring with them.
The honest counter-argument
Page builders exist for a reason. They allow agencies with limited development skills to ship websites faster and more cheaply. For clients with very small budgets, a page builder site is often better than no site. We acknowledge that.
But if performance matters to you — if you care about Google rankings, page speed, security and the long-term health of your website — a hand-coded site is not a luxury. It is the correct technical choice. The performance gap is real, measurable and significant. The security exposure is real. The lock-in is real.
We choose to build properly. Every time.
If you want to see what your current site scores — and what it could score after a proper rebuild — we offer a free website audit that covers exactly this. Or if you are ready to discuss a custom build, get in touch for a free quote.
Frequently asked questions
Is Elementor really that bad for performance?
It depends on how it is used, but even optimised Elementor sites carry more overhead than equivalent hand-coded sites. The gap is smallest on simple sites and largest on complex ones with multiple sections, animations and add-on functionality.
Can you speed up an existing Elementor site without rebuilding?
To a point. Caching, image optimisation and some code minification can improve scores. But the fundamental overhead of the builder markup and JavaScript cannot be removed without removing the builder itself. Significant performance improvements require a proper rebuild.
Do page builders affect SEO?
Yes — through performance, which directly affects Core Web Vitals, which are a confirmed Google ranking factor. Slow sites rank lower. The content of a page builder site can be excellent but if the site loads slowly, that excellence is partially offset by the performance penalty.
What do you use instead of a page builder?
We build custom PHP templates for each page type, with content managed through WordPress’s native editor and custom fields. The result is a site that looks exactly as designed, performs at the highest possible level and can be updated intuitively without touching code.
