M
marc dumont ·
Menu
Status
Available for new work
Working with
🇬🇧 UK · 🇺🇸 US · 🇪🇺 Europe
13+y in web development
Elsewhere
© 2026 Marc Dumont
Blog · Elementor

Elementor without the bloat

Elementor has a reputation for slow, bloated sites. Most of the reasons are real, and most of them are also fixable. Here's how I build with it without producing the sites people complain about.

The honest version

If you've heard that Elementor is bad for performance, what you've heard is half-true.

It's true that Elementor sites can be slow. They can load too much CSS, too much JavaScript, and ship widgets to pages that don't need them. They can produce pages with thirty stacked nested containers where five would do. They can be the visible reason Google flags your site as failing Core Web Vitals.

It's also true that the platform isn't the cause. Elementor in 2026 is a more capable, more performance-aware tool than it was in 2018, and a well-built Elementor site is faster than a poorly-built custom theme any day. The issue isn't Elementor. The issue is that Elementor lowers the floor on who can build a WordPress site, and most of the bad reputation comes from sites built by people who didn't know what they didn't know.

A few things have to be true for an Elementor site to be fast:

  1. The theme it's running on is light
  2. The widgets are scoped to the pages where they're needed
  3. The settings that matter are turned on (and the settings that hurt are turned off)
  4. The build avoids known anti-patterns
  5. Caching, image optimisation, and CDN are configured properly

That's a list any working developer can get through. Most don't. This post is a walkthrough of all five.


1. Start with a light theme

The single biggest decision on an Elementor build is the theme it runs on. The theme decides how much CSS and JavaScript loads on every page before Elementor even gets involved.

The good options:

  • Hello Elementor — Elementor's own minimal theme, designed to do as little as possible. Fewer than 6KB of CSS by default. This is what I use for almost every Elementor build.
  • GeneratePress or Astra — slightly heavier than Hello Elementor but offer more out-of-the-box layout control. Worth it if the design needs structural elements outside Elementor's reach.
  • Blocksy — a more recent option, light and well-built.

The bad options are the ones that come with their own page builder, their own theme options panel, their own animation library, and a couple of megabytes of opinionated CSS that fights with Elementor for control of your layout. Multipurpose themes like Avada or BeTheme fall in this category. Combining one of those with Elementor produces sites that load like brochures from 2014.

Quick check: load your site in an incognito browser, open DevTools, and look at the Network tab. If the theme is shipping more than ~30KB of CSS on a basic page, the theme is the problem before any of Elementor is.


2. Scope widgets to where they're needed

By default, Elementor doesn't load widget code on pages where the widget isn't being used. That's fine. What gets you into trouble is third-party widget add-ons (Crocoblock, Stackable, Essential Addons, Premium Addons) which often don't scope their assets, and load their entire library on every page even if you've used one of their widgets once on the homepage.

The audit:

  • Open Chrome DevTools, Network tab on a typical page
  • Reload
  • Sort by file size
  • Anything in the top ten that isn't being used on the page is a candidate for scoping or removal

The fixes:

  • Asset CleanUp or Perfmatters — both let you disable specific scripts and styles on specific pages
  • Replace heavy add-on packs with native Elementor widgets wherever possible. Native widgets are scoped properly out of the box
  • Audit add-on packs ruthlessly — if you're using three widgets from a 60-widget pack, that pack is shipping 57 widgets you don't need

This is the area where most existing Elementor sites have the biggest wins available, and it's the area that takes the most patience. Configuration is fast; the thinking about which scripts can safely be disabled where is what takes the time.


3. Turn on the settings that matter

Elementor has improved its built-in performance features significantly in recent versions. Most of them are off by default, or hidden behind feature flags. The ones to turn on:

text
Elementor > Settings > Features > Optimised Asset Loading: ON
Elementor > Settings > Features > Improved Asset Loading: ON
Elementor > Settings > Features > Improved CSS Loading: ON
Elementor > Settings > Features > Inline Font Icons: ON
Elementor > Settings > Performance > Lazy Load Background Images: ON
Elementor > Settings > Advanced > Google Fonts Load: SWAP

