Skip to content

diagnostic · one of 50 free, no counter

DOM size

Lighthouse says excessive DOM size - but where is all of it?

Lighthouse tells you the page has too many elements and points at one of them. This walks the whole document and says where they are: the total against the 800 and 1,400 lines Lighthouse scores on, the deepest branch against its 32 levels, the parent with the most children against its 60, and the subtrees holding the most weight, each one a click away from being shown on the page.

Reach it Press ⌘ + K on any tab and type dom size. Ctrl + K on Windows and Linux

Element count, depth and the heaviest branches against Lighthouse’s budget
reads the document as it stands, one walk
limits Lighthouse's: 800 and 1,400 elements, 32 deep, 60 children
writes nothing
sends nothing
skips LoupeKit's own nodes and shadow roots
cap stops at 60,000 elements and says so
section#about

What this actually is

After a Lighthouse run flags excessive DOM size and the one element it names is not the problem, on a page that grew a mega-menu, a long table or an infinite list, or before shipping a component that repeats. Reach for Performance in devtools instead when the question is how long the layout took rather than how big the tree is.

section#asked

Asked about this diagnostic

Why is my count different from the one in the Lighthouse report?

Lighthouse counts once, at the end of its own load, in its own browser. This counts the document you are looking at, after whatever the page added since - a menu opened, a list scrolled, a widget hydrated - and it does not descend into shadow roots. The limits are the same; the moment is not, so the two numbers are close rather than equal.

What does it mean that a wrapper is skipped in favour of its child?

A page wrapper holds nearly every element on the page, so a ranking by size would list body, then main, then the first div, and say nothing. Where one child carries nearly all of a parent's weight, the child is listed instead, which walks the ranking down to the branch that is actually large.

Does a page over 1,400 elements have a problem?

Not necessarily. It is the point where Lighthouse's audit scores worst, because a large tree costs memory and makes style recalculation and layout slower. A long data table can be over it for a good reason; a marketing page usually is not, and the heaviest subtree is where to look first.

how to use dom size

  1. Open DOM size on the page Lighthouse flagged; it reads the document when it opens.
  2. Read the three checks: elements, deepest nesting and widest parent, each beside its limit.
  3. Go down the heaviest subtrees, and reveal the one that holds the most on the page.
  4. Fix that branch, then press Run again to see the count move.