“We built it in Elementor and now it’s slow” is one of the most common messages I get. Almost every time, Elementor is the least of the problems. The site has three addon packs, a slider loading on every page, a 4 MB hero image and no working cache — and the builder takes the blame because it is the thing the owner can see. An Elementor website slow enough to lose visitors is usually slow for those reasons, and the fixes below are the ones that move the numbers.
This is the Elementor-specific list. For the general WordPress work (hosting, caching, database), read the WordPress speed optimization checklist first; the two together are what I actually do on a rescue job.
First, find out what is slow
Run the home page and one inner page through PageSpeed Insights on mobile. Then open the browser’s Network tab, reload, and sort by size. In five minutes you will know whether the problem is images (usually), scripts from addons (often), fonts (sometimes), or the server (occasionally). Fix in that order.
The ten fixes
-
Switch on Elementor’s own performance features.
Go to Elementor → Settings → Features and enable the optimised markup, inline font icons (icons as SVG instead of loading a whole icon font), and flexbox containers if the site was built with them. In the Performance tab, set the CSS print method to External file so styles can be cached, and turn on lazy loading for background images. These are free wins that older sites often have switched off.
-
Remove addon packs you use one widget from.
Essential Addons, Element Pack, Premium Addons and friends each load CSS and JavaScript for dozens of widgets. If you use two widgets from a pack of eighty, you are paying for eighty. Rebuild those two with core Elementor or Pro widgets (which cover most needs now) and delete the pack. This is usually the single biggest script saving on an Elementor site.
-
Stop the slider.
Hero sliders load a carousel library, several large images and their animation scripts before anything else — and visitors rarely see slide two. Replace with one strong image and a headline. If you truly need a carousel, keep it below the fold where lazy loading helps.
-
Fix the images (again, because it is always the images).
Elementor uses the image size you choose in the widget. Choose an appropriate one — “medium_large” for a card, “large” for a content image, “full” only for a genuine full-width hero — rather than defaulting to full everywhere. Convert to WebP. Set the hero image to load eagerly with high fetch priority, and everything else lazily. A site I converted recently went from 415 MB of PNG screenshots to 32 MB of WebP with no visible change.
-
Self-host and trim fonts.
Elementor loads Google Fonts for every family and weight used anywhere in the kit. Audit the kit’s global fonts: two families, three or four weights, no more. Then self-host them (Elementor has a setting to stop loading Google Fonts once you provide your own via the theme) and preload the heading font. Fewer fonts also means less layout shift.
-
Use the Theme Builder, not a plugin, for header and footer.
Sites that combine an Elementor header with a theme header, or a third-party header plugin, load two of everything. One Theme Builder header, one footer, conditions set to “entire site”. Remove the alternatives.
-
Regenerate CSS after every big change and cache it.
Elementor writes one CSS file per page. After changing global styles, run Elementor → Tools → Regenerate CSS & Data, then make sure your cache plugin serves those files with long expiry headers. Stale or missing CSS files force Elementor to print styles inline on every load, which is slower and uncacheable.
-
Defer the third-party scripts.
Chat widgets, pixels, maps and video embeds should load after the page is interactive. Use the caching plugin’s delay-JavaScript feature or Tag Manager, and use a click-to-load facade for YouTube. Each deferred script improves Interaction to Next Paint, which is now a ranking signal.
-
Kill layout shift.
The “page loads wrong, then corrects itself” effect is Cumulative Layout Shift, and Elementor sites are prone to it: accordions that expand after load, image widgets without dimensions, fonts swapping late, sections whose height depends on JavaScript. Set widths and heights on images, give late-loading sections a minimum height, preload the headline font, and check the page with the Performance panel’s layout-shift regions highlighted. This one fix often moves the mobile score by ten points.
-
Audit what loads on pages that do not need it.
Open a simple inner page and look at the Network tab. If you see form scripts, popup scripts and carousel CSS on a page with none of those, something is loading globally. Elementor Pro loads most widget assets conditionally; addons and older plugins often do not. This is another argument for fix number two.
What to expect from each fix
| Fix | Typical gain | Risk |
|---|---|---|
| Elementor performance settings | Small–medium; more with icon fonts removed | Low; check icons still show |
| Remove addon packs | Large on script weight and INP | Medium; widgets must be rebuilt |
| Replace slider with static hero | Large on LCP | Design decision |
| Image sizes + WebP + eager hero | Largest on LCP | Low |
| Self-hosted, trimmed fonts | Medium on LCP and CLS | Low |
| Deferred third-party scripts | Large on INP | Low; test forms and chat still work |
| Layout-shift fixes | Large on CLS | Low |
Things people try that do not help
- Installing a second optimisation plugin on top of the first. They fight, and the site gets slower and stranger.
- “Unused CSS removal” tools applied blindly. They regularly strip styles Elementor needs on hover or on mobile. Test every page if you use one.
- Combining all JavaScript into one file. With HTTP/2 this can delay the first paint. Minify; do not blindly combine.
- Switching themes. Hello Elementor is already minimal. The theme is rarely the bottleneck.
The order I do it in on a rescue job
Images and hero first (largest gain, lowest risk). Fonts second. Then Elementor settings and CSS regeneration. Then the addon audit, which is the slow, careful part. Then deferred scripts and layout shift, with a test of every form and interactive element afterwards. Then hosting and caching from the general checklist if the server is the remaining problem. The whole thing is usually one to two days, and it is much cheaper than a rebuild.
Measure before and after on the same page, same device setting. Lab scores move around; keep the comparison fair. Then check the field data a month later to confirm real visitors felt the difference.
Further reading: Elementor Help Center · PageSpeed Insights.
FAQ
Is Elementor slower than other page builders?
Out of the box it loads more CSS and JavaScript than a plain theme, but a well-built Elementor site reaches good Core Web Vitals. Most slow Elementor sites are slow because of addon packs, unoptimized images and missing caching, not the builder itself.
Should I switch from Elementor to a lighter builder to fix speed?
Rarely worth it. Rebuilding a whole site costs far more than applying the fixes in this article, and the same mistakes will slow any builder. Switch only if the site needs a redesign anyway.
Which Elementor settings improve performance?
In Elementor → Settings → Features, enable the optimised markup and inline font icons options, use flexbox containers, and keep only the features you use. In the Performance tab, enable CSS print method “external file” and lazy-load background images.
Why does my Elementor site load, jump, then settle?
That is layout shift: images without dimensions, fonts swapping late, accordions or sliders rendering after the page. Give every image a size, preload the heading font, and set fixed heights or minimum heights on elements that load late.
Slow Elementor site and no time to work through the list? Request a free speed audit — I will tell you which three of the ten are costing you the most, with numbers, before any work starts.
