dom构建延迟指html解析到document.readystate为interactive的耗时，即字节流转dom树时间，受html体积、同步脚本及内联资源影响；超300ms必致首屏滞后。
DOM构建延迟指的是什么
DOM构建延迟不是“页面白屏时间”，而是从 HTML 开始解析到 document.readyState 变为 interactive 的耗时，本质是浏览器将字节流转换为 DOM 树所花的时间。它直接受 HTML 体积、同步脚本阻塞、内联 CSS/JS 大小影响。若该阶段超过 300ms，首屏内容渲染必然滞后——哪怕资源都已缓存。
用 navigation API 精确捕获 domInteractive 时间点
别依赖 performance.timing.domInteractive，它在 Safari 和多数 WebView 中返回 0，且已被标准废弃。必须用 performance.getEntriesByType('navigation') 获取 PerformanceNavigationTiming 实例：
const nav = performance.getEntriesByType('navigation')[0];
if (nav && nav.domInteractive > 0) {
const domBuildTime = nav.domInteractive - nav.responseStart;
console.log('DOM构建耗时:', domBuildTime, 'ms');
}
-
nav.responseStart是服务端响应首个字节的时间，减它才能排除网络传输干扰 - 若
nav.type === 'back_forward'，responseStart可能为0，此时应跳过计算或 fallback 到nav.fetchStart - 该条目只在导航完成时存在，必须在
DOMContentLoaded后读取，否则可能为空数组
为什么不能在 DOMContentLoaded 回调里直接测 DOM 构建耗时
因为 DOMContentLoaded 触发时刻 ≈ domInteractive，但不等于。它实际发生在 DOM 树就绪 + 所有同步脚本执行完毕之后，中间夹着 JS 执行时间。你测到的可能是 “DOM构建 + 脚本执行” 总和，而非纯构建延迟。
- 常见误判：看到
DOMContentLoaded在 400ms 触发，就认为 DOM 构建花了 400ms —— 实际可能是 200ms 构建 + 200ms 执行了一个大<script></script> - 真正想定位瓶颈，得拆开看：
domInteractive - domLoading（纯解析） vsdomContentLoadedEventStart - domInteractive（同步脚本） - 如果后者显著偏高，说明问题不在 HTML，而在内联或同步加载的 JS 逻辑过重
监控脚本必须放在 最前面
任何晚于 HTML 解析开始的性能埋点都会漏掉关键阶段。比如把监控代码包在第三方 SDK 后面、或用 async 加载，first-contentful-paint 和 domInteractive 这类事件只触发一次，错过就永远丢失。
- 正确做法：在
第一行内联一段 ≤1.5KB 的 IIFE，直接调用performance.getEntriesByType或监听performance事件 - 禁用所有 DOM 操作（如
document.querySelector）和console.log，它们会拖慢主线程，反而抬高测出的延迟值 - 上报必须用
navigator.sendBeacon()，避免因页面卸载导致数据丢失
DOM构建延迟的根因往往藏在看不见的地方：一个未压缩的 200KB 内联 JSON、一段阻塞解析的同步 fetch、甚至服务端输出时多加了几个空格导致 HTML 字节膨胀。监控本身不解决问题，但能让你一眼锁定该砍哪一刀。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
