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 未激活分支。

Doc To HTML

使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

下载

• 用 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>）是重灾区，优先删或用 CSS gap 替代

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，必须在真实浏览器上下文中执行，否则拿到的是服务端字符串，计数无效

真正难的不是测出数字，而是说服产品和 UI 接受“这个卡片组件必须砍掉两层 wrapper”——因为性能瓶颈往往藏在视觉不可见的嵌套层级里。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！