<b>DOM size predicts render lag better than page weight</b>

<b>DOM size predicts render lag better than page weight</b>
We regressed render-queue time against three variables on 138 JS-heavy sites.

— DOM node count: r ≈ 0.67 (strongest) ▓▓▓▓▓▓▓░░░
— Total JS bytes: r ≈ 0.58 ▓▓▓▓▓▓░░░░
— Image weight: r ≈ 0.12 ▓░░░░░░░░░

Pages over 3,000 DOM nodes sat in the render queue a median 8.9 days longer than sub-1,000-node pages. Image weight barely moved the needle — Googlebot defers images, not layout.

The mechanism: rendering cost scales with the layout/paint tree, and a bloated DOM (nested divs, component soup) inflates it independent of byte size.

So what: a 'light' 400 KB page with 5,000 nodes renders slower than a 1.2 MB page with 900. Profile node count in your audit, not just transfer size.