The State of Web Vitals

DOM size

How many elements the DOM holds after load.

Field data PhoneDesktopAll Scope All sites Q1 2026 edition · All devices field outcomes
Metric LCP INP CLS
1

At a glance the headline numbers for DOM size

How many elements the DOM holds after load.

694
on the typical site
half of sites sit at or below
1,205
1 in 4 sites exceed this
the top quarter
6,478
the heaviest 1%
the long tail
94,748
sites measured
all-device field data

The typical page contains 694 DOM elements.

The State of Web Vitals · Q1 2026 · 94,910 sites · all devices field datacorewebvitals.io/state-of-cwv
2

Distribution & median CLS site count and median CLS at each level of DOM size

0.00 0.04 0.08 0.11 0.15
0.1
0 18689 37378
1–2 3–6 7–13 14–31 32–73 74–173 174–408 409–962 963–2272 2273–5361 >p98
Good (≤0.1) Needs improvement Poor (>0.25) Site count
The State of Web Vitals · Q1 2026 · 94,910 sites · all devices field datacorewebvitals.io/state-of-cwv
3

Passing CLS by DOM size which level passes the CLS most often

DOM sizeSitesPassing CLSCLS
3–6 603 89% 0.00
7–13 700 85% 0.00
14–31 825 88% 0.00
32–73 1,947 86% 0.00
74–173 4,820 86% 0.00
174–408 16,151 91% 0.00
409–962 37,378 89% 0.00
963–2272 24,207 86% 0.01
2273–5361 6,223 86% 0.01
>p98 1,893 80% 0.02
Good Needs Improvement Poor Faded rows: under 100 sites

DOM size 694. p75 1,205. p99 6,478.1. At the low end (3–6): CLS 0.00. At the high end (>p98): CLS 0.02. computed

The State of Web Vitals · Q1 2026 · 94,910 sites · all devices field datacorewebvitals.io/state-of-cwv
4

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, 90% of sites pass the INP. On the biggest pages, 82% do. The decline is gradual. There is no point where sites suddenly start failing.

Go fix it Fix excessive DOM size → Yield to the main thread →
Related signals Iframes per page → Media source → Image fetchpriority → Uses @import → Chrome field data from 94,910 sites, representing millions of real page loads · How we measured