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.
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.
- List every Elementor add-on installed.
- For each, identify which widgets you actually use.
- Where an add-on is installed for one widget, find a way to remove it.
- Where an add-on offers per-widget asset loading, enable it.
- 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.