Chrome DevTools 中 document.querySelectorAll('*').length 超过 2000 会引发明显卡顿，低端安卓设备 layout 耗时非线性飙升；首屏 DOM 节点须 ≤500，深度应 ≤6，CI 中需自动化校验。
document.querySelectorAll('*').length 超过 2000 就该停手了
这不是建议，是 Chrome DevTools 里可复现的卡顿拐点。在低端安卓设备（如搭载联发科 Helio A22、2GB RAM 的机型）上，document.querySelectorAll('*').length 达到 2000 后，layout 阶段耗时会非线性翻倍——从 15ms 跳到 60ms+，首屏渲染明显卡顿。SSR 渲染后直接 hydration 的 SPA 更敏感，实测中 1800 个节点已触发连续两帧掉帧。
SPA 首屏必须压到 ≤500 个 DOM 节点
首屏节点数不是“越少越好”的模糊概念，而是硬性约束：超过 500，低端机上 JS 执行 + layout 合计耗时大概率突破 100ms，用户感知为明显延迟。关键在于“首屏”指 viewport 内实际渲染内容，不含懒加载区域或 v-if/ngIf 未激活分支。
- 用 Chrome DevTools → Elements → 右键任意节点 → “Show DOM properties”，看
node.depth和总节点数 - Vue/React 项目需在 mounted/useEffect 后执行
document.querySelectorAll('*').length，避开 SSR 静态 HTML 计数干扰 - CMS 输出的 wrapper（如
<div class="container"><div class="row"><div class="col">...</div></div></div>）是重灾区，优先删或用 CSSgap替代
DOM 深度比总数更危险：别让 node.depth > 6
深度超 6 层时，getComputedStyle() 平均耗时翻倍；深度达 12，低端安卓单次调用可能卡顿 80ms 以上。浏览器计算样式要递归回溯祖先，每深一层，选择器匹配、继承属性传播、布局上下文创建开销都叠加。
- 常见高危结构：
body > div > div > div > .content > .list > .item—— 这种纯 class 堆叠毫无语义，且深度已达 7 - 用
<section></section>、<article></article>、<nav></nav>替代无意义div，它们不增加深度，还能缩短选择器路径 - CSS 选择器写成
.card .title，别用div div h2—— 后者强依赖结构深度，一改就崩
CI 中加断言比人工检查更可靠
靠开发者每次手动跑 document.querySelectorAll('*').length 不现实。把检测逻辑塞进 CI 流程，才能守住底线。
立即学习“前端免费学习笔记（深入）”；
- 在 Puppeteer 或 Playwright 测试脚本里加入断言：
expect(await page.$eval('body', el => document.querySelectorAll('*').length)).toBeLessThan(2000) - 对首屏页面单独校验：
expect(await page.$eval('body', el => { const rect = el.getBoundingClientRect(); return [...document.querySelectorAll('*')].filter(n => n.getBoundingClientRect().top - 注意：Node.js 环境无法直接访问 DOM，必须在真实浏览器上下文中执行，否则拿到的是服务端字符串，计数无效
