A single heading that should be six characters of HTML becomes six nested divs in a page builder. Multiply that by every element on every page, and you start to understand why your website is slow.
You paid for a custom website. Did you get one?
You hired a web designer. They showed you mockups. You went back and forth on colours, fonts, and layout. They delivered a website that looked like what you agreed on. You paid the invoice. Job done.
But behind the design, something else was happening. Your designer was not writing code. They were dragging and dropping pre-built blocks into a visual editor. They were using a page builder.
59 percent of WordPress websites use a page builder. The most popular, Elementor, is installed on nearly a third of all WordPress sites. Then there is Divi, WPBakery, Beaver Builder, and a dozen others. These tools let someone build a website without writing HTML, CSS, or JavaScript. That sounds like a good thing. It is not.
Our blog Why we don't use WordPress (and when you should) covers the broader platform problems beyond page builders.
What is a page builder?
A page builder is a plugin that sits on top of WordPress and provides a visual, drag-and-drop interface for building pages. Instead of writing code, the designer drags a heading block onto the page, types the text, adjusts the font size with a slider, and moves on to the next block.
The result looks fine on screen. But what the designer sees is not what the browser receives. Behind every block, the page builder generates its own HTML, its own CSS, and its own JavaScript. And it generates far more of all three than a hand-coded website ever would.
Six divs to hold a heading
In clean HTML, a heading looks like this: a single h2 tag with the text inside it. Six characters of code. The browser reads it instantly.
In Elementor, that same heading is wrapped in a section div, a container div, a column div, a widget-wrap div, a widget div, and a widget-container div. Six nested layers of code before the browser reaches the actual heading. Every element on the page gets the same treatment. Every paragraph, every image, every button.
Google recommends that a web page should have fewer than 1,500 DOM nodes. A DOM node is essentially one piece of the page structure, one div, one heading, one paragraph. A typical Elementor page generates three to five times more DOM nodes than the same page written by hand. A simple five-page brochure site can easily exceed 3,000 nodes per page.
Every one of those nodes has to be downloaded, parsed, and rendered by your visitor's browser. On a phone, over mobile data, that difference is not academic. It is the difference between a page that loads in one second and a page that loads in four. Our blog Why your website needs to load in under two seconds explains why that gap costs you customers.
Your website loads code it does not use
Page builders do not just add extra HTML. They load their own CSS framework and their own JavaScript libraries on every page of your site.
Elementor adds 180 to 280 kilobytes of CSS and JavaScript per page on top of whatever your theme already loads. It includes a slider library even if you have no sliders. It loads an animation library even if nothing animates. It loads the entire Font Awesome icon set even if your site uses no icons.
On a typical Elementor site, 40 to 60 percent of the loaded CSS is unused. It is downloaded by every visitor, parsed by every browser, and thrown away without ever being applied to anything on the page.
Each of those files is a separate request your visitor's browser has to make. A page built with Elementor can trigger 75 or more HTTP requests before a single word of text appears. A hand-coded page doing the same job might make 10.
The numbers your designer never showed you
Independent benchmarks tell a consistent story. WP Rocket tested every major page builder on identical hosting with identical content. Elementor scored 81 out of 100 in controlled lab conditions. Divi scored lower. In real-world testing across thousands of sites, the numbers are worse. The Admin Bar study found Elementor's median Lighthouse score was 66. Divi's was 62.
For comparison, a hand-coded approach using native blocks or a lightweight framework scores 88 to 90 in the same tests.
One agency documented the before and after of removing Elementor from a client site. PageSpeed went from 49 to 88. Page weight dropped by 42 percent. First paint dropped from 1,400 milliseconds to 499 milliseconds. The server was the same. The hosting was the same. The content was the same. The only thing that changed was removing the page builder.
Divi is worse still. Lab testing put Divi's page weight at 6.9 times heavier than a lightweight theme for the same content, with a Largest Contentful Paint of 5.8 seconds. Google considers anything over 2.5 seconds to be a problem.
Our blog What your PageSpeed score is actually telling you breaks down what these numbers mean and why they matter for your business.
Even Wix passes more Core Web Vitals than this
Core Web Vitals are the three performance metrics Google uses to measure real user experience. Only 46 percent of WordPress sites pass all three on mobile. Our blog Core Web Vitals: what they are and why most websites fail them explains what these metrics are and why they matter.
Wix passes at 75 percent. Squarespace passes at 70 percent. These are the platforms WordPress developers have spent years dismissing as toys for beginners. They outperform WordPress because they control the entire stack and can optimise globally. WordPress cannot do that because any theme or plugin can inject unoptimised code. And page builders are the single largest contributor.
The irony is difficult to overstate. A business owner who paid a professional to build their WordPress site with Elementor would have got better performance from a free Wix template.
Your content is trapped
Page builders do not store your content as clean HTML in the database. Elementor stores it as serialised JSON, a complex data format that only Elementor can read. WPBakery stores it as shortcodes, custom tags like [vc_row] and [vc_column] scattered throughout your content.
If you deactivate Elementor, your pages turn into blank screens or gibberish. If you deactivate WPBakery, your visitors see raw shortcode tags where your content used to be. Your content is not yours. It belongs to the plugin.
Switching from one page builder to another means rebuilding every page from scratch. Switching from a page builder to clean code means the same. There is no export button. There is no migration tool that does it properly. You are locked in, and the only way out is a rebuild.
A business that paid a designer to build with Elementor is now tied to Elementor forever. Every future developer must work within that ecosystem, or the business pays for a complete rebuild. That cheap website just got expensive. Our blog Why cheap websites cost more in the long run explains how this pattern plays out.
The ThemeForest starter pack
It gets worse. Many designers do not just use a page builder. They start with a pre-made theme from ThemeForest, the largest marketplace for WordPress themes. The top seller, Avada, has sold over 704,000 copies.
These themes come bundled with a page builder, a premium slider plugin, and a collection of add-on widgets. The theme listing advertises these as bundled plugins worth hundreds of pounds. What it does not mention is that those plugins come without individual licences. You get the plugin files but not the right to update them directly. Security patches depend on the theme author packaging the updated version, which can take weeks or months.
When the designer imports the theme's demo content to use as a starting point, they import everything. Every widget, every layout variation, every feature the demo showcases. Even if the site only needs five pages and a contact form, it inherits the infrastructure of a complex portfolio, ecommerce, and blog hybrid. One developer found a single ThemeForest theme loaded 47 external scripts on the homepage alone.
The theme adds bloat. The page builder adds bloat. The plugins add bloat. Each layer compounds the last, and the person paying the invoice has no way to see any of it. Our blog Death by a Thousand Plugins covers the full cost of this accumulation.
Your designer probably never mentioned it
Most business owners have no idea their website was built with a page builder. The designer called it a custom website. It looked custom. The colours matched the brand. The layout was unique enough. But underneath, it was assembled from pre-made blocks using a drag-and-drop tool, on top of a theme someone else designed, running on a platform that was never built for this kind of use.
This is not about blame. Page builders exist because there is demand for them. Not every designer can write code, and not every project budget allows for hand-coded development. But the business owner deserves to know what they are getting. A page builder site and a hand-coded site are not the same product, even if they look identical on screen.
If your site scores below 60 on Google PageSpeed, has a load time above three seconds, or triggers dozens of render-blocking resource warnings, there is a good chance a page builder is why.
What this site is built with
This website is not built with WordPress. It does not use Elementor, Divi, WPBakery, or any page builder. It does not use a ThemeForest theme. Every line of code was written by hand.
The page you are reading right now loaded from one domain. Ours. It made fewer than 10 requests. There are no div wrappers around div wrappers around div wrappers. There is no unused CSS. There is no JavaScript library loaded for a feature that does not exist on this page.
It scores 100 on Google PageSpeed. Not because we spent months optimising a slow foundation. Because we started with a clean one.
The bottom line
Page builders are not evil. They are tools that serve a purpose. For a designer who cannot write code, they make it possible to deliver a working website. For a business owner with a small budget, they can be better than nothing.
But they come with a cost that is almost never disclosed. Extra code that slows every page. Unused CSS and JavaScript that your visitors download for no reason. Content locked inside a proprietary format you cannot take with you. And a dependency on a plugin that has to be maintained, updated, and kept compatible with WordPress indefinitely.
If your website was built with a page builder, you should know about it. Not to be angry at your designer, but to understand why your site is slow, why your PageSpeed score is low, and what it would take to fix it. The answer is usually not another plugin. It is less code, not more.
How we can help
Every website we build at BIG MOUTH is hand-coded from scratch. No page builders. No pre-made themes. No drag-and-drop tools generating code behind the scenes. The result is a website that is faster, lighter, and entirely under your control.
If your current site was built with a page builder and you are not happy with its performance, we can audit it and show you exactly what is happening under the surface. Sometimes the answer is targeted optimisation. Sometimes the honest answer is that a clean rebuild will cost less in the long run than continuing to patch a slow foundation.