Skip to content
Issue docs

Excessive DOM size

Standardexcessive_dom_sizeIssue 192

What is this issue?

The page has more than 1,500 HTML elements.

Every tag in a page — each <div>, <span>, <li>, <svg> path and so on — becomes a node in the browser's DOM. The more there are, the more work the browser does to style, lay out and repaint the page, every time anything changes.

For a page to pass this check:

  • It has no more than 1,500 elements in total, counting <html>, <head> and <body> themselves.

1,500 is the long-standing Lighthouse warning threshold. The finding also reports how deeply the elements are nested and the largest number of children any one element has, which usually point at where the bulk comes from.

What it measures. When a scan renders pages in a browser, the count is of the page after its JavaScript has run — the DOM the browser actually works with. Otherwise it is the HTML the server sent; a page that builds most of its content with JavaScript may then be counted lower than it really is.

Why it matters

  • Slower rendering. Style calculation and layout scale with the number of elements. A large DOM delays the first render and makes every later change more expensive.

  • Slower interactions. Clicking, typing and scrolling trigger style and layout work. On a large DOM that work takes longer, which shows up in Interaction to Next Paint (INP), a Core Web Vital.

  • More memory. Each element costs memory, which matters on low-end phones where pages are most likely to be killed and reloaded.

  • More HTML to download and parse. A large DOM usually means a large document, often repeated markup: mega-menus duplicated for mobile and desktop, long lists rendered in full, or icons inlined as SVG hundreds of times.

Effect on the health score

This is a standard issue. It deducts from the Delivery & Trust score for each affected page.

How to fix it

  1. Find where the elements are. In Chrome DevTools, run document.querySelectorAll('*').length in the console, and look at the largest sections in the Elements panel. The widest-parent number on the finding usually points at a long list or table.

  2. Paginate or lazy-render long lists. Product grids, comment threads and tables with hundreds of rows can show the first page and load the rest on demand, or use list virtualisation.

  3. Stop duplicating markup. A navigation rendered twice (once for desktop, once for mobile) and hidden with CSS doubles its cost. Render it once and restyle it.

  4. Flatten wrappers. Page builders often nest five <div>s where one would do. CSS grid and flexbox rarely need extra wrappers.

  5. Reuse SVG icons with <use href="#icon"> from a sprite instead of inlining the full SVG each time.

  6. Defer off-screen content with content-visibility: auto on large below-the-fold sections, so the browser skips their layout until needed.

Examples

Example 1: A product listing with 600 items

<ul class="products">
  <li><a href="/p/1"><img src="..."><span>Name</span><span>Price</span></a></li>
  <!-- ... 599 more ... -->
</ul>

Reported: about 3,000 elements from the list alone. The finding's widest parent is the <ul> with 600 children.

Example 2: A typical article

An article page with a header, navigation, 30 paragraphs, a few images and a footer.

Passes: a few hundred elements.

Example 3: Exactly 1,500 elements

Passes: the check reports counts above 1,500.

Example 4: A deeply nested page-builder layout

<div class="section"><div class="row"><div class="col"><div class="inner">
  <div class="widget"><div class="widget-wrap"><p>Text</p></div></div>
</div></div></div></div>

Reported only if the total passes 1,500, but the depth recorded on the finding shows how much nesting is adding to it.

How PixyScan detects this

  1. Counts every element in the page, the same way document.querySelectorAll('*').length does in a browser: <html>, <head>, <body>, <script> and <style> included; text and comments excluded.

  2. Reports when the count is above 1,500. Exactly 1,500 passes.

  3. Measures the deepest nesting, counting <html> as level 1.

  4. Measures the widest parent — the largest number of element children directly under one element.

  5. Records all three numbers on the finding.

Under the browser engine the count is of the rendered page; otherwise of the HTML as served.

What we store

Storage Level

Page Level

Database Table / Prisma Model

audit_issues.details

Stored Fields

Field Type Description
message String The element count, depth and widest parent
elementCount Int Total elements in the page
maxDepth Int Deepest nesting level, with <html> as 1
maxChildren Int Most element children under one element
limit Int The threshold, 1500

Detection Dependencies

  • The HTML document (rendered DOM under the browser engine, served HTML otherwise)

Note

Kept on the finding only. The numbers are not stored in a column of their own.

Further reading