Why Elementor Excessive DOM Size Happens and How to Fix It

If PageSpeed Insights keeps flagging an excessive DOM size on your Elementor site, you’re not alone, and it’s not just a vanity warning. Below I explain the Elementor excessive DOM size problem in plain terms: what the DOM is, why Elementor pages grow so large, how it affects real visitors, and the fixes I use to shrink pages without starting over. You can do most of them in the editor yourself.

What the DOM is and why size matters

The DOM is the browser’s working model of your page. Every heading, image, button, wrapper and invisible container is an element in it. Lighthouse, the engine behind PageSpeed Insights, has long flagged pages with more than about 1,400 elements as excessive.

A large DOM costs you in three ways:

• Slower rendering. Every style calculation and layout pass has more elements to work through, which slows the first paint and every update after it.
• Slower interactions. When someone taps a menu or accordion, the browser has to recalculate more of the page, which pushes up Interaction to Next Paint.
• More memory. On mid-range phones, large pages can stutter while scrolling.

A big DOM rarely makes a page fail on its own, but it makes every other speed problem worse. It’s one reason some Elementor sites never feel snappy on mobile, no matter how much caching you add.

Why Elementor pages get so large

Wrapper nesting

In the older section and column structure, every widget sat inside several layers: a section, a container div, a column, a column wrapper, a widget wrapper, then the widget itself. A simple heading could need half a dozen elements. Inner sections doubled that. Elementor’s Flexbox Containers and its optimized DOM output cut this nesting a lot, but many sites were built before those existed and still use the old structure.

Duplicated sections for desktop and mobile

This is the biggest one I find. To get a layout looking right on phones, someone builds a desktop version of a section and a separate mobile version, then hides each one on the other device. Hiding is done with CSS, so both versions are still in the page for every visitor. Do that for the hero, the services grid and the footer and you have doubled your DOM.

Mega menus and off-canvas menus

A mega menu with columns, icons, images and descriptions is loaded on every page, even though most visitors never open it. Many headers also include a second, separate mobile menu with the same links.

Widget-heavy layouts

• Icon lists and icon boxes where each item is several nested elements.
• Tabs and accordions that load every panel’s content upfront.
• Post and product grids showing 24 or 48 items with all their markup.
• Sliders and testimonial carousels with many slides, plus cloned slides for looping.
• Addon packs that wrap widgets in extra layers of their own.

How to fix Elementor excessive DOM size

Work on a staging copy, change one template at a time, and measure before and after. These are in the order I usually tackle them.

1. Remove duplicate desktop and mobile sections. Rebuild them as one responsive section using Elementor’s per-device settings for spacing, columns and font size. This alone can remove hundreds of elements.
2. Convert sections to containers. Elementor includes a tool to convert old sections into Flexbox Containers. Run it on a copy of the page, check the layout at every breakpoint, then tidy up. Rebuilding complex sections by hand often gives a cleaner result than the converter.
3. Flatten nesting. Remove inner sections and containers that exist only for spacing. Use padding, gap and alignment instead.
4. Slim the header. Simplify the mega menu, drop images and descriptions from menu items unless they earn their place, and use one menu that adapts to mobile instead of two.
5. Cut grid sizes. Show 9 or 12 posts or products and paginate, rather than loading dozens.
6. Trim sliders and tabs. Use fewer slides, avoid cloned loops, and move long tab content to its own page if it matters for search.
7. Check the Features settings on older sites. Make sure optimized DOM output and Flexbox Containers are active. Newer versions of Elementor have them on by default.

When a site was built on years of patched templates, it can be faster and cheaper to rebuild the key templates cleanly than to keep fixing them. I cover both routes in my speed optimization and website redesign work.

How to measure your progress

Open the page in Chrome, open DevTools, go to the Console and run document.querySelectorAll('*').length. That gives you the total element count. Write it down for each key template (home, a service page, a blog post, a product page), make your changes, and check again. PageSpeed Insights also reports the DOM size and the deepest nesting level.

Do not chase a number for its own sake. Some pages genuinely need a lot of content. The goal is to remove elements nobody sees and nesting that adds nothing.

It also helps to look at where the elements are, not just how many there are. In DevTools, open the Elements panel and collapse the main sections of the page one by one. You’ll usually find that two or three areas, often the header, a long FAQ accordion and a testimonials carousel, account for a large share of the total. Those are the places to start, because one fix there helps every page that shares the same header or template.

Finally, remember that the header and footer appear on every page of the site. Removing 200 elements from a global header is worth more than removing 200 from a single landing page, so global templates usually come first in my plan.

At a glance

• Count elements on your main templates and note the worst pages.
• Find and merge any duplicate desktop and mobile sections.
• Convert old sections to containers on a staging copy.
• Remove spacer sections and unnecessary inner containers.
• Simplify the mega menu and use one responsive menu.
• Limit grids, sliders and tabs to what visitors actually use.
• Recount and retest in PageSpeed Insights after each template.

Related reading: how to fix Interaction to Next Paint (INP) on your website and how to run a WordPress plugin audit for speed, step by step.

Questions people ask me

How many DOM elements is too many?

Lighthouse has long treated more than about 1,400 elements as excessive. Treat that as a guide, not a hard limit. Lighter is better, especially on mobile.

Does hiding a section on mobile remove it from the page?

No. Elementor hides it with CSS, so it’s still downloaded and still part of the DOM. Only deleting it, or building one responsive section, reduces size.

Will converting to containers break my layout?

It can shift spacing and alignment, which is why I always do it on staging and check every breakpoint before going live.

Should I switch away from Elementor to fix DOM size?

Usually not. A well-built Elementor site with containers and sensible layouts can be fast. Switching builders is a much bigger decision than one warning justifies.

Request a free website review and I’ll show you where the extra elements come from.