Why Elementor is bad (and when it's fine)

Elementor is the most popular WordPress page builder, and it is responsible for a disproportionate share of the slow, fragile WordPress sites we’re called in to fix or rebuild. That’s not a coincidence.

This is not a hit piece - Elementor is genuinely useful for certain situations. But the problems it causes are real and consistent enough that you should go in with eyes open.

The core problem: code bloat

Elementor works by wrapping every element on your page in nested <div> containers with inline styles. A simple heading-text-button layout that would take perhaps 10 lines of clean HTML can become 80 to 120 lines of Elementor’s markup.

That extra markup:

Increases HTML document size
Adds CSS that gets loaded on every page whether the elements are used there or not
Slows browser parsing and rendering

On a simple brochure site this is a manageable tax. On a site with 50+ pages and heavy use of widgets and global templates, it compounds. We routinely see Elementor sites loading 1–3MB of CSS on page load.

Speed and Core Web Vitals

The bloat directly hits your Core Web Vitals scores - particularly LCP (Largest Contentful Paint) and the overall load time. Elementor adds multiple JavaScript files and stylesheets to every page load, even pages that use none of its widgets.

Elementor has improved this with asset loading improvements in recent versions, but you still need to manually enable them and they don’t always work cleanly with third-party add-ons.

The practical result: a WordPress site built with clean custom code or native Gutenberg blocks will almost always outperform an equivalent Elementor site on PageSpeed Insights, without any extra optimisation work.

SEO issues

Elementor’s popups and dynamic content created in certain widget types do not always appear in Google’s rendered DOM. If you use Elementor popups for important content - navigation, calls to action, key product information - Google may not index it.

The heading widget is also worth watching. Elementor lets you set any visual size independently of the H-tag level, which makes it easy to end up with mismatched visual hierarchy and semantic heading structure. Google reads the heading tags, not the visual size.

Plugin conflicts

Elementor conflicts more than most plugins, particularly with:

Other plugins that enqueue their own version of jQuery
WooCommerce extensions with heavy front-end JS
Caching plugins that aggressively inline or combine scripts
Security plugins that modify script loading

When conflicts happen, they can be difficult to trace and often surface only in specific combinations of plugins, on specific page types.

Lock-in

If you build a site entirely in Elementor and later decide to switch - to Gutenberg, to a custom theme, or to a different page builder - your content does not cleanly transfer. The text and images are there, but your layouts are stored as Elementor shortcodes. You are essentially rebuilding from scratch.

This is not unique to Elementor, but it’s worth factoring in when you’re choosing a builder for a site you expect to maintain long-term.

When Elementor is fine

Short-term landing pages where performance matters less than speed of production, and you plan to rebuild or discard them later
Internal tools or password-protected pages where Google never crawls the content and speed is not a priority
Non-technical clients who need to make layout changes themselves and are comfortable with the Elementor interface - though the native block editor has largely closed this gap

What we use instead

For our own client builds we use the Sage/Roots stack with ACF for content management, or fully custom PHP implementations depending on the project. Clean custom themes, no proprietary builders, no lock-in - and the performance difference is significant.

If you’ve inherited a site built on Elementor and are deciding whether to stay or rebuild, we give honest second opinions - we’ll tell you if it’s worth the migration or not.