TL;DR
“Elementor is slow” describes two separate problems—editor lag and frontend slowness—and the fixes for each have almost no overlap. For the published site, the highest-impact changes are enabling Elementor’s conditional asset loading settings, removing unused CSS and JS, and adding a caching layer with a CDN. NitroPack handles the entire frontend optimization stack automatically, including Elementor-specific JS exclusions that typically break other tools.
When people say “Elementor is slow,” they’re usually describing one of two completely different problems.
- The first is editor lag: The panel freezes while you drag a widget, padding adjustments take three seconds to register, and containers won’t select cleanly. This is a server resource and browser memory problem. Caching tools do nothing for it.
- The second is frontend slowness: what your visitors experience. Pages taking six seconds to load, Core Web Vitals in the red, Google PageSpeed scores that make you want to close the tab. This comes from DOM bloat, page-specific CSS and JS, external font requests, and add-on packs loading their entire asset library on every page.
If you’ve identified the latter as your problem and want a quick fix, NitroPack’s free plan takes minutes to set up, requires no credit card, and doesn’t compete with Elementor for server resources—but more on that later.
For now, let’s work through both problems from the ground up.
Test NitroPack yourself
By submitting, you agree to our Privacy Policy.
How to fix a slow Elementor editor
💡 Before touching anything
Run your site through PageSpeed Insights and a waterfall tool like WebPageTest to get a baseline. High TTFB points to hosting; large LCP points to images or render-blocking CSS; high Total Blocking Time points to JavaScript. NitroPack’s PageSpeed Insights guide walks you through reading the results.
If your problem is editor lag, caching plugins won’t help. The editor runs in a completely different environment from your published site, and the fixes are specific to server resources and browser behavior.
Here’s where to start.
- Increase your PHP memory limit. Elementor’s system requirements set 256 MB as the bare minimum, 512 MB as recommended, and 768 MB for best performance. If you’re on a shared host with a lower cap, this is almost certainly contributing to the lag.
- Activate Safe Mode. Go to Elementor > Tools > Safe Mode. This loads the editor without your active plugins or theme, so you can immediately tell whether the slowness is coming from a conflict. If the editor snaps back to normal in Safe Mode, reactivate your extensions one at a time until you find the culprit.
- Enable the Switch Editor Loader Method. Go to Elementor > Settings > Advanced and toggle this on. It changes how the editor loads its interface and resolves rendering delays for a surprising number of setups.
- Close your other browser tabs. The Elementor editor renders every registered widget in real time. On complex pages, that’s a significant RAM draw—and competing tabs make it worse.
⚠️ Important
If you’re running a caching or optimization plugin, make sure it’s excluding Elementor’s editor and preview URLs. Some plugins apply caching, minification, and JS deferral to admin URLs, which can interfere with the editor even though that’s not what they’re intended for.
Audit your add-ons and theme overhead
The thing about Elementor add-on packs is that the same ecosystem that makes Elementor so flexible is also its biggest performance liability.
Plugins like Essential Addons, JetElements, and PowerPack load their entire CSS and JavaScript library on every page—regardless of which widgets you’re actually using. A page with none of its widgets still pays the full asset cost. However, removing the plugin isn’t always the best fix—you need to try and understand the problem first.
One way to do that is to install Query Monitor (free), which provides a per-plugin breakdown of memory consumption and database query counts on every page load. Instead of guessing which plugins to trim, you get the data sorted by actual impact.
On the theme side: If you’re running a heavy multipurpose theme alongside Elementor, you’re loading two separate CSS/JS frameworks on every page—the theme’s and Elementor’s. Switching to Hello Elementor or another minimal starter theme eliminates that double layer.
Finally, don’t just deactivate plugins you don’t need—delete them. Deactivated plugins can still leave orphaned database tables and stored data behind. A proper uninstall (sometimes requiring a cleanup tool or manual SQL) is the only way to fully remove that overhead.
Removed everything you don’t need?
By submitting, you agree to our Privacy Policy.
Elementor performance settings that affect your published site
Elementor already has some performance toggles that you can check out before turning to external fixes. And the best part is that they affect the code your visitors actually receive. Let’s take a look.
Switch CSS Print Method to External File
Find it at Elementor > Settings > Performance. The setting is called CSS Print Method, and it controls whether Elementor embeds your page-specific CSS inline inside the HTML, or outputs it as a separate stylesheet file.
Here’s why that distinction matters:
| Method | What happens | Performance impact |
|---|---|---|
| Inline | CSS is baked into every HTML response. | Can’t be cached across pages; inflates HTML size on every request. |
| External File | CSS is output as a separate stylesheet. | Browsers and CDNs can cache it and reuse it across page visits. |
Switch it to External File and leave it there.
Enable Improved Asset Loading and Improved CSS Loading
Both of these settings work on the same principle: They stop loading assets on pages that don’t need them.
- Improved Asset Loading makes Elementor’s Lightbox, Dialog, and Share Link JavaScript load only on pages that actually use those features—not across your entire site. That alone can cut meaningful JavaScript weight from pages where none of those widgets appear.
- Improved CSS Loading does the same for stylesheets. Instead of loading a single global CSS file on every page, it loads only the CSS for the widgets actually present on that page. Depending on your setup, that’s up to 171KB of render-blocking CSS removed per page.
Both of these features started as opt-in experiments before being promoted to stable defaults in recent Elementor versions. If your site was built on an older install, there’s a real chance they’re still switched off. It takes thirty seconds to check.
Turn on Optimized DOM Output (carefully)
This setting removes legacy wrapper divs—specifically, .elementor-inner, .elementor-row, and .elementor-column-wrap—from Elementor’s HTML output. Fewer DOM nodes means less for the browser to parse, render, and store in memory, which translates directly to faster page loads.
The catch: On existing sites built with the old Section/Column layout, this can break custom CSS that targets those removed class names.
Elementor documents every wrapper removed by version—from the .elementor-inner removal in 3.0 through to elementor-section-wrap in 3.6. If you’ve written any custom CSS using those class names, it will stop working.
⚠️ Always test on staging before enabling this on a live site.
This isn’t theoretical—it’s a documented breaking change for sites built on older layouts.
For new builds using Flexbox Containers (now Elementor’s default layout system), you don’t need to worry about this at all. Containers already produce significantly less markup than the legacy Section/Column structure, and Optimized DOM Output is safe from the start.
Disable unused fonts and widgets
A few more quick wins before moving on to the frontend optimization stack.
- Google Fonts. If your theme already handles typography, Elementor loading Google Fonts on top of it means unnecessary external DNS lookups and additional font file downloads on every page. Thankfully, you can easily disable those in the settings, even in the free version.
- Inline Font Icons. Enabling this setting swaps the Font Awesome CSS library for inline SVGs—removing an entire stylesheet request from your page load.
- Element Manager. Go to Elementor > Element Manager and disable widget types from add-on packs you never use. If a widget type is disabled, its scripts never load. Simple as that.
🙂 Warning
One thing worth clearing up while we’re here: Regenerating CSS & Data is not a speed fix. It resolves CSS discrepancies that appear after updates or setting changes—display issues, styles not reflecting correctly, that kind of thing. It does not address TTFB, JavaScript bloat, or add-on overhead.
Clearing the Elementor cache on a slow site is the most common first-try fix that doesn’t work, because users assume “clearing cache” and “improving speed” are the same thing. They’re not.
Fix what visitors actually experience on your site
Everything covered so far—editor fixes, add-on audits, Elementor’s internal settings—happens before a visitor ever loads your page. This section is about what they actually receive: The compiled HTML, CSS, JavaScript, and images that determine how fast your site feels in the real world.
Images, video embeds, and lazy loading
Images are where many Elementor sites quietly bleed performance, especially on mobile.
- Format and file size first. Convert images to WebP or AVIF. Hero images should come in under 200KB; thumbnails under 50KB. The most common mistake? Uploading a 4000px original that displays at 600px on a mobile screen. The browser downloads the full file regardless.
- Set explicit width and height attributes on all images. Without them, the browser doesn’t know how much space to reserve while the image loads, which causes layout shift (CLS) as elements jump around on screen.
- Video embeds. Replace YouTube and Vimeo iframes with lightweight facade images that load the full player only when a visitor clicks. A YouTube iframe loads dozens of external requests before anyone presses play. A facade loads one image.
- On lazy loading—pick one, not both. Elementor has its own built-in lazy loading. If you add a plugin-based lazy loader on top of it, you get double-processing, conflicts, and often worse performance than either solution alone.
NitroPack handles adaptive image sizing automatically—serving mobile-appropriate dimensions without manual resizing—along with WebP conversion and video facades on all paid plans.
💡 Did you know?
The “LCP request discovery” warning in PageSpeed Insights means your most important above-the-fold image is being deferred when it shouldn’t be. If you’re using both Elementor’s lazy loading and a plugin, this is a likely culprit.
Caching and why clearing the Elementor cache isn’t enough
Here’s something that trips up a lot of Elementor users: There isn’t just one cache. There are three distinct caching layers, and they solve completely different problems.
| Cache layer | What it does |
|---|---|
| Page cache | Serves pre-built HTML snapshots to visitors instead of executing PHP on every request. |
| Browser cache | Stores CSS, JS, and images locally via cache-control headers, reducing repeat download requests. |
| Elementor’s CSS cache | Regenerates page-specific stylesheets after design changes or updates. |
Elementor’s Clear Files & Data tool only touches that third layer. It fixes CSS discrepancies—styles not reflecting correctly after an update, design changes not appearing on the frontend. That’s it.
It does not create page-level caching, which serves a pre-built HTML file instead of regenerating the page on demand. Add a CDN on top of that, and those cached files get distributed to edge servers closer to wherever your visitors are—reducing latency regardless of where your hosting server sits.
✨Start with NitroPack today!
Combine page and browser caching with a built-in Cloudflare CDN in a single setup →
Remove unused CSS and JavaScript
Unused CSS removal and JavaScript delay are the two highest-impact frontend optimizations you can make on an Elementor site. They’re also the two most likely to break things if you get them wrong.
The problem is specific to Elementor’s architecture. Sticky headers, scroll animations, search widgets, and dropdown menus all depend on JavaScript that must be initialized before a user interacts with the page. Defer or delay those files, and your sticky nav stops sticking, your animations freeze mid-scroll, and your forms may stop working entirely.
Elementor doesn’t provide a universal JS exclusion list. The files you need to protect depend on which caching or optimization plugin you’re using—and every plugin handles this differently. We recommend starting with that plugin’s official Elementor integration documentation, then test your site manually: Check sticky headers, forms, animations, and menus. Adjust from there.
On top of that, many caching tools conflict with Elementor’s own image loading and lazy loading features, which means you often have to disable Elementor’s built-in settings to avoid double-processing—the exact problem covered in the images section above.
This is the real reason “just install a caching plugin” breaks Elementor sites so often. Users end up toggling settings back and forth without a clear picture of which tool is responsible for which optimization.
If you’re using NitroPack specifically, here are the JavaScript exclusions for Elementor and Elementor Pro:
jquery - js
/elementor/* - any
/elementor-pro/* - any
/wp-includes/js/imagesloaded.min.js* - js
ElementorProFrontendConfig - js - inline
elementorFrontendConfig - js - inlineAdd these to your NitroPack excluded resources before enabling JS delay. Note that if you’re running third-party Elementor add-ons, you may need additional exclusions beyond these—there’s no single list that covers every combination.
How NitroPack handles all of this automatically
Everything in the previous sections—manual JS exclusion lists, CSS print method toggles, lazy loading conflicts, caching layer confusion—exists because frontend optimization on an Elementor site involves a lot of moving parts that don’t always play nicely together.
NitroPack is built to handle that entire stack automatically.
Here’s what that looks like in practice:
- Critical CSS is generated per page, not globally—so each page gets only the styles it actually needs, inlined in the header.
- Unused CSS removal strips page-specific dead weight without touching styles that are in use.
- JavaScript delay defers non-critical scripts until user interaction, with Elementor-aware handling built in—the exclusions covered in the previous section are managed automatically.
- Adaptive image sizing serves images scaled to the visitor’s actual screen dimensions, not just a responsive approximation.
- Google Fonts CDN hosting routes font requests through NitroPack’s own infrastructure instead of Google’s servers.
- Built-in Cloudflare CDN is included on all paid plans—no separate subscription, no additional configuration.
Because NitroPack is a cloud-based performance optimization service, all processing happens on its own servers rather than yours. It doesn’t compete with Elementor for PHP memory or CPU on shared hosting, which is one of the reasons it works where other tools cause conflicts.
Test NitroPack yourself
By submitting, you agree to our Privacy Policy.
🙂 Important
For edge cases where something needs protecting, the Excluded Resources feature gives you manual control over exactly which scripts bypass optimization.
87% of NitroPack users say they no longer pay separately for CDN, caching tools, image optimization, or CSS/JS minification.
“If you want lightning-fast results for your Elementor site, NitroPack is the way to go. And I barely touched the settings!”—WPLearningLab, reviewed on YouTube.
What NitroPack doesn’t do: Fix editor lag, clean the database, or configure Elementor’s internal settings. Those are separate problems—and they’re all covered earlier in this guide.
You can try NitroPack’s free plan with no credit card required to see the impact before committing to a paid plan.
When hosting and database bloat are the real bottlenecks
Frontend optimization can only take you so far. If the server itself is underpowered, or if the database is bloated with years of accumulated revision data, no amount of CSS minification will fully fix the problem. These are the two highest-effort layers to address—but they’re also worth understanding, because they’re often the actual root cause.
Hosting and TTFB
Elementor’s system requirements set the baseline clearly: 256 MB minimum WP memory, 512 MB recommended, 768 MB for best performance. PHP 8.x is strongly recommended over PHP 7.4—the performance difference in script execution is significant enough that it’s one of the easiest server-side wins available.
To check whether your server is the bottleneck, run your site through PageSpeed Insights or WebPageTest and look at your TTFB. According to Google, TTFB should be under 800ms. Consistently above that threshold—especially from locations close to your server—points to a hosting problem that no frontend optimization can fully compensate for.
NitroPack’s built-in Cloudflare CDN reduces TTFB for cached pages by serving them from edge nodes closer to the visitor. But that only applies to repeat visits after a page has been cached. The very first uncached visit still hits the origin server directly—and if that server is slow, the first visitor waits.
“If TTFB is consistently high, the long-term answer is better hosting. Shared hosting plans that cap memory well below Elementor’s recommendations will always struggle, regardless of what optimization tools are running on top.” —Niko Kaleev, User Experience Content Expert at NitroPack.
Database bloat
Elementor sites get slower the more you work on them. Every time you save a page in Elementor, WordPress stores a full serialized copy of the page data as a new revision. Edit a complex page fifty times, and there are fifty complete copies sitting in wp_posts.
Over months and years, this bloat accumulates quietly—slowing down database queries, editor load times, and eventually page generation itself.
The fix is straightforward:
- Cap future revisions. Add this line to your
wp-config.php:
define('WP_POST_REVISIONS', 5);This limits WordPress to storing only the five most recent revisions of any post or page going forward.
- Clean up what’s already there. Run WP-Optimize (or a similar database cleanup tool) monthly to remove existing excess revisions, expired transients, and orphaned post metadata.
NitroPack doesn’t interact with the WordPress database at all—it operates entirely on the frontend. WP-Optimize and NitroPack solve different problems and work fine alongside each other.
Frequently asked questions
Does Elementor slow down your site compared to building without a page builder?
Yes—but the gap is smaller than most people assume, and it’s largely closeable. Benchmarks show a default Elementor install loads around 1.93 seconds versus roughly 1.32 seconds for a comparable Gutenberg build.
Will NitroPack work with Elementor add-on packs like Essential Addons or JetElements?
Yes. NitroPack works with Elementor and Elementor Pro, and is compatible with the major add-on packs. For Elementor-specific JS exclusions, refer to the list provided earlier in this guide.
If you’re running additional third-party add-ons, you may need extra exclusions on top of the core Elementor ones—the Excluded Resources feature in your NitroPack dashboard gives you full control over which scripts are protected from optimization.
Why is the Elementor editor lagging even though my published site is fast?
Editor performance and frontend performance are entirely separate. A site with excellent PageSpeed scores can still have an editor that takes 30 seconds to open a complex page. The editor runs a full rendering of all registered widgets, theme assets, and active plugin code inside your browser—frontend caching and optimization tools have no effect on this.
Editor lag is fixed through PHP memory increases, Safe Mode testing, the Switch Editor Loader Method, and reducing active plugin count.
Should I clear the Elementor cache to fix slowness?
Only if the issue is CSS discrepancies—styles not reflecting correctly after an update or design change. The Regenerate CSS & Data tool resolves that specific problem. It does not fix TTFB, JavaScript bloat, add-on overhead, or any other underlying performance issue. If your site is slow, clearing the Elementor cache will leave it equally slow afterward.
What’s the best way to remove unused CSS and JavaScript generated by Elementor?
Per-page unused CSS removal and delayed JavaScript execution are the two highest-impact approaches. Doing this manually requires plugin-specific exclusion lists and per-site testing to avoid breaking sticky headers, animations, and forms. NitroPack handles both automatically—critical CSS is generated per page, unused CSS is stripped, and JS delay uses Elementor-aware exclusions without requiring manual configuration.
Test NitroPack yourself
By submitting, you agree to our Privacy Policy.
