A slow Elementor site is rarely one big problem. It is usually eight small ones stacked on top of each other, and the page builder gets blamed for all of them. We clean up Elementor performance for clients most weeks, and the same handful of causes come up again and again.
This is the order we actually work in, from the fixes with the biggest payoff to the ones worth doing last.
Measure before you touch anything
Run the page through PageSpeed Insights and look only at the field data at the top if it exists. That is real Chrome user data. The lab score underneath is a simulation on a throttled mid-range phone, and chasing it to 100 will waste days.
You are looking at three numbers:
- LCP (Largest Contentful Paint) should be under 2.5 seconds. On almost every Elementor site this is the hero image or hero heading.
- INP (Interaction to Next Paint) should be under 200ms. High INP on Elementor usually means too much JavaScript, often from sliders, popups or animation libraries.
- CLS (Cumulative Layout Shift) should be under 0.1. Nearly always caused by images without dimensions, or web fonts swapping in.
Write the three numbers down. If you do not, you will not know which of the changes below actually helped.
Fix hosting and caching first
This is boring and it is also where most of the win is. A well-optimised Elementor site on bad shared hosting will still feel slow, because time-to-first-byte is already burning half your budget before a single pixel renders.
Check your TTFB
If server response time is over 600ms, no amount of image compression will save you. Common causes are an overloaded shared server, no object cache, PHP 7.x still running, or a bloated plugin doing database work on every page load.
Get a real caching setup
Page caching, GZIP or Brotli compression, and a CDN in front. Any of the mainstream caching plugins will do this. What matters more is that you configure it and then test, rather than installing three caching plugins that fight each other, which we see constantly on rescue jobs.
Move to PHP 8.2 or newer
Free performance. Check your plugins are compatible, take a backup, switch it in your host panel. Sites still sitting on PHP 7.4 are leaving a meaningful chunk of server-side speed on the table.
Cut what Elementor loads on every page
Elementor ships a lot of CSS and JS by default, and a stock install loads much of it whether the page uses it or not.
Turn on the performance experiments
In Elementor → Settings → Features, enable Improved Asset Loading, Improved CSS Loading, Inline Font Icons and Optimized Control Loading. These stop Elementor loading widget assets on pages that do not use them. Test the site afterwards, because Inline Font Icons occasionally breaks icons in older third-party widgets.
Disable Google Fonts and Font Awesome if you are not using them
Under the same settings screen you can switch off Elementor’s default font loading. If your theme already loads your typefaces, Elementor loading its own copies is pure waste.
Audit your third-party Elementor addons
This is the big one nobody wants to hear. Many sites have three or four addon packs installed to use two widgets. Each pack loads its own CSS and JS bundle sitewide. Pick one, rebuild the two or three widgets you actually need, and delete the rest. On one recent cleanup this alone cut about 400KB of render-blocking assets.
Fix your images, which are almost certainly the LCP problem
On the majority of Elementor sites we audit, the hero image is a 2MB PNG exported straight from a design tool and dropped into a section background.
- Serve WebP or AVIF. Any decent image optimisation plugin will convert and serve these automatically.
- Size images to the container. A 3000px-wide file rendering in an 800px column is wasted bandwidth on every single visit.
- Never lazy-load the hero. Lazy loading the LCP element delays it by definition. Exclude the hero image and logo in your optimisation plugin’s settings.
- Set explicit width and height so the browser reserves the space. This is the single most common CLS fix.
- Background images in Elementor sections are not lazy-loaded and are not preloaded either, which is why hero backgrounds so often hurt LCP. Consider using a real image widget with a preload hint instead.
Tame fonts and third-party scripts
Two or three font families at four weights each is four to twelve font files. Cut to two families, two weights each, host them locally, and add font-display: swap so text renders immediately in a fallback rather than staying invisible.
Then look at what else is on the page. Chat widgets, heat-map tools, analytics, pixels, review widgets and embedded maps all cost you. Load the non-critical ones on interaction or on scroll rather than immediately. An embedded Google Map in the footer can pull in several hundred kilobytes of JavaScript on every page view; a static map image linking to Maps costs almost nothing.
When it is still slow after all that
If you have done everything above and the numbers still will not move, the problem is usually structural rather than a setting:
- A page built with dozens of nested containers and sections, where the DOM itself is the bottleneck.
- A slider or animation library running on the hero and blocking interaction.
- A plugin querying the database on every page load without caching, common with booking, directory and multi-currency plugins.
- A theme that is fighting Elementor rather than getting out of its way.
At that point rebuilding the critical templates cleanly is usually faster and cheaper than continuing to patch. That is a judgement call, and it is worth getting a second opinion before committing either way.
If you would rather hand this over, speed optimisation is one of the things we do, and you can tell us what you are seeing and get an honest read on whether it is a config problem or a rebuild.
Frequently asked questions
Does Elementor make a WordPress site slow?
Elementor adds more CSS and JavaScript than a hand-coded theme, but on its own it is not what makes most sites slow. In practice the bigger causes are cheap hosting, unoptimised images, several addon packs loading sitewide, and too many third-party scripts. A properly configured Elementor site can comfortably pass Core Web Vitals.
What is a good PageSpeed score for an Elementor site?
Aim to pass Core Web Vitals rather than to hit a specific score: LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1. A mobile lab score in the 70s that passes field data is worth more than a 95 that does not.
Will a caching plugin fix my slow Elementor site?
It will help, often significantly, but it will not fix oversized images, duplicate addon packs or a slow server. Caching reduces how often the work is done; it does not reduce how much work there is. Installing more than one caching plugin usually makes things worse.
Should I switch from Elementor to something else for speed?
Usually not. Migrating a site is expensive and risky, and most Elementor performance problems are fixable in configuration and asset management. Switching is worth considering only when the site is already being rebuilt for other reasons.