Most existing Elementor builds I take over have at least three of these turned off. Each one delivers measurable gains, often without changing anything visible about the site.

The official Elementor documentation on these is at elementor.com/help/performance-features and is worth reading once, even if you're not the one configuring the site.


4. Avoid the anti-patterns

Some Elementor patterns produce slow pages no matter how well the rest of the site is configured. The ones to avoid:

Each one in slightly more detail:

  • Heavy nested containers — five layers deep when two would do. Renders slowly, edits slowly, breaks unpredictably on smaller screens.
  • Background videos as hero elements — an autoplay video as the first thing a visitor sees turns a 200KB hero into a 12MB hero. If you absolutely must have one, optimise it heavily and use a lightweight poster image as the LCP target.
  • Sliders / carousels for every section — sliders are the heaviest element type Elementor produces. One slider on a homepage is fine. Five is a problem.
  • Custom CSS pasted widget-by-widget — instead of one consolidated stylesheet. Hard to maintain, harder to override, slow to load.
  • Animated entrance effects on every element — the "fade in on scroll" pattern multiplied across forty elements per page. Each one requires JavaScript, a layout calculation, and a paint. Use sparingly.
  • Multiple icon libraries simultaneously — Font Awesome 4 and Font Awesome 5 and the Elementor icon library and an add-on icon library. Pick one.

Avoiding these isn't sophisticated work. It's just a discipline about what to skip.


5. Stack the rest sensibly

Beyond Elementor itself, the standard performance stack applies:

  • Caching plugin: I usually use WP Rocket or LiteSpeed Cache. Either handles CSS minification, JS deferral, and HTML caching with sensible defaults.
  • CDN: Cloudflare for almost every project, with their image optimisation and minification features turned on.
  • Image optimisation: ShortPixel or Imagify for automatic conversion to WebP and AVIF, plus on-upload compression.
  • Hosting: a managed WordPress host (Kinsta, WP Engine, Cloudways with the right config) makes a measurable difference. The cheapest shared hosting is rarely worth it for a serious site.

If you're curious about the broader picture of WordPress performance, the related post What actually slows down a WordPress site goes deeper on the diagnostics side.


Should you use Elementor at all?

This question gets asked often, usually by someone who's been told Elementor is the wrong choice. The honest answer:

Elementor is the right choice when:

  • The client wants editability without depending on a developer for every change
  • The design is layout-driven and benefits from visual building rather than code
  • The site needs to be maintained by a non-technical team
  • Budget or timeline doesn't justify a fully custom theme

Elementor is the wrong choice when:

  • The design has unusual structural requirements that fight with Elementor's container model
  • The site has high performance requirements where every kilobyte matters (a custom theme on Bedrock with Sage will always be faster, given enough budget)
  • The client has an internal development team who'll maintain the site at code level

For most clients I work with, the first list applies. They want a site they can actually edit. They want their team to be able to add a new page or update copy without a support ticket. Elementor delivers that, and with the discipline above, it does so without paying for it in performance.


When to bring someone in

A well-built Elementor site is faster than 90% of the sites people complain about. If your existing Elementor site is slow, the cause is one of the five things above, and finding which is part of the diagnostic work.

If you're starting fresh, the bespoke WordPress development service is where most of my Elementor builds happen.

If you've got an existing Elementor site that needs the bloat removed, the performance service is the right one. Often the audit takes a day, the fixes take a couple of weeks, and the difference is significant.

Either way, get in touch and we can figure out what shape the work is.


Further reading

Keep reading

All articles →
Stay in touch

More posts.

Read more articles →
WordPressElementorWooCommerceLong-term partnershipsTransparent hourly pricingWordPressElementorWooCommerceLong-term partnershipsTransparent hourly pricing