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 87ms. At the high end (>p98): INP 132ms. 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?
DOM elements correlate with the INP. On the smallest pages, 89% of sites pass the INP. On the biggest pages, 83% do. The decline is gradual. There is no point where sites suddenly start failing.
Chrome field data from 189,915 sites, representing millions of real page loads. How we measured.