Skip to content
ThemesIonic — home
Elementor

Why Elementor Is Slow and How to Speed It Up

Elementor's weight comes from global font and icon loading, nested containers and add-on packs. Trim those, then treat it like any other site: cache, images, scripts.

4 min read intermediate

Start in Elementor's own settings. Several of its performance features are opt-in, and turning them on removes weight from every page before you touch anything else.

Step 1: Elementor's own performance settings

Under Elementor → Settings and Elementor → Settings → Features (labels shift between versions, the options do not):

  • Improved CSS loading / optimised asset loading — loads widget CSS only where a widget is used, instead of one large global file.
  • Inline font icons — stops loading a full icon font when a handful of icons are used.
  • Optimized DOM output — produces less wrapper markup.
  • Element caching — caches rendered widget output where available.
  • Load Google Fonts locally — removes a third-party request from the critical path.
  • Disable Default Colors and Default Fonts, if your theme already defines them, so two systems are not both loading typography.

Enable them one at a time and check the site between each. These change how assets are produced, so purge caches and regenerate CSS afterwards — Elementor → Tools → Regenerate CSS & Data.

Step 2: cut what loads globally

Font Awesome, eicons and Google Fonts are frequently loaded on every page for a site that uses three icons.

  • Set fonts to load locally, and reduce the number of families and weights in Site Settings → Typography. Three weights of one family covers most designs, as how to choose fonts for a website argues.
  • If you use no icons on a template, avoid icon widgets on it entirely rather than trying to unload the library conditionally.
  • Remove widgets from templates that are not visible — a hidden widget still loads its assets.

Step 3: simplify the structure

Elementor builds nested containers, and deeply nested layouts produce large DOMs that are slow to parse and style.

  • Use the newer flexbox or grid containers rather than the legacy section/column structure where available.
  • Flatten nesting: a section inside a column inside a section is usually two levels more than the design needs.
  • Replace a stack of separate widgets with one where possible — a single text editor widget instead of five heading and text widgets.
  • Delete hidden or disabled elements rather than leaving them in the template.

Step 4: audit the add-ons

Widget packs are the largest single cause of slow Elementor sites. Each one registers dozens of widgets, and many load their CSS and JavaScript globally regardless of use.

  1. List every Elementor add-on installed.
  2. For each, identify which widgets you actually use.
  3. Where an add-on is installed for one widget, find a way to remove it.
  4. Where an add-on offers per-widget asset loading, enable it.
  5. Delete deactivated add-ons entirely, per how to delete a plugin completely.

Measure as you go: disable one add-on, load a page, note the request count and total weight. The numbers make the decision for you.

Step 5: the ordinary performance work

Once Elementor's own overhead is under control, the rest is the same as any WordPress site:

  • page caching, configured with correct exclusions;
  • images sized and compressed properly, per how to optimise images;
  • scripts deferred and third-party tags delayed, per render-blocking resources;
  • a current PHP version and object caching where the host offers it.

The full sequence is in how to speed up a WordPress site.

One Elementor-specific caution: be conservative with CSS and JavaScript combination, and with "remove unused CSS". Elementor pages rely on generated per-page stylesheets, and aggressive optimisation strips rules that widgets need — the symptom is in Elementor changes not showing.

Speeding up the editor itself

A slow editor is a different problem from a slow site, because caching never applies to it:

  • reduce the number of installed widget packs — the editor loads them all;
  • raise the PHP memory limit, per how to increase the WordPress memory limit;
  • work on shorter pages; a single page with two hundred widgets will always be slow to edit;
  • check server response time, since the editor makes many admin requests — see how to speed up a slow WordPress admin;
  • disable browser extensions while editing, particularly ad blockers and privacy tools.

Measure honestly

Test one representative page before and after, logged out, in a private window, with the cache warm. Record total page weight, request count and LCP.

A realistic outcome for a bloated Elementor site is a substantial reduction in weight from the steps above. If it is still slow after all of it, the remaining cost is usually a specific add-on or a third-party embed — remove them one at a time and measure, rather than concluding the builder itself is the limit.

Frequently asked

It is heavier than native blocks because it ships its own CSS and JavaScript framework, but a well-configured Elementor site can be fast. Most slow ones are slow because of add-ons and unused global assets.
The editor loads the whole builder plus every registered widget from every add-on. Its speed depends on server response time and the number of installed widget packs, not on page caching.
Only as part of a planned rebuild. Migrating away means rebuilding every page, so it is worth doing for the right reasons, not to save a few hundred kilobytes.

Related guides