A page has too many or deeply nested HTML elements
In the reportExcessive DOM size
dom_size_excessive · Review item
This appears when a page's HTML, as served, has more elements than the limit, nests them deeper, or puts more children under one element: by default more than 1,500 elements, 32 levels or 60 children. A large page structure makes the browser's rendering work more expensive, on load and after each interaction. Remove markup you do not need, and split long lists.
Severity: Low. For review: the counts come from the HTML as served, not from the page the browser builds.
Why it matters
web.dev's guide to Interaction to Next Paint says rendering work tends to grow with the size of the DOM, and that a large DOM can make the updates after an interaction very expensive; it suggests flattening the DOM and rendering off-screen parts later with content-visibility.
What to do
- Look at the finding: it shows which measure passed its limit, the value, and the path to the deepest element or the busiest parent.
- Remove wrappers that only add nesting, and markup that is hidden on every screen size.
- Split very long lists, such as all products or comments on one page, into pages, or load more on request.
When to leave it as it is: if the page is long on purpose, such as a full price list, and it responds quickly in your browser, you can leave it.
What we read
We read the HTML of each crawled page as served, without running JavaScript, and count its elements, the deepest nesting and the most children under one element. Content inside <template>, <noscript> and <iframe> is not counted.
A page is reported when any of the three passes its limit: 1,500 elements, 32 levels or 60 children by default. The limits are audit settings, recorded with each audit. Pages that are only an empty shell for JavaScript are left out.
A page is marked as not checked when its HTML could not be read in full, for example because it contains unsupported SVG markup, <select> or <math>, has more than 100,000 elements or is nested very deeply, so the largest pages are often not checked.
Example & evidence
Illustrative example — one page's counts, not a live audit.
https://bakery.example/products/ measured:
elements: 4,812 (limit 1,500)
deepest nesting: 21 levels (limit 32)
most children under one element: 312 (limit 60)The page has more elements than the limit, and one list holds 312 items, so it is reported with the path to that list.
A possible correction: show 48 products per page, with links to the next pages.
Confirm & check again
Check for yourself: open the page, then the console in your browser's developer tools, and run document.querySelectorAll('*').length; the browser's count includes what JavaScript adds, so it may be higher than ours.
Check again: Full audit — run a new audit of the site. The finding closes when the page is crawled again, its HTML is read in full, and all three measures are within their limits; a page that becomes an empty shell for JavaScript also closes it. A page that cannot be read in full, or is not crawled again, keeps the finding open. A higher limit in your audit settings also stops the finding; the finding records the limits it used.
Limits & sources
The counts come from the HTML as served, not the page the browser builds, so elements added by JavaScript are missed. Our parser does not close list items, paragraphs and table cells whose end tags are left out, as browsers do, so such pages can show more depth and fewer children than they have. Rendering cost itself is not measured.
Confidence: Medium because the counts come from the served HTML, which can differ from the page the browser builds.
Sources
- web.dev, Optimize Interaction to Next Paint — says rendering work tends to scale with DOM size and a large DOM can make rendering updates after an interaction very expensive, and suggests flattening the DOM and using content-visibility. Checked 28 September 2026.
Editorial review: 29 September 2026