You built the site in Elementor because it let you design without a developer. That was a rational trade and it worked.
Then PageSpeed Insights gave you a 34, and now everyone on the internet is telling you page builders are the problem and you should rebuild in Gutenberg.
You probably shouldn't. A well-configured Elementor site can pass Core Web Vitals — it just takes deliberate work that a default install doesn't do for you. Here's what's actually costing you and what to change.
The short version
The overhead is real but manageable. Builders add CSS and JavaScript frameworks, deep nested markup, and per-widget assets.
Five things fix most of it:
- Turn on Elementor's own performance features — several are off by default
- Cut the widget and addon count
- Simplify nested section structure
- Fix the hero image, which is usually your LCP element
- Use a caching plugin properly on top
Rebuilding in Gutenberg is rarely worth it unless you were going to redesign anyway.
Where the weight actually comes from
Four sources, and knowing which is which tells you what to fix.
The framework. Elementor loads its own CSS and JavaScript on every page that uses it. That's the baseline cost, and it's unavoidable while you're using the builder.
Per-widget assets. Historically Elementor loaded assets for widget types whether or not the page used them. Recent versions load more conditionally — but only if the relevant setting is enabled, and it isn't always.
Nested markup. Builders generate deeply nested div structures — section, container, column, widget wrapper, widget. More DOM nodes mean more for the browser to parse, style, and reflow, which affects both rendering and INP.
Third-party addons. This is frequently the biggest contributor and the one people overlook. Essential Addons, Ultimate Addons, Happy Addons and similar each load their own CSS and JS. Install three addon packs for four widgets and you've multiplied the framework cost.
Step 1 — Turn on the performance features
Elementor ships several optimisations that aren't all enabled by default. Go to Elementor → Settings → Features (labelled Experiments in some versions) and work through them.
Optimized DOM Output — reduces the wrapper elements Elementor generates. Fewer DOM nodes, lighter markup.
Improved CSS Loading — loads stylesheets more conditionally rather than site-wide.
Inline Font Icons — loads icons as inline SVG instead of pulling an entire icon font file. Genuinely significant if you use a handful of icons, which is most sites.
Optimized Image Loading / Lazy Load Background Images — helps, with the important caveat below about your hero.
Element Caching, if available on your version — caches rendered widget output.
How to do this safely: enable one at a time, then check the site properly — desktop, mobile, forms, menus. These change how markup and CSS are generated, and occasionally a design that depended on old behaviour shifts. Enabling all five at once and discovering something broke gives you no idea which one did it.
Also worth checking: Elementor → Settings → Advanced for options to disable Google Fonts loading (self-host instead) and Font Awesome if you're not using it.
Step 2 — Audit your addons
The highest-return step on most Elementor sites.
Go through your plugin list and find every Elementor addon pack. For each, ask: how many widgets from this pack am I actually using?
The common answer is one or two. And you're loading an entire library's CSS and JavaScript for them.
What to do:
Consolidate. If three packs each supply one widget, find one pack that covers all three and remove the others.
Check for a module toggle. Most addon packs let you disable individual widgets you don't use, which cuts their asset load substantially. This is the single fastest win available and almost nobody does it.
Rebuild the one widget. If a whole pack exists for a single testimonial slider, consider whether a core Elementor widget or a small dedicated plugin does the job.
Step 3 — Simplify your structure
Elementor makes nesting easy, and sites accumulate it: a section containing a container containing columns containing an inner section containing widgets.
Every level adds DOM nodes. Deep DOM trees slow style calculation and layout, which hurts rendering and contributes to INP.
Practical moves:
Use Containers (flexbox), not the old Section/Column structure. Containers produce substantially flatter markup for the same layout. New sites should default to them.
Flatten what you can. Look at your templates — header, footer, and any layout repeated across the site — and remove wrapper levels that exist for no reason.
Reuse templates rather than rebuilding similar layouts differently on each page.
You don't need to rebuild everything. Fixing your header, footer, and main page template covers most of your traffic.
Step 4 — Fix the hero image
On most Elementor sites, the LCP element is a hero image or a section background image. PageSpeed will name it under Diagnostics.
Three things:
Correct format and size. WebP, sized to actual display dimensions. A 3000px background image displayed at 1400px is downloading twice the necessary data.
Do not lazy-load it. Elementor's lazy-load-background-images setting is useful for images further down the page and actively harmful applied to your hero — you're deferring exactly what LCP measures. Most optimisation plugins let you exclude specific images; make sure your hero is excluded.
Preload it if your caching plugin supports preloading the LCP image.
This one step frequently moves an Elementor site from a failing LCP to a passing one, and it takes about ten minutes.
Step 5 — Layer caching on top
Elementor's own optimisations reduce what's generated. A caching plugin stops it being regenerated on every request. You want both.
What helps most on builder sites: page caching, WebP conversion, and CSS/JS minification.
What to be careful with: combining and deferring JavaScript. Builders rely on their JS for sliders, tabs, accordions, and popups, and aggressive deferral breaks these regularly. Enable one setting, then click through every interactive element on the site before enabling the next.
The rule: if your score improved twenty points and your mobile menu stopped opening, you haven't optimised anything.
Should you rebuild in Gutenberg?
Usually not, and the honest comparison matters here.
Gutenberg is lighter. It's core WordPress, produces flatter markup, and doesn't load a separate framework. On a like-for-like page it will generally outperform a builder.
But a rebuild is expensive. You're recreating every page, re-testing every layout, and risking design and content regressions — for a performance gain you can largely achieve through configuration.
When a rebuild does make sense: you were planning a redesign anyway; your site is simple enough that the rebuild is a few days rather than weeks; you're on a very old Elementor structure with heavy addon dependencies; or you've done everything above and still can't pass.
The more useful framing: a well-configured Elementor site beats a badly-configured Gutenberg site comfortably. The builder isn't what's failing your vitals — an unoptimised install with four addon packs and a 3MB hero image is.
Frequently asked questions
Is Elementor bad for SEO?
Not inherently. Elementor produces crawlable, indexable HTML and doesn't prevent proper headings, meta tags, or structured data. Where it can hurt SEO is indirectly, through Core Web Vitals — the framework overhead, nested markup, and addon assets can push LCP and INP outside the passing thresholds if left unconfigured. That's a configuration problem with configuration fixes, not a reason to avoid the builder.
Is Elementor slower than Gutenberg?
Generally yes, on a like-for-like page. Gutenberg is core WordPress, loads no separate framework, and produces flatter markup. But the gap narrows considerably once Elementor's performance features are enabled, addon packs are trimmed, and Containers replace the older Section/Column structure. A well-configured Elementor site comfortably outperforms a badly-configured Gutenberg one.
Can a builder site pass Core Web Vitals?
Yes, and plenty do. It requires deliberate work a default install doesn't do for you: enabling Elementor's performance features, cutting unused addon widgets, flattening nested structure, fixing the hero image, and layering caching on top. The most common single blocker is an oversized or lazy-loaded hero image, which is a ten-minute fix rather than a rebuild.
What to do next
Open Elementor → Settings → Features and see how many performance options are switched off. On most sites installed more than a year ago, several are — and Inline Font Icons alone is often worth a noticeable improvement.
Then count your addon packs and how many widgets you actually use from each. That ratio usually explains most of the remaining weight.
Free: The WordPress maintenance checklist.
Related guides
- WordPress speed: the Core Web Vitals playbook — the full priority order
- How to read a PageSpeed Insights report — finding your LCP element
- WordPress plugin audit — trimming addon packs
- Caching and CDN explained — what to layer on top
Join the Newsletter
Get practical marketing tactics delivered straight to your inbox.
Written by
Muhammad Basim
Related Articles
Transactional Email Services Compared for WordPress
Every one of these services will deliver your password resets. That's not the differentiator. What differs is setup difficulty, what the free tier covers, how good the logs are when something goes wrong, and — the one people never consider until it bites them — whether the service also handles marketing mail, and whether you […]
Contact Form Notifications Not Arriving: Every Cause
Here's the version of this problem that costs the most: it's been happening for months and you don't know. The form says "thank you." The visitor believes they've reached you. You believe nobody's been in touch. There's no error, no bounce, no alert — just an absence, and absences are invisible. Most of the time […]
WooCommerce Order Emails Going to Spam: The Fix
"I never got a confirmation. Did my order go through?" Every store owner gets this message. And when it arrives often enough, you stop treating it as customer confusion and start realising your receipts genuinely aren't landing. This costs more than most email problems, because a missing order confirmation doesn't just annoy someone — it […]