Why I moved away from Elementor — and what I’m using instead.

Elementor is one of those tools that feels like the right choice until it isn't. It speeds up the first build. It makes it easy to hand off to a non-technical person for basic edits. And for a single store, at launch, the tradeoffs feel manageable.

But I run a portfolio of stores, not a single store. And after rebuilding the same type of site six or seven times with Elementor, I started noticing a pattern in what went wrong: performance degraded, database tables bloated, updates broke things, and every customisation that had seemed simple at the start had created invisible coupling to the page builder's internal structure.

This is not an Elementor-specific problem. It's a page builder problem. But since most of my stores run on WooCommerce + WordPress, and Elementor is the dominant choice, that's what this is about.

The promise vs. the reality

The pitch for Elementor is visual editing without code. Drag something where you want it. Change the colour. Deploy. For marketing teams and solo founders who aren't developers, this is genuinely valuable.

The reality, once a store has been live for 12 months: every piece of content is locked inside Elementor's JSON data structure stored in the WordPress postmeta table. Switching themes breaks everything. Running the wrong update at the wrong time breaks things. The visual editor accumulates layout debt that nobody ever audits. And the pages that looked clean in the builder serve 400KB of CSS that the visitor's browser has to parse before anything renders.

The performance numbers

I measured three comparable product pages across stores in the same niche: one built with Elementor, one with a custom WooCommerce theme and hand-written templates, one with Kadence blocks (a lighter FSE approach). Same image sizes, same content complexity.

The Elementor page loaded in 4.2 seconds on a simulated 4G connection (GTmetrix, EU server). The Kadence page loaded in 2.1 seconds. The hand-coded template loaded in 1.4 seconds. Page speed score: 54 for Elementor, 79 for Kadence, 91 for hand-coded.

A 4-second load time on mobile e-commerce is not a cosmetic problem. Studies consistently show conversion rate drops of 20%+ for each additional second of load time on mobile. That's margin, not a footnote.

The database bloat problem

Elementor stores its page data as serialised JSON in the wp_postmeta table — specifically in the _elementor_data key. On a site with 50+ products and 10+ landing pages, this table can grow to several hundred megabytes of data that has to be queried on every page load. Revisions compound this: WordPress keeps a draft of every version, and Elementor creates a revision for every auto-save.

On one of my older stores I found 47,000 rows in wp_postmeta attributed to Elementor revisions. The table was 1.8GB. Queries that should have taken 20ms were taking 300ms. The solution (automated revision cleanup, manual table optimisation) worked — but it was a problem that shouldn't have existed.

What I use now

For new WooCommerce stores, I'm using a combination of:

• Kadence theme + Kadence Blocks for the overall layout and marketing pages — FSE-compatible, significantly lighter than Elementor, and the block output is clean HTML.
• Custom PHP templates for product pages, category pages, and checkout — things that are performance-critical and where I want full control. These are straightforward if you're comfortable with WooCommerce's template hierarchy.
• ACF (Advanced Custom Fields) for any content that needs a structured editing interface — product specifications, comparison tables, custom fields. Clean, database-efficient, and the data structure survives a theme change.

For marketing landing pages where a non-technical person needs to make edits, I use Kadence blocks in the Gutenberg editor. The visual editing is good enough, the output is clean, and I'm not locked into a proprietary data format.

The migration path

If you have an existing Elementor site and want to move away from it, the honest answer is: don't migrate everything at once. The practical path that's worked for me:

1. Start with new pages. Any new page that gets created from now on uses the new approach. This prevents the problem from getting worse.
2. Prioritise high-traffic pages. Identify your top 10 pages by traffic and rebuild those first. This is where performance gains matter most.
3. Archive, don't delete. When you rebuild a page, keep the Elementor version as a private draft. You can reference it if something was missed.
4. Clean up the database after deactivating. Once Elementor is deactivated, run a cleanup query to remove the orphaned postmeta rows. Or use a plugin like WP Rocket or WP-Sweep.

When Elementor is still fine

I want to be honest about this: Elementor is fine for single stores where you need fast iteration, where a non-technical person is making content edits regularly, and where the site isn't going to scale to a large product catalogue. If you're testing a concept and speed to launch matters more than load speed, a page builder is a sensible choice.

The problem is treating it as a permanent foundation rather than a starting point. It's a tool for speed, not a tool for scale. Know which one you need before you choose.