本文详解浏览器中脚本执行与渲染的时序关系，阐明为何 requestAnimationFrame 可能早于外部脚本执行、如何利用 <head> 中的同步脚本实现渲染阻塞，以及现代 blocking="render" 属性的实践用法。
本文详解浏览器中脚本执行与渲染的时序关系，阐明为何 `requestanimationframe` 可能早于外部脚本执行、如何利用 `
` 中的同步脚本实现渲染阻塞，以及现代 `blocking="render"` 属性的实践用法。在构建高性能、无闪烁的 Web 应用时，一个常被忽视却至关重要的细节是：HTML 解析、JavaScript 执行与浏览器渲染并非严格串行，尤其当脚本位置与加载策略不当时，渲染可能抢先发生——这正是导致 UI 闪烁、布局错乱或 DOM 访问异常的根源。
渲染抢占的本质：解析、执行与渲染队列的协作机制
浏览器采用单线程事件循环，但将任务划分为多个队列：HTML 解析器队列、JS 执行队列、渲染更新队列（包括 RAF 回调）。关键在于：
- 外部经典脚本（<script src="...">）默认是 parser-blocking：HTML 解析器会暂停，等待脚本下载并执行完毕后才继续解析后续 HTML。
-
但它不自动是 render-blocking：除非脚本位于 <head> 中，否则其执行不强制延迟首次渲染（First Paint）或后续帧更新。这意味着：
- 若 <head> 中存在 requestAnimationFrame 回调，它可能在 <body> 中外部脚本执行前就被调度并执行；
- 尤其当外部脚本较大或网络较慢时，RAF 回调极易“抢跑”，造成逻辑依赖错位（如尝试操作尚未加载的 DOM 元素）。
以下示例清晰展示了该现象：
<html>
<head>
<script>
requestAnimationFrame(() => {
console.log('RAF fired before script.js!');
});
</script>
<!-- 此处 script.js 若体积大或延迟高，RAF 很可能先执行 -->
<script src="./script.js"></script>
</head>
<body>
<h1>Hello world</h1>
</body>
</html>控制台输出顺序不可预测：RAF fired... 可能先于 SCRIPT EXECUTED，证明渲染阶段已介入。
✅ 正确方案一：将关键脚本置于 <head> 实现渲染阻塞
根据 HTML 规范，位于 <head> 中的同步脚本（非 async/defer）具有 render-blocking 能力（Chrome/Edge 支持，Firefox 当前暂未实现）。这意味着浏览器会推迟首次渲染，直至该脚本执行完毕。
✅ 推荐写法：
<head>
<!-- 渲染阻塞脚本：确保 DOM 就绪前不渲染 -->
<script>
// 关键初始化逻辑（如主题切换、CSS 注入、DOM 预处理）
document.documentElement.classList.add('js-ready');
</script>
<script src="./critical.js" defer></script> <!-- 或直接内联 -->
</head>⚠️ 注意：defer 脚本虽在 DOM 解析后执行，但不参与 render-blocking；只有 <head> 中的同步、非异步脚本才具备此能力。
✅ 正确方案二：使用 blocking="render"（现代标准）
为更精细地控制脚本行为，HTML 新增 blocking="render" 属性（MDN 文档），允许脚本放弃 parser-blocking，但仍保持 render-blocking——特别适合模块化、需延迟加载但又不能破坏渲染时序的场景：
<head> <script blocking="render" type="module" src="./app.mjs"></script> <!-- 或用于 defer 脚本 --> <script blocking="render" defer src="./vendor.js"></script> </head>
✅ 效果：
- type="module" 或 defer 脚本不再阻塞 HTML 解析（提升首字节时间 TTFB）；
- 但浏览器仍会等待其执行完成，才进行首次渲染和后续 RAF 调度；
- 当前仅 Chromium 内核支持（Chrome 125+），Firefox/Safari 正在跟进（参见 WHATWG Issue #10034）。
⚠️ 实践建议与避坑指南
- 避免在 <body> 底部放置关键初始化脚本：即使它“最后加载”，也无法阻止 <head> 中 RAF 的提前触发；
- 慎用 document.write() 或动态 appendChild(<script>)：它们会中断解析并引发不可预测的渲染时机；
- 验证渲染时序：使用 Chrome DevTools 的 Performance 面板 → 启用 “Rendering” 和 “Frames” 轨迹，观察 Parse HTML、Evaluate Script、Layout、Paint 的精确时序；
- 服务端渲染（SSR）/静态生成项目：优先通过内联关键 JS 或 blocking="render" 确保 hydration 前的视觉一致性；
- 兼容性兜底：对不支持 blocking="render" 的浏览器，回退至 <head> 同步脚本 + document.readyState === 'interactive' 检测。
总之，掌控渲染时序不是“阻止浏览器工作”，而是主动声明脚本的语义优先级：告诉浏览器“此脚本的结果必须可见于用户第一眼”。理解 parser-blocking 与 render-blocking 的差异，并善用 <head> 位置与新兴标准，是构建稳定、专业 Web 应用的底层基石。
