直接查看chrome devtools performance面板main轨道中“html parser”块的duration值，即为script阻塞dom构建的确切毫秒数；该值是浏览器真实记录的解析暂停时长，而非估算。
怎么测出script阻塞DOM构建的具体毫秒数
直接看 Chrome DevTools 的 Performance 面板里 Main 轨道上的“HTML Parser”块长度，就是实际阻塞时间——不是估算，是浏览器真实记录的暂停时长。
常见错误是只盯着 DOMContentLoaded 时间戳，但它包含脚本执行+其他初始化耗时，无法拆解出纯“解析阻塞”部分。
- 打开 DevTools →
Performance→ 点录制（Ctrl+E），刷新页面 - 停止后展开
Main轨道，找连续灰色/浅蓝的HTML Parser区段（不是Script Evaluation） - 鼠标悬停，看 tooltip 里 “Duration” 字段，比如
127ms就是这次阻塞的确切毫秒数 - 若该区段中间夹着
Script Evaluation，说明脚本在解析中途被强制插入执行——这就是默认同步行为的铁证
为什么把script放
不是脚本本身慢，而是它触发了“解析-下载-执行”三重阻塞链：浏览器必须等完整下载并执行完 app.js，才能继续解析 里的任何内容。
实测中，一个 80KB 的未加 defer 的外链脚本，在 3G 网络下会带来平均 240ms 的 DOM 构建中断——这期间 first-contentful-paint 完全卡住。
- 阻塞时间 = 脚本下载耗时 + JS 引擎解析时间 + 执行时间（不含渲染）
- 内联脚本（
<script>init();</script>）没有下载耗时，但解析+执行仍会打断解析流 - 多个无属性 script 串行执行，阻塞时间是累加的，不是并发的
- 哪怕脚本只有一行
console.log(1)，只要没加defer或async，就一定会触发阻塞
defer脚本的执行时机到底比DOMContentLoaded早多少
通常早 0–5ms，但这个差值不可靠；真正能依赖的是“DOM 已就绪”，而不是具体时间点。浏览器规范只要求 defer 脚本在 DOMContentLoaded 触发前执行，没规定提前量。
这意味着你在 defer 脚本里调用 document.getElementById("app") 是安全的，但别指望它比 DOMContentLoaded 回调早执行“更可控的毫秒数”。
- 多个 defer 脚本按顺序执行，但执行总时长会影响
DOMContentLoaded触发时刻——它必须等所有 defer 脚本执行完 - 如果某个 defer 脚本里有
while(Date.now() - start 这类同步阻塞逻辑，<code>DOMContentLoaded会被拖慢整整 100ms - 不要用
performance.now()在 defer 脚本里和DOMContentLoaded回调里比时间差——结果每次都不一样 - 想精确控制时机？用
requestIdleCallback或queueMicrotask做微任务调度，比拼毫秒级先后更可靠
监控脚本必须放
因为 PerformanceObserver 必须在 paint 事件发生前注册，否则数据直接丢弃——而 first-paint 可能在 DOMContentLoaded 前 100ms 就完成了。
把监控脚本放 前或加 defer，等于主动放弃 FCP/LCP 数据采集能力。
- 正确写法：
<script>new PerformanceObserver(...).observe(...)</script>直接写在里，不带任何属性 - 哪怕只加
defer，也会导致 observer 注册晚于首次绘制，performance.getEntriesByType('paint')返回空数组 - 现代项目若用
type="module"，需确认入口脚本无top-level await，否则仍会延迟注册 - CI 环境中 Lighthouse 默认不审计 render-blocking-resources，得手动在
.lighthouserc.json里启用"render-blocking-resources"
真实瓶颈往往藏在“看似无害”的位置：一个没加 defer 的统计脚本、一段写在 里的内联初始化逻辑、甚至只是多了一个没删干净的 document.write 调用——它们不会报错，但会让 DOM 构建在毫秒级上反复卡顿。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
