Elementor has a reputation problem. Mention it in any performance thread and someone will tell you page builders are “slow by design.” I’ve built and audited enough Elementor sites to call that lazy thinking — the builder isn’t slow, undisciplined building is. If you want to speed up Elementor, the fixes are concrete, measurable, and mostly built into Elementor already. Most Elementor sites I work on jump from a 60s PageSpeed score into the 90s after these changes, without losing a single design element.
Why Elementor Sites Get Slow (It’s Not the Builder)
Elementor pages carry more weight than hand-coded templates for four predictable reasons:
- Extra markup. Classic Sections and Columns wrap content in layers of nested divs — a section, an inner container, a row, a column wrapper — before your content even starts.
- All-widget assets. Without its performance features on, Elementor can load CSS and JavaScript for widgets you never used on that page.
- Unoptimized media. Massive PNGs uploaded straight from a camera roll, full-screen background sliders, no lazy loading.
- Addon sprawl. Third-party Elementor addon packs that load their own scripts on every page, even the ones that don’t use them.
Fix those four and Elementor stops being the bottleneck. Your hosting and caching still matter — but that’s true for every WordPress site, not just Elementor ones.
Step 1 — Switch On Elementor’s Built-In Performance Features
This is the step almost everyone skips. Go to Elementor → Settings → Features and make sure these are active:
- Flexbox Container — replaces Sections and Columns with a single container element, cutting DOM nodes by roughly a third.
- Optimized DOM Output — strips redundant wrapper divs from the HTML Elementor generates.
- Improved CSS Loading — loads a widget’s CSS only on pages that actually use that widget.
- Improved Asset Loading — the same idea for JavaScript: scripts load only when their widget is on the page.
- Lazy Load Background Images — defers offscreen background images. Browsers can’t natively lazy-load CSS backgrounds, so this one matters for hero-adjacent sections.
- Inline Font Icons — renders icons as small inline SVGs instead of downloading the full Font Awesome and Eicons font files.
One caveat: recent Elementor versions have made some of these permanent and removed their switches. If a toggle is missing from your Features screen, that feature is already part of core — nothing left to do.
After flipping switches, go to Elementor → Tools and hit Regenerate CSS & Data so Elementor rebuilds its cached files with the new settings.
Step 2 — Set the CSS Print Method to External File
Under Elementor → Settings → Advanced, set CSS Print Method to External File. This writes Elementor’s styles to a real .css file instead of inlining them into every page’s <head>. External files get cached by the browser and by your caching plugin, so repeat visitors skip the download entirely. On content-heavy pages this alone can shave hundreds of kilobytes off the initial HTML.
Step 3 — Rebuild Layouts With Containers, Not Sections
If your pages were built with the old Section/Column structure, they’re carrying the heaviest markup Elementor ever produced. A Section containing an inner Section and two Columns is five nested elements before a single word of content. A Flexbox Container does the same job with one.
- Build all new pages with Containers instead of Sections.
- Rebuild your heaviest existing pages first — the homepage and top landing pages carry your traffic and your Largest Contentful Paint element.
- Keep nesting shallow. A container inside a container is fine; four levels deep is a red flag.
- Combine widgets. A heading, a paragraph, and a button stacked as three widgets can often be one widget with tuned spacing. Aim for under 40–50 widgets per page — beyond that, load times start to suffer.
A smaller DOM also improves Interaction to Next Paint, because the browser has fewer elements to process when a visitor clicks or taps.
Step 4 — Cut Unused Fonts, Icons, and Addons
Every font weight and icon library is a render-blocking request. Audit yours:
- Google Fonts: if your design doesn’t use them, stop Elementor loading them. You can switch to system fonts under Elementor → Settings → Advanced, or disable them in code:
- Icons: the Inline Font Icons feature from Step 1 already removes the icon-font downloads. Don’t re-add the problem with an addon that ships its own icon set.
- Addon packs: if you installed a 100-widget addon bundle for one widget, that’s dozens of scripts loading on every page. Keep one bundle at most — or none. Elementor’s native widget set covers the vast majority of layouts.
- Custom fonts: when you do use them, host the files locally in WOFF2 format and preload only the weight used above the fold.
// Stop Elementor printing Google Fonts on the frontend
add_filter( 'elementor/frontend/print_google_fonts', '__return_false');Step 5 — Optimize Images Before Elementor Ever Sees Them
Images are the heaviest part of most Elementor pages, and no builder setting fixes a 4MB upload. Get the media right first:
- Compress and convert to WebP before uploading — ShortPixel, Imagify, or the free Squoosh web app all work.
- Upload at the size you’ll display. A 4000px photo squeezed into an 800px container is pure wasted bytes.
- Set explicit width and height (or an aspect ratio) on images so the browser reserves space — this kills layout shift and protects your CLS score.
- Lazy-load everything below the fold. WordPress does this natively with
loading="lazy", and Elementor’s Lazy Load Background Images covers backgrounds. Here’s the right way to set it up. - Skip the background video hero on mobile — serve a static image to small screens instead. Your LCP score will thank you.
Step 6 — Put Caching and a CDN in Front of Everything
Elementor generates its CSS and JavaScript dynamically, which is exactly what page caching exists for. Use one caching plugin and configure it properly: LiteSpeed Cache if your host runs LiteSpeed, otherwise WP Rocket or a similar optimizer. Enable page cache, browser cache, and CSS/JS minification, then put a CDN in front of your static assets.
Don’t neglect the server side either: PHP 8.2 or newer, and an object cache (Redis or Memcached) if your host offers one. Elementor’s dynamic file generation benefits directly from both — and server response time is the foundation everything else builds on.
Step 7 — Test After Every Change, Not Just at the End
Run PageSpeed Insights on a real URL — not only the homepage — after each step. Elementor changes can interact: a new performance feature plus an outdated addon can break a layout, so check the page visually too. Clear every layer of cache between tests (plugin cache, Elementor files, CDN) and test in an incognito window so you’re measuring what a new visitor gets.
The 5-Minute Checklist
- Features screen: every performance switch on (or already permanent in your version)
- CSS Print Method set to External File
- Layouts rebuilt with Containers, shallow nesting, under ~50 widgets per page
- Only the fonts and icons you actually use — hosted locally where possible
- Images compressed to WebP, correctly sized, lazy-loaded below the fold
- One caching plugin configured + CDN active, all caches cleared after changes
Work through that list and most Elementor sites land in the 90s on PageSpeed — with the design completely intact. The builder was never the problem. The build was.
Slow Elementor site and no time to tune it yourself? I optimize WordPress sites for a living — Core Web Vitals, Elementor builds, speed audits, the works. Get in touch and I’ll take a look.