DOM too large

Memory, proportional to the node count, which matters most on the low-end devices where it is already scarce.

Style recalculation, which the browser runs whenever anything changes and which considers every element that might be affected.

Layout, which is the expensive pass and which a deep tree makes more expensive still.

Query performance in any script that searches the document, which frameworks do more than their authors realise.

The symptom is an interaction that lags rather than a page that loads slowly, which is why a load-focused audit misses it.

Wrapper elements added by component composition, where each component contributes a container and nesting multiplies them.

A list rendering every item rather than the visible window — a table with ten thousand rows is ten thousand rows in the tree.

Repeated markup for layout that a grid or flex rule would express in one element.

Utility-class markup where a single visual element is built from several nested ones.

Content generated by a rich text editor, which produces deeply nested markup for simple formatting.

A deeply nested tree makes style inheritance and layout more expensive per element than a shallow one with the same count.

Deep nesting also makes selector matching slower, since a selector has to be evaluated against each ancestor.

It frequently comes from the same cause as the count: composition adding a wrapper at each level.

Flattening the wrappers usually reduces both at once, which is why the two are reported together.

A tree more than about thirty levels deep is worth looking at regardless of the total count.

Render only the visible window of a long list and replace the rest as the visitor scrolls, which is the single largest reduction available on a data-heavy page.

Paginate rather than rendering everything, which is simpler and frequently better for the reader too.

Remove wrapper elements that exist only to carry a style a parent could carry instead.

Use the content-visibility property on below-the-fold sections, which lets the browser skip their layout until they are needed.

Check whether a component library is adding containers you do not need, since that is where the multiplication starts.

In the browser console, count the elements in the document — the total is the number this problem is about.

Measure the maximum depth as well, which frequently tells a clearer story than the count.

Record a performance profile while interacting and look at the time spent in style and layout.

Compare a page with a long list against one without, which isolates whether the list is the cause.

Check on a low-end device rather than a development machine, where the cost is largest and the symptom obvious.

`performance.dom_size` reports the served DOM size, which is this problem directly.

`performance.request_count` and `performance.page_weight` describe the rest of the page's cost.

`performance.core_web_vitals` reports the rendering measurements, where a large tree shows up in interaction responsiveness rather than in load time.

`performance.unused_css` is reported alongside, since a large stylesheet and a large tree compound each other in style calculation.

The measurement is of the served markup, so elements added by script after load are not counted.

It is not a ranking factor in itself, and no search engine publishes a node count threshold.

It is not a load-time problem: the markup compresses well and transfers quickly.

It is not caused by having a lot of content, which is usually a small part of the total.

It is a runtime cost paid on every interaction, which is why it is measured and reported rather than ignored.

Assistive technology builds its own tree from the document, so a large one is slow to navigate as well as slow to render.

A screen reader reading through thousands of elements offers a list of headings and landmarks that is proportionally unusable.

Deeply nested markup also produces announcements about entering and leaving groups that carry no meaning for the reader.

Which means flattening the tree improves both, and the accessibility improvement is the one users notice.

A table rendered as nested containers rather than as a table is the worst version: large, deep, and announced as nothing in particular.