Page Builder Bloat: Elementor, Divi and Speed

A visual page builder makes a WordPress site easy to lay out. It also adds code that every visitor’s browser has to load. Whether that costs you speed and rankings depends on how much a page loads, how the builder is set up and what real visitors experience.

We build hand-coded WordPress sites through our custom WordPress development service, so weigh that. Every fact below about Google’s metrics, Elementor, Divi and WPBakery was checked against their own documentation in October 2026.

Short answer: Page builder bloat is code a page loads but doesn’t need: scripts, stylesheets and wrapper elements that make drag-and-drop editing work. It shows up in Core Web Vitals, measured at the 75th percentile of real visits. Elementor and Divi both ship settings that load less code, so switch those on and check your field data first. Google uses Core Web Vitals in ranking, but relevance comes first. Rebuild when field data still fails after tuning, or when the layout needs to change anyway.

What Google, Elementor and Divi Document

As of October 2026, from Google, Elementor and Elegant Themes documentation:

Sources: web.dev Web Vitals, PageSpeed Insights docs, web.dev on TBT, Google page experience, Elementor performance features, Divi 5 Theme Options.

What Is Page Builder Bloat?

Page builder bloat is the extra CSS, JavaScript and HTML a visual editor adds so any layout can be built without code. It isn’t a bug. A builder supports every widget and layout option it offers. The question is how much of that a single page carries.

Builders have worked on this. Elementor’s developer blog explains that up to version 3.1.0, every widget’s JavaScript handler loaded on every page. With “Improved Asset Loading”, each widget loads its handler only when it’s on the page (source). Divi 5’s settings page describes the same aim: load what each page needs, not everything at once (source).

So bloat isn’t a fixed number per builder. It depends on the version, the settings, the add-ons and how the page was built.

The Real Performance Cost

Google measures what visitors experience through three Core Web Vitals (source). Extra code can hurt each one.

Largest Contentful Paint (LCP) is how long the main content takes to appear. Good is within 2.5 seconds. Stylesheets and synchronous scripts still loading in the page head block rendering, so web.dev recommends reducing or inlining render-blocking stylesheets (source).

Interaction to Next Paint (INP) is how quickly the page responds to taps and clicks. Good is 200 ms or less. A larger DOM makes rendering more expensive and can slow responses (source), and every wrapper a builder adds is part of the DOM. Lab tests show Total Blocking Time instead, a proxy for INP with a target under 200 ms (source).

Cumulative Layout Shift (CLS) is how much the page jumps while loading. Good is 0.1 or less. Common causes include images and embeds without dimensions, injected content and web fonts (source). Builders can cause these. So can hand-written code.

Why Caching Doesn’t Fix It

The common reply: “I have caching and a CDN. My site loads fast.”

Caching speeds up how files arrive. It doesn’t change what’s in them. A cached stylesheet still has to be applied before the page renders. A cached script still runs on the visitor’s phone. A deep DOM still has to be laid out. Those are the costs LCP, INP and TBT pick up.

Optimization plugins that minify and defer files are useful. They work on what the builder produces. The builder’s own settings change what it produces, which is why they come first.

Elementor vs. Divi vs. WPBakery: The Breakdown

Elementor

Elementor is active on more than 10 million sites, per its WordPress.org listing (source). Its help centre lists speed features that reduce code and optimize the DOM (source):

• Element Caching (experimental): serves a stored copy of an element instead of rendering it each time.
• Inline Font Icons: draws icons as inline SVG, without loading icon font libraries.
• Optimized Image Loading: adds high fetch priority to LCP images and lazy-loads images below the fold.

Widgets are treated as dynamic and not cached by default, and one using a dynamic tag or display condition is always fully rendered (source).

Divi

In Divi 5, speed settings sit under Theme Options, General, Performance: dynamic CSS, dynamic icons, critical CSS and deferred scripts (source). Elegant Themes says Divi 4 stores content as WordPress shortcodes, while Divi 5 uses a block-based format and loads JavaScript on demand (source).

WPBakery

WPBakery’s troubleshooting guide says that when a page shows its shortcodes instead of page elements, the most common reason is that the plugin is deactivated (source). That’s less about speed than about how tied your content is to the builder.

What a Hand-Coded Site Actually Looks Like

A hand-coded theme loads what each template needs. For a typical service page:

• CSS for the components on that page, not every component the site could use
• JavaScript only where something is interactive, like a form or menu
• Plain, semantic HTML without layers of wrappers

Editing doesn’t have to suffer. WordPress’s block editor handbook covers block locking, to restrict what editors can change, and patterns, which are predefined block layouts (source). Your team edits text, images and calls to action. The layout stays in the theme.

How Much Speed Matters for SEO

Google says Core Web Vitals are used by its ranking systems, but there’s no single page experience signal. It says Search “always seeks to show the most relevant content, even if the page experience is sub-par”, and that page experience helps most when lots of helpful content competes (source).

So the ceiling is real but narrow. A slow page won’t stop relevant content ranking. Among close competitors, page experience can separate you.

To check, start with PageSpeed Insights. Field data comes from real Chrome users over 28 days. Lab data comes from a simulated Lighthouse load, useful for debugging (source). The two can disagree (source). Honest, the pay-per-report audit tool we run, has a speed audit covering Core Web Vitals, render-blocking resources and mobile vs desktop.

The “But It’s Easier” Argument

The strongest case for a builder is that people who don’t code can change layouts. For a team rebuilding landing pages every week, that may be worth the extra code.

For a site whose layout changes a few times a year, you carry the builder’s code on every visit for flexibility you rarely use. Locked layouts with editable blocks cover the edits teams make most.

How to Measure a Page Builder Rebuild

We don’t publish before-and-after ranges, because every site starts somewhere different. Measure the same way before and after:

1. Field data in PageSpeed Insights for your key templates
2. LCP, INP and CLS at the 75th percentile, not only the lab score
3. Lighthouse results on the same pages, for debugging
4. Enquiries from those pages over a comparable period

If field data already passes, a rebuild for speed alone is hard to justify.

Related Posts

• Hand-coded vs page builder performance: the two approaches side by side
• WordPress plugin bloat: the other common source of extra code
• Lighthouse score explained: what the lab score tells you
• Core Web Vitals business impact: the three metrics in plain terms

FAQ

Can I remove Elementor from my existing site without losing my content?

Elementor’s developer docs say it stores each layout as JSON in WordPress post metadata, which its frontend parses to build the page (source). Without the plugin, nothing reads that layout. Plan to rebuild layouts, and test on a staging copy first.

Are there any page builders that don’t hurt performance?

Any builder adds code a hand-written template doesn’t need. How much it matters depends on version, settings and the page. Turn on the builder’s performance settings, then check field data.

Why do web designers use page builders if they hurt performance?

Speed of production, and clients who want to change layouts themselves. Both are fair reasons. Ask how the site will be edited and how speed will be measured after launch.

Does Google’s algorithm actually penalize slow sites?

Core Web Vitals are one of many signals Google’s ranking systems use, and Google still shows the most relevant content when page experience is weak.

My site was built with Elementor and has decent traffic. Should I rebuild it?

Not on speed alone. Check field data, turn on Elementor’s performance features and fix images and plugins. If key templates still fail, or the site needs a redesign anyway, scope a rebuild.

How long does a page builder to custom code rebuild take?

It depends on the templates, content and integrations, so we don’t quote a standard timeline. We scope it after looking at your site.