The trade that was made
Page builders like Elementor, Divi and WPBakery let someone build a WordPress site visually, without a developer, and that is a real benefit. The trade is that the builder ships every capability to every page: its full stylesheet, its full script bundle, its animation library, its icon fonts, plus whatever each add-on pack brings. A page that shows a heading, a paragraph and a button loads the machinery for sliders, counters, forms, pop-ups and parallax, in case.
On a fast connection on a laptop, nobody notices. On a mid-range phone on mobile data, it is the difference between a site that appears in a second and one that appears in four.
Is the builder actually the problem on your site?
Measure before blaming. Run the home page through PageSpeed Insights on mobile and look at three things:
- Total page weight and requests. Builder sites commonly load 60 to 120 files and two to four megabytes on a simple page. Under 30 files and one megabyte would be reasonable for the same content.
- "Reduce unused CSS" and "Reduce unused JavaScript". If the top entries are the builder's files (
elementor,divi,js_composer), the builder is loading far more than the page uses. - The main-thread time, in the Performance panel. Builder scripts initialising are often the largest block before the page becomes interactive.
Also check the Core Web Vitals report in Search Console: if LCP and INP are failing across the site rather than on specific pages, a site-wide cause like the builder is likely.
If the builder's files dominate all three, it is the cause. If images or third-party scripts dominate, fix those first; the builder may be fine.
What can be done without leaving
The builders know they are heavy and have added settings. Used together, these typically recover a third to a half of the lost speed.
Elementor: Settings, Features and Performance. Enable "Improved Asset Loading" and "Improved CSS Loading" (or their current names), inline font icons, disable the Google Fonts loading in favour of self-hosted or system fonts, turn off the widgets you do not use in Element Manager, and set the "Optimized DOM output" and "Optimized Markup" experiments on. Remove add-on packs you installed for one widget.
Divi: Theme Options, Performance. Dynamic CSS, dynamic JavaScript libraries, dynamic icons, critical CSS, deferring of the builder's scripts, and disabling of Google Fonts and the unused modules. Divi's later versions load considerably less when these are on.
WPBakery: fewer options. Remove unused add-ons; use a caching and optimisation plugin to defer its scripts; consider the move.
All builders: a caching plugin that generates critical CSS and defers JavaScript (WP Rocket, FlyingPress, Perfmatters alongside a cache). Compress and resize every image. Remove the sliders on pages that do not need them. Self-host fonts. Reduce the number of fonts to two. Load embeds (maps, video, Instagram feeds) on click rather than on load.
Do this on staging, measure again, and check the site still works, because the "optimised" loading modes occasionally break a widget.
What cannot be fixed
The floor. A tuned Elementor or Divi site still loads more CSS and JavaScript than a well-built theme needs, because the builder's architecture assumes every page might need everything. After the settings above, most builder sites land at "needs improvement" rather than "good" on mobile, and further gains require removing the builder.
The other thing that cannot be fixed is the lock-in: content stored in builder shortcodes or JSON, so that switching the theme or removing the builder leaves pages as a wall of broken markup. That is what makes leaving a project rather than a toggle.
When to leave
- The tuning above has been done and the site still fails Core Web Vitals on mobile.
- The site is due a redesign anyway, so the content is being re-entered regardless.
- Nobody at the business uses the builder to edit; the visual editing benefit is not being collected.
- The site depends on add-on packs that are abandoned or breaking with updates.
- Speed is a commercial priority: search rankings in a competitive local market, or ad spend that depends on landing page conversion.
When two or more apply, a rebuild onto a block theme or a lightweight framework, with the content moved over properly and URLs preserved, is the answer. It is a project, and it is the last time the question comes up.
When to stay
- The site passes or nearly passes Core Web Vitals after tuning.
- Someone at the business genuinely edits with the builder and values it.
- The budget for a rebuild is not there this year.
- The site is small and its traffic is not search-dependent.
Stay, tune, and revisit in a year.
Where this sits
Assessing whether a builder is the bottleneck, and how much tuning recovers, is a routine part of the diagnosis we run on slow WordPress sites, and the answer is written down with the numbers before anyone commits to a rebuild. Where the decision is to stay, the tuned settings become part of the care plan so the next builder update does not quietly turn them off, which they sometimes do.