--- title: "Elementor Core Web Vitals: fixing LCP, INP and CLS" id: "540" type: "post" slug: "elementor-core-web-vitals" published_at: "2026-10-06T20:00:48+00:00" modified_at: "2026-10-06T20:00:48+00:00" url: "https://danielpazwp.com/elementor-core-web-vitals/" markdown_url: "https://danielpazwp.com/elementor-core-web-vitals.md" excerpt: "Why Elementor sites fail Core Web Vitals, which Elementor performance settings matter, and how to fix hero images, deep DOM, animations and fonts." taxonomy_category: - "Performance" --- [Performance](https://danielpazwp.com/category/performance/) 7 min read # Elementor Core Web Vitals: fixing LCP, INP and CLS Why Elementor sites fail Core Web Vitals, which Elementor performance settings matter, and how to fix hero images, deep DOM, animations and fonts. Published **06/10/2026**7 min read [Written byDaniel PazDaniel Paz has worked on the web for more than 14 years and has focused on WordPress since 2016. He is CEO and founder of WebOption, creator of WP Alta Performance (Brazil’s reference channel on WordPress optimization) and has shipped WordPress for Globo, Shell, Endeavor, Estratégia Concursos and Brazil’s Federal Government. He speaks at WordCamp Brazil, WordCamp Canada and WordCamp US, TDC and PHP Conference Brazil.](https://danielpazwp.com/author/daniel-paz/) Elementor sites can pass Core Web Vitals, but the way pages get built makes failing easy. The usual causes are deep DOM trees from nested sections and columns, hero images set as CSS backgrounds or placed inside sliders, entrance animations on the LCP element, widget CSS and JavaScript loaded more widely than needed, Google Fonts and icon libraries, and popups or sticky headers that move the layout. To fix Elementor Core Web Vitals, turn on Elementor’s performance features, rebuild the heaviest templates with Flexbox containers, make the hero a real image that loads first, and cut what runs on mobile. Then confirm the change in field data at the 75th percentile. Elementor is not the only reason a site is slow, and it is rarely the first thing I would remove. It is, though, the place where I find the most avoidable work in audits of builder sites. For how the three metrics are measured and what the thresholds are, see [the complete guide to Core Web Vitals for WordPress](https://danielpazwp.com/core-web-vitals-wordpress/) . ## Why do Elementor sites fail Core Web Vitals? A page builder turns visual decisions into markup. Every section, column, container and widget becomes one or more wrapper elements, and each widget can bring its own CSS and script. The person building the page sees a clean layout in the editor and never sees the DOM it produces. The other cause is organizational. On most Elementor sites I audit, many people built templates over several years, each with a different idea of how to make a hero or a pricing table. So the problem is rarely one setting. It is a few heavy templates that carry most of the traffic. ## Which Elementor settings matter for performance? Elementor groups its performance options in its settings, under the Features tab and, in recent versions, a Performance tab. Names and defaults change between releases, and some are already on for new installs, so check your own version. These are the ones I look for: - Optimized DOM output and the Flexbox Container, which reduce the number of wrapper elements. - Improved asset loading, which loads widget scripts only on pages that use them. - Improved CSS loading, which loads widget CSS per widget instead of one large file. - Inline font icons, which render icons as inline SVG instead of loading full icon font files. - Lazy load background images, useful below the fold and harmful if it touches the hero. - Load Google Fonts locally, which removes the connection to a third-party font host. - CSS print method. External files can be cached by the browser across pages. Internal embedding avoids extra requests but repeats the CSS in every HTML response. - Element caching, in versions that have it, which caches the rendered output of widgets on the server. Turn these on in staging first. Some of them change markup, and custom CSS written against the old wrappers can break. ## How do you fix LCP on Elementor pages? On most Elementor pages the LCP element is the hero: a background image, an Image widget or a large heading. These are the patterns that make it slow. - The hero image is a CSS background. The browser only discovers a background image after it has the CSS and knows the element needs it, which is later than an `img` in the HTML. Use an Image widget for the hero when you can. If the design needs a background, preload that image and make sure lazy loading of background images skips it. - The hero is a slider. The first slide often waits for the carousel script to start before it is shown at the right size. A static hero, or a slider whose first slide renders without JavaScript, is faster. - The hero has an entrance animation. Motion effects start the element hidden and reveal it with JavaScript, so the LCP is recorded only when the animation shows it. Remove entrance animations from anything above the fold. - Mobile and desktop versions of the same section. Responsive visibility hides elements with CSS. Both versions stay in the HTML and the DOM, and an image that is not lazy loaded in the hidden copy can still download. - Render-blocking CSS from the theme, the Elementor kit, global widgets and add-on packs, all loading before anything is painted. The four-part LCP breakdown in [LCP in WordPress: causes and fixes](https://danielpazwp.com/lcp-wordpress/) helps you see which of these is your bottleneck. ## How do you fix INP on Elementor sites? INP problems on Elementor sites usually come from two places: a very large DOM and scripts that run on interaction. A large DOM makes every style recalculation and layout more expensive, so even a small click handler can turn into a long task. Old section and column layouts nest deeper than the same design built with Flexbox containers. Mega menus, nested tabs, accordions with heavy content and Loop Grids with many items all add up. Hiding a widget on mobile does not remove it from the DOM. Then come the scripts: popups with several triggers, form validation, sticky effects that run on scroll, add-on packs that load their full library on every page, and the third-party tags every marketing site has. Rebuilding the heaviest template with containers and fewer widgets usually helps more than any single setting. The general method is in [INP in WordPress: fixing slow interactions](https://danielpazwp.com/inp-wordpress/) . ## Where does CLS come from on Elementor sites? - Sticky headers that change height or switch from static to fixed. Scroll down slowly and watch whether the content jumps when the header sticks. - Web fonts that swap late, especially when several Google Fonts families and weights load. - Announcement bars and popups that push content down instead of overlaying it. - Carousels and galleries that resize after their script runs. - Images in HTML widgets or custom code without width and height. Reserve space for anything that appears after the first paint, and limit fonts to the weights you actually use. More fixes in [CLS in WordPress: stop layout shifts](https://danielpazwp.com/cls-wordpress/) . ## Quick reference | Problem | Metric hit | What to change | | --- | --- | --- | | Hero as CSS background | LCP | Use an Image widget, or preload and exclude it from lazy loading | | Hero slider | LCP and CLS | Static hero, or a first slide that renders without JavaScript | | Entrance animation above the fold | LCP | Remove the motion effect from the hero | | Deep section and column nesting | INP | Rebuild with Flexbox containers | | Duplicate mobile and desktop sections | LCP and INP | One responsive section instead of two hidden copies | | Many font families and weights | LCP and CLS | Fewer weights, loaded locally | | Add-on packs loaded site-wide | LCP and INP | Load only where used, remove unused add-ons | | Sticky header changing size | CLS | Fixed height, or a placeholder of the same height | ## Do you need to leave Elementor? Usually not as a first step. I start by rebuilding the two or three templates that carry most of the traffic, turning on the performance features and cleaning up add-ons. That fixes most of the failures I see. If a site still fails after that, or a redesign is coming anyway, it is worth comparing with a block theme, which I do in [Elementor vs Gutenberg performance](https://danielpazwp.com/elementor-vs-gutenberg-performance/) . For general Elementor speed beyond the three metrics, see [how to speed up Elementor](https://danielpazwp.com/speed-up-elementor/) , and for what a cache or optimization plugin adds on top, see [the best plugins for Core Web Vitals](https://danielpazwp.com/core-web-vitals-plugins/) . If you want your Elementor templates traced and ranked by what to fix first, my [WordPress performance audit](https://danielpazwp.com/wordpress-performance-audit/) does exactly that. [Work with Daniel](https://danielpazwp.com/#book) [More in Performance](https://danielpazwp.com/category/performance/) [About the authorDaniel Paz has worked on the web for more than 14 years and has focused on WordPress since 2016. He is CEO and founder of WebOption, creator of WP Alta Performance (Brazil’s reference channel on WordPress optimization) and has shipped WordPress for Globo, Shell, Endeavor, Estratégia Concursos and Brazil’s Federal Government. He speaks at WordCamp Brazil, WordCamp Canada and WordCamp US, TDC and PHP Conference Brazil.Author page](https://danielpazwp.com/author/daniel-paz/) ## Related articles [All articles](https://danielpazwp.com/blog/) [Performance Oct 2026What are Core Web Vitals?](https://danielpazwp.com/what-are-core-web-vitals/) [Performance Oct 2026How to speed up WordPress: an engineer’s guide](https://danielpazwp.com/speed-up-wordpress/) [Performance Oct 2026PageSpeed Insights vs Lighthouse: field vs lab data](https://danielpazwp.com/pagespeed-insights-vs-lighthouse/)