At a glance the headline numbers for DOM size
How many elements the DOM holds after load.
The typical page contains 695 DOM elements.
Distribution & median INP site count and median INP at each level of DOM size
Passing INP by DOM size which level passes the INP most often
DOM size 695. p75 1,202. p99 6,465. At the low end (3–6): INP 46ms. At the high end (>p98): INP 69ms. computed
Why this matters for the Core Web Vitals, and where to start fixing it
A large DOM makes rendering work scale with the page. That hits two Core Web Vitals. The interaction side is INP. A click usually changes the DOM. Before the browser can paint the result it has to recalculate styles and update the layout. More elements means more work in that recalculation, so the response to every click lags. This cost repeats on every interaction for the whole session.
The loading side is LCP. On the first render the browser parses, styles and lays out every element, even the ones below the fold. The main content waits for that work (render delay in the LCP). If the page only rendered what is visible, the first paint and every later click would be faster. Pagination, virtualization and fewer wrapper divs all work towards that.
How does DOM size affect the Core Web Vitals?
Passing INP barely moves across the range: 98% at one end, 98% at the other. This signal does not separate passing sites from failing ones.
The effect is bigger on CLS. On the smallest pages, 81% of sites pass it. On the biggest pages, 73% do.
Chrome field data from 189,915 sites, representing millions of real page loads. How we measured.