If you've searched this, you've probably already tried a caching plugin, compressed your images, and maybe moved to a "faster" host. The score went up for a fortnight and then drifted back down.
That pattern is the actual symptom. It's worth understanding why it happens, because it determines whether your site needs an afternoon of tuning or something more serious.
Here's the short version: most Elementor sites can be made meaningfully faster without rebuilding anything — often by changing settings you already own. But there's a ceiling, it's lower than people expect, and once you hit it no plugin gets you past it. This article covers both: how to get everything available to you, and how to recognise when you've run out of road.
First, measure it properly
Before changing anything, get a real number. Most people are optimising against the wrong metric.
Run your homepage and one interior page through PageSpeed Insights. When it loads, look at the top section — Discover what your real users are experiencing — not the performance score underneath it.
That top section is field data: measurements from actual Chrome users on your actual site. The score below is lab data from a simulated device, and it swings wildly between runs. Field data is what Google uses.
You're looking at three numbers:
- LCP (Largest Contentful Paint) — how long until the main content appears. Good is under 2.5 seconds. Over 4 seconds is poor.
- INP (Interaction to Next Paint) — how long the page takes to respond when someone taps something. Good is under 200ms.
- CLS (Cumulative Layout Shift) — how much things jump around while loading. Good is under 0.1.
Check the mobile tab. Australian small business traffic skews heavily mobile, and mobile is where Elementor sites struggle most — desktop numbers routinely look fine while mobile is failing.
If the field data section says there isn't enough data, your site doesn't get sufficient traffic for Google to have collected it. Use the lab score as a rough guide instead, but run it three times and take the middle result.
Write your numbers down. You need the before, or you can't tell whether anything you do afterwards actually worked.
Why Elementor sites get slow
Four causes, in roughly the order they matter.
1. It ships CSS and JavaScript for widgets you never used
This is the big one. Elementor is a general-purpose builder, so out of the box it loads its full frontend stylesheet and JavaScript bundle on every page — plus icon fonts, plus jQuery, plus its animation library. A page containing nothing but a heading and a paragraph still loads the machinery required to render carousels, accordions, countdown timers and forms.
Newer Elementor versions are considerably better at this than older ones, and there are settings that improve it further. Most sites have never turned them on.
2. The HTML is deeply nested
A single Elementor section typically renders as a container, inside a section, inside a column, inside a widget wrapper, inside the widget itself — five or six levels of nested divs to display one heading. Multiply that across a full page and you get a large DOM.
A large DOM costs you twice: the browser spends longer building and styling it, and every subsequent interaction costs more to recalculate. This is a common contributor to poor INP scores, and it's largely inherent to how builders work.
3. The plugin stack grew
Elementor sites accumulate plugins, because the builder makes it easy to solve each new problem by installing something. A slider addon here, a forms extension there, a widget pack for one page. Each one loads its own CSS and JavaScript — usually site-wide, whether or not the current page uses it.
Thirty plugins is not unusual. Most of them load on every single page view.
4. Images and fonts were never dealt with
Not Elementor's fault, but it's where the largest easy wins usually sit. An uncompressed hero photo straight off a phone camera is frequently the single biggest thing on the page, and web fonts loaded from Google's servers block rendering while the browser waits for them.
What to fix first (free, and often substantial)
Work through these in order. Take a new measurement after each one so you know what's actually helping.
1. Turn on Elementor's own performance features. Go to Elementor → Settings → Performance (in older versions these live under Experiments). Depending on your version you'll find options such as Improved Asset Loading, Improved CSS Loading, Inline Font Icons, Optimized DOM Output, and Lazy Load Background Images.
These exist specifically to address cause #1, and on a site that has never touched them the improvement can be significant. Enable them one at a time and check the site afterwards — occasionally an older third-party addon depends on the legacy behaviour and something breaks visually. That's exactly why you enable them one at a time.
2. Audit your plugins honestly. List every active plugin and ask what it does that you'd actually miss. Deactivate anything you can't answer for, then check the site still works. Pay particular attention to widget packs and addon bundles — a pack installed for one widget on one page is loading its whole library everywhere.
3. Fix your images. Resize them to the dimensions they're displayed at, convert to WebP, and make sure everything below the fold is lazy-loaded. Your hero image should be the exception: it wants preloading, not lazy-loading, because it's usually the LCP element and lazy-loading it directly harms the metric.
4. Host your fonts locally. Loading fonts from Google's servers means an extra DNS lookup and connection before any text renders. Serve them from your own domain and preload the one or two weights you actually use. While you're there, count how many weights you're loading — most sites load six and use two.
5. Caching and a CDN, in that order. A page-caching plugin so WordPress isn't rebuilding pages on every request, and a CDN so Australian visitors aren't fetching assets from a server in another hemisphere. If your host is in the US and your customers are in Melbourne, that's a real and measurable penalty on every asset.
6. Then reconsider your hosting. Cheap shared hosting genuinely does throttle you, but do it in this order — moving a bloated site to a faster host makes a bloated site load slightly sooner, which is a much smaller win than people expect and considerably more expensive than the five steps above.
The ceiling
Do all of that properly and most Elementor sites land somewhere respectable. Plenty end up passing Core Web Vitals, and if yours does, you're finished — stop here and spend the money on something else.
Some don't. If you've genuinely worked through the list and mobile LCP is still sitting above 3 seconds, you've likely hit the structural limit, and it's worth understanding what that limit is made of:
- The framework loads regardless. You can trim what Elementor ships, but you can't get to zero. A hand-built page starts from nothing and adds only what it needs; a builder page starts from the builder.
- The DOM depth is inherent. It's how the visual editor works. Optimised DOM output helps, but a builder-rendered page will always carry more structure than a purpose-built one.
- Every page is assembled on request. WordPress queries the database and renders PHP each time. Caching hides this well until something changes and the cache clears.
- It drifts back. This is the part people find most frustrating. You optimise, it improves, then over six months someone adds a plugin, uploads an unoptimised image, or an update changes what loads — and you're back. Speed on a builder site is maintenance, not a state you achieve.
For a great many businesses that is completely fine. A local service business with eight pages and steady enquiries does not need to escape any of this.
The three honest options
If tuning hasn't got you there, you have three routes, and the cheapest one is genuinely the right answer more often than agencies like to admit.
Keep tuning — if the gap is small
If you're at 3 seconds and need 2.5, keep going. Targeted work on your specific bottleneck is far cheaper than any rebuild, and hiring someone for a day of focused optimisation will cost a fraction of the alternatives. Our guide to page speed and SEO covers what genuinely moves the needle, and what Core Web Vitals actually measure explains the metrics in more depth.
Rebuild lean on WordPress — if you like WordPress and the site is straightforward
You can stay on WordPress and drop the builder. A well-built lightweight theme, no page builder, and a disciplined plugin list produces a genuinely fast WordPress site. Your team keeps the admin they know, the cost is moderate, and for a brochure or small service site this is frequently the best value on the table.
The trade-off is that layout changes need a developer rather than a drag-and-drop editor. If your marketing team rearranges pages weekly, that matters. If nobody has touched the layout in two years, it doesn't. A lean WordPress build is the right recommendation for a lot of sites, and we'd rather quote one than oversell you.
Move the front end to Next.js — if the site earns real money and the ceiling is costing you
If your site drives significant revenue, you've done the work, and it's still not fast enough, the remaining option is to change what renders it. Pages get pre-rendered and served as static files, so there's no database query and no PHP execution when a visitor arrives — which is a different performance category, not an incremental improvement.
You can do this while keeping WordPress. In a headless setup your team keeps writing in the same editor, and only the public front end changes — see headless WordPress with Next.js for how that works in practice, or our WordPress to Next.js migration page for the process and how rankings are protected through the cutover.
Be clear-eyed about the cost: it's a genuine rebuild. Elementor layouts don't convert to React automatically, whatever anyone tells you — they get rebuilt as components. That's the real work, and it's also the reason the result is fast.
How to decide
A rough guide:
- Under 10 pages, modest traffic — tune it. A rebuild will not pay for itself.
- Tuning got you close — finish the tuning. The last 20% is cheaper than the alternatives.
- You like WordPress, the site is simple, the builder is the bottleneck — lean WordPress rebuild.
- The site is central to revenue, you've hit the ceiling, and speed is costing you conversions — migration is worth costing out.
- You're rebuilding anyway for other reasons — decide the platform now rather than rebuilding twice.
The question that settles it is not "is Elementor slow". It's what is the slowness costing you. If you can't quantify that, the answer is almost certainly to tune what you have and spend the money somewhere it earns more.
Get an honest read on yours
If you'd like a straight answer without a sales process, send us your URL. We'll come back with your real field data, what's specifically causing the drag on your site, and which of the three options above we'd actually recommend — including "leave it alone", which is a genuine outcome and one we give regularly.
Get a free performance audit — no cost, no pitch deck.