"Elementor makes my site slow" is one of the most common complaints in WordPress circles, and it's usually only half right. Elementor adds overhead — every page builder does, because it trades some performance for the ability to design visually without touching code. But on almost every slow Elementor site I've looked at, the builder itself is a minority contributor. The bigger costs are a handful of ordinary WordPress problems that would slow the site down with or without a page builder in the mix, and that are genuinely straightforward to fix once you know where to look.
This is the order I'd actually work through it in — roughly biggest, easiest win first — not an exhaustive settings dump.
1. Check the PHP version before anything else
This is the fix people skip because it doesn't feel like a "performance" change, but it's usually the highest-leverage thing on this list. Every major PHP release since 7.0 has brought real execution-speed improvements, and a lot of shared and legacy hosting still defaults sites to an old version for compatibility reasons. Check what's currently within php.net's supported window — at the time of writing that's PHP 8.3 and 8.4 — and if your plugins are reasonably current, switching is close to a free win: no code changes, no redesign, just a setting in your hosting control panel (or a quick support ticket). Running an end-of-life version isn't just slower, it's also no longer getting security patches, so this one's worth checking even on a site that feels fast enough.
While you're there, confirm opcache.enable is on. OPcache caches compiled PHP bytecode between requests instead of recompiling every file on every page load — most managed WordPress hosts enable it by default, but budget shared hosting doesn't always.
2. Check Elementor's Experiments panel for anything still off
Elementor's biggest performance wins of the last few years — trimming the redundant wrapper divs it used to add around every widget, and loading CSS more selectively instead of one large stylesheet covering every widget it knows about, used or not — have already graduated from opt-in experiments to standard behavior on current versions. You don't need to go find a toggle for them on a reasonably new install. Where this still matters is a site that's been running the same install for years without updating: open Elementor → Experiments in the admin sidebar and check nothing performance-related was left switched off back when it was still a "try at your own risk" feature. Lazy Load Background Images is worth confirming either way — it defers offscreen section backgrounds rather than requesting all of them upfront, and isn't universally on by default.
If you do flip anything here, test the page afterward rather than assuming — a heavily customized theme or an old third-party widget pack occasionally assumed the older behavior.
3. Stop loading Google Fonts from a third-party origin
By default, Elementor (and a lot of WordPress themes) request Google Fonts directly from fonts.googleapis.com on every page load — a separate DNS lookup and connection the browser has to make before it can render text in that font. Elementor's Settings → Advanced → Google Fonts → Load Google Fonts Locally option downloads and self-hosts the fonts your design actually uses instead, removing that third-party round trip entirely. If you're on a handful of font weights, this alone is often a noticeably faster First Contentful Paint.
4. Fix images before you touch anything else visual
Images are the single largest payload on almost every WordPress page, and the default media library upload rarely ships something appropriately sized. Three things matter, roughly in order:
- Serve the size the layout actually needs. A hero image doesn't need to ship at the same resolution on a 360px phone screen as a 1920px desktop — WordPress generates responsive
srcsetsizes automatically from its registered image sizes, but only if the theme/builder is set up to use them, and only if you upload a large enough original in the first place. - Use a modern format. WebP (or AVIF where support allows) at the same visual quality is routinely 25–50% smaller than the JPEG or PNG most site owners upload straight from a phone or a stock photo site.
- Lazy-load anything below the fold. WordPress core has lazy-loaded images by default since 5.5, but double-check it isn't being disabled by a plugin, and make sure the one or two images actually in the first viewport are excluded from lazy loading — lazy-loading your Largest Contentful Paint image is a common self-inflicted regression.
5. Add a real caching layer
WordPress rebuilds a page from PHP and database queries on every single request unless something is caching it. A page cache — either at the server level if your host provides one (most managed WordPress hosts do), or via a well-regarded caching plugin otherwise — serves a pre-built static version of the page to anonymous visitors instead of re-running that whole pipeline every time. For anything with dynamic, per-user content (carts, logged-in dashboards), pair it with an object cache (Redis or Memcached) so the repeated database lookups behind that dynamic content don't hit MySQL directly on every load either.
6. Clean up the database and the plugin list
Two boring, unglamorous causes that add up more than people expect:
- Post revisions and expired transients accumulate in the database indefinitely by default. A site that's been live for a few years with no cleanup can easily carry tens of thousands of rows nobody will ever read, which makes every query against those tables marginally slower. A cleanup plugin (or a careful manual pass) run every few months keeps this from creeping back up.
- Overlapping plugins — two SEO plugins, two caching plugins, an old page builder's assets still enqueuing after you switched to Elementor — are more common than they should be. Every active plugin gets a chance to hook into the page load; an audit that removes the ones doing nothing (or duplicating something another plugin already handles) is often worth more than any single optimization setting.
Measure one change at a time
The order above is a reasonable default, but the honest answer is: run a Lighthouse or PageSpeed Insights pass before you start, change one thing, measure again, and keep what actually moved the number. Stacking five changes at once and re-measuring tells you the combined effect was positive or negative — it doesn't tell you which one did the work, which matters the next time you're debugging a different site that doesn't share the same bottleneck.
Page builders and performance aren't actually in conflict. Most "Elementor is slow" complaints are really "this WordPress install hasn't been maintained," and every fix above applies whether or not a page builder is involved at all.