sfw/fix
Excessive DOM size medium

Avoid an excessive DOM size

A page with thousands of DOM nodes inflates memory and slows every style and layout recalculation, hurting responsiveness.

What you see

Avoid an excessive DOM size
3,214 elements
Maximum DOM depth: 28
Maximum child elements: 312

What’s actually happening

Scrolling stutters and taps feel sticky, especially on phones. Lighthouse reports the total element count, the deepest nesting, and the node with the most children. Open the Performance panel and you'll see long purple "Recalculate Style" and "Layout" blocks on interaction. INP suffers because every DOM change forces the browser to re-evaluate a huge tree. Memory use climbs, and on lower-end devices tabs get evicted.

Common causes

  • Page builders (Elementor, Divi, WPBakery) that wrap every element in layers of nested divs
  • Long lists or tables rendered in full — thousands of rows in the DOM at once with no virtualization
  • Component frameworks that add wrapper elements per component, compounding through deep trees
  • Hidden content kept in the DOM (off-screen menus, tabs, modals, accordions) instead of being removed
  • Repeated markup from loops or CMS blocks that could collapse into fewer, simpler elements

How to fix it

  1. Find the heaviest part of the tree firstIn DevTools Elements panel, look at the node Lighthouse names as having the most children. That's usually one list, table, or builder section dragging the whole count up. Fix the worst offender before touching anything else.
  2. Virtualize long lists and tablesRender only the rows in (and just around) the viewport and recycle nodes as the user scrolls — react-window, TanStack Virtual, or native content-visibility: auto on row containers. A 5,000-row table can drop to a few dozen live nodes.
  3. Flatten the markup the builder generatesReplace deeply nested wrapper divs with CSS grid/flex layouts that need fewer elements. If a page builder is the source, reduce nested sections/columns or move that page to a hand-built template. Aim to cut depth, not just count.
  4. Don't keep hidden UI in the DOMMount modals, mega-menus, and inactive tab panels only when they're opened, and unmount them after. display: none still costs you on every style recalculation because the nodes are still in the tree.
  5. Paginate or lazy-render below-the-fold sectionsBreak enormous pages into pages or load sections as they approach the viewport. content-visibility: auto lets the browser skip rendering work for off-screen blocks until they're needed.

Stop it recurring

Set a rough node-count budget (Lighthouse warns past ~800 and fails past ~1,400) and watch it when adding builder sections or large lists.

Related errors