To speed up Elementor, fix the server and the page cache first, then cut what Elementor puts on each page. In practice that means building with the Flexbox Container instead of nested sections and columns, turning on the performance features your Elementor version offers (optimized DOM output, conditional asset and CSS loading, inline font icons), loading fonts locally, keeping the hero image out of lazy load and away from entrance animations, and switching off add-on widgets you never use. Elementor is rarely slow by itself. It gets slow when layouts are nested five levels deep and every add-on loads its assets on every URL.
I audit a lot of Elementor sites, and the builder usually gets blamed for problems it only made easier to create. This guide is the order I work in. It is part of my larger guide on how to speed up WordPress, and if your problem is specifically a failing Core Web Vitals report, read Elementor Core Web Vitals: what to fix first alongside it.
Why do Elementor sites get slow?
Elementor adds cost in three places. Once you know which one hurts your site, the fix list gets short.
- Markup depth. Every section, column, inner section and widget wrapper is a DOM node. Old layouts built with sections and columns often end up with a very large DOM, which makes style calculation and layout slower and hurts INP on cheaper phones.
- CSS and JavaScript. Elementor loads its frontend files, a CSS file per page, icon libraries and fonts. Add-on packs load their own files, often on every page whether or not their widgets are used.
- PHP work. Elementor stores the layout as data in post meta and renders it through PHP widget classes on each uncached request. That is fine with a page cache in front and expensive without one.
The first two show up in Lighthouse and in field data. The third shows up as a slow TTFB for logged-in users, for cart and checkout pages, and for anything your cache bypasses.
To speed up Elementor, start with the server and the page cache
Before touching a single Elementor setting I check what happens on an uncached request. If the HTML takes more than a second to arrive, no amount of CSS tuning will get LCP under 2.5 seconds on mobile. Make sure a page cache serves anonymous visitors, that marketing query strings and cookies don’t bypass it, that PHP is a supported version with OPcache on, and that a persistent object cache is in place if the site has many logged-in users. My guide to reducing TTFB in WordPress covers that part step by step.
Which Elementor settings actually help?
Elementor moves performance work around between releases. Some features start as experiments under Elementor > Settings > Features (older versions called the screen Experiments), some become the default and vanish from that screen, and some options live in a Performance or Advanced tab. So I don’t give version numbers here. Open your own settings and look for these names:
| Feature or setting | What it changes | What to check after |
|---|---|---|
| Flexbox Container | Replaces the section and column wrappers with a single flex container, so the same layout needs fewer DOM nodes | Existing pages keep their old structure until you convert or rebuild them |
| Optimized DOM Output | Drops some legacy wrapper elements from widget markup | Custom CSS that targeted the removed wrappers |
| Improved Asset Loading | Loads widget scripts only on pages where the widget is used | Widgets that rendered fine before but now lose behavior |
| Improved CSS Loading | Loads widget CSS only for widgets present on the page | Styling of widgets inside templates and popups |
| Inline Font Icons | Renders icons as inline SVG instead of loading an icon font | Icons in custom code that expect the font classes |
| Lazy Load Background Images | Delays background images set in Elementor until they are near the viewport | Never apply it to the hero background if that is your LCP element |
| Element Caching | Stores the rendered output of elements so uncached requests do less PHP work | Dynamic widgets that must show fresh or per-user content |
| CSS Print Method | Chooses between an external CSS file per page and CSS embedded in the HTML | External files cache better across pages; embedded saves a request on single-page visits |
After changing any of these, regenerate the generated files under Elementor > Tools and test the page in staging. A stale generated CSS file can make a correct change look broken, so clear the page cache too.
Should you rebuild old layouts with containers?
Not all at once. Rebuilding every page is expensive and rarely necessary. I pick the templates that carry most traffic, usually the home page, the header and footer templates, the main service or product templates, and the blog single template. Header and footer matter more than people expect because they render on every URL. Converting those few templates to containers usually removes more DOM nodes across the site than rebuilding fifty low-traffic pages.
While rebuilding, flatten the structure. A container inside a container inside a container, just to add padding, is the same problem with a new name.
How should you handle fonts and icons?
Fonts are one of the easiest wins on Elementor sites. By default Elementor can load Google Fonts from Google’s servers for every family and weight used in the kit or in any widget. My order of work:
- Limit the kit to two families and the weights you actually use. Each extra weight is another file.
- Use the setting that loads Google Fonts locally if your version has it, or disable Google Fonts in Elementor and self-host the files from your theme.
- Set font-display to swap, which Elementor exposes as a setting for Google Fonts, so text renders while the font downloads.
- Preload only the one or two font files used above the fold.
For icons, Inline Font Icons removes most of the weight. If you can’t use it, check whether the site still loads Font Awesome 4 support for old content and turn it off when nothing needs it. Loading a whole icon library for three social icons in the footer is a common find in my audits.
What breaks LCP on Elementor pages?
The hero section is where most Elementor LCP problems live, and they come from three habits.
The first is putting the hero image in a CSS background. The browser only discovers it after downloading and parsing the CSS, so it starts late. An image widget in the HTML is discovered by the preload scanner right away. The second is lazy loading the hero. Check the rendered HTML: if the LCP image has loading=”lazy”, it waits for layout before downloading. The third is entrance animations. Elementor hides an animated element until its script runs and reveals it, so an animated hero heading or image can’t paint until JavaScript has executed. Remove entrance animations from anything above the fold.
WordPress 6.3 added fetchpriority=”high” to the image core guesses is the LCP candidate, but builder markup doesn’t always go through the same path. Look at the HTML of your own page instead of assuming. The detailed walkthrough is in my guide to fixing LCP in WordPress.
Add-on packs, popups and third-party widgets
Most Elementor sites I audit have at least one add-on pack installed for one or two widgets. Many of those packs have a module or widget manager in their settings. Turn off every widget you don’t use, then check the network panel to confirm the files are gone, because some packs still load a shared bundle.
Popups, sliders, mega menus and chat widgets are the usual INP offenders. They attach event handlers and run JavaScript on interaction, and on a slow phone that is where the 200 ms budget disappears. If a slider exists only because a client asked for one years ago, removing it does more than any optimization of it. More on that in fixing INP in WordPress.
Do caching plugins work with Elementor?
Yes, but the aggressive options need care. Delaying all JavaScript until interaction and removing unused CSS are the two features that most often break Elementor menus, tabs, sliders and popups, because the CSS for those states isn’t used on first render and their scripts must run early. Turn those features on one at a time, test the mobile menu and any popup, and add exclusions for what breaks. I compare the main plugins in the best WordPress caching plugins.
What should you measure after each change?
Change one thing, then measure. These are the numbers I record before and after:
- LCP, INP and CLS from field data (CrUX or your own RUM), knowing CrUX is a 28-day rolling window and won’t move the next morning
- DOM size reported by Lighthouse for the main templates
- the number and weight of CSS and JavaScript files in the network panel, filtered by Elementor and add-on paths
- TTFB on an uncached request and on a cached one
Lab tools are good for checking a single change. Field data tells you whether real visitors saw it. If you are not sure how the two relate, read field data vs lab data.
Frequently asked questions
Is Elementor bad for performance?
No, but it makes it easy to build heavy pages. A page built with containers, few add-ons, local fonts and no animated hero can pass Core Web Vitals. The slow Elementor sites I see are usually slow because of layout habits and add-ons, not because of the builder core. If you are deciding between builders for a new project, I compare the two approaches in Elementor vs Gutenberg performance.
Does Elementor Pro make a site slower than the free version?
Pro adds widgets, the theme builder and popups. The widgets you use cost something; the ones you don’t use should not load when conditional asset loading is active. Measure the pages that use Pro features instead of the plugin as a whole.
Should I disable Elementor’s Google Fonts?
If you self-host the fonts in your theme, yes. If not, use local loading and font-display swap. The goal is the same either way: no request to a third-party font server in the critical path.
If you want someone to go through your Elementor templates and tell you which of these fixes matters for your traffic, that is what I do as a Core Web Vitals expert: I find the slow template, explain the cause and prove the change with field data.