浏览器中 HTML 解析、脚本执行与样式布局/绘制并非严格串行，requestAnimationFrame 可能在外部脚本加载前触发，导致渲染早于关键逻辑执行，引发 UI 闪烁或状态不一致。本文详解 render-blocking 机制、blocking="render" 属性及可靠防抖策略。
浏览器中 html 解析、脚本执行与样式布局/绘制并非严格串行，`requestanimationframe` 可能在外部脚本加载前触发，导致渲染早于关键逻辑执行，引发 ui 闪烁或状态不一致。本文详解 render-blocking 机制、`blocking="render"` 属性及可靠防抖策略。
在构建高性能、状态敏感的 Web 应用时，开发者常默认「脚本执行完毕后才会渲染」——但事实并非如此。HTML 规范中，外部经典脚本（<script src="..."></script>）默认是 parser-blocking 的，即 HTML 解析器会暂停并等待该脚本下载、编译与执行完毕，再继续解析后续 HTML；但它不自动成为 render-blocking，除非满足特定条件。
✅ 什么是 render-blocking？
Render-blocking 指：浏览器必须完成该脚本的执行，才能进入样式计算（Style）、布局（Layout）和绘制（Paint）阶段。换言之，即使 DOM 已解析完成，若存在未执行完的 render-blocking 脚本，页面将保持空白或冻结状态，不会呈现任何视觉内容。
根据 HTML 规范，仅当 <script></script> 标签位于 中且为外部脚本（非内联）时，才具备 render-blocking 行为（Chrome/Edge 支持，Firefox 当前暂不支持该特性）。
以下示例可验证此行为（使用 <iframe srcdoc></iframe> 避免 StackBlitz 环境干扰）：
<iframe srcdoc="
<html>
<head>
<script>
requestAnimationFrame(() => parent.postMessage(['RAF fired'], '*'));
</script>
<script src='data:text/javascript,console.log(`SCRIPT EXECUTED`);'></script>
</head>
<body><h1>HELLO</h1></body>
</html>">
</iframe>在 Chrome 中，你将稳定看到：
SCRIPT EXECUTED RAF fired
说明 requestAnimationFrame 回调被推迟到了脚本执行之后 —— 因为 中的外部脚本已触发 render-blocking。
⚠️ 注意事项与兼容性
-
Firefox 不支持 render-blocking：上述
中外部脚本的行为在 Firefox 中仍可能被 RAF 抢先触发，需额外防护。 -
内联脚本不 render-blocking：即使写在
中，<script>...</script>内联代码仅 parser-blocking，不阻塞渲染。 -
defer/async/type="module"脚本默认非 render-blocking：它们绕过 parser-blocking，但也失去 render-blocking 能力（除非显式声明）。
✅ 推荐方案：blocking="render"（现代标准）
HTML 新增的 blocking="render" 属性，允许非 parser-blocking 脚本（如 defer、async、模块）主动声明为 render-blocking：
<head>
<!-- 此脚本异步加载，但强制 render-blocking -->
<script defer blocking="render" src="./init.js"></script>
<!-- 或配合 RAF 安全初始化 -->
<script>
// 确保 DOM 就绪 + 渲染被阻塞后才运行
document.addEventListener('DOMContentLoaded', () => {
requestAnimationFrame(() => {
// ✅ 此处 DOM 已就绪，且无中间帧渲染干扰
initializeUI();
});
});
</script>
</head>✅ 当前支持：Chrome 125+、Edge 125+（CanIUse 数据）。Firefox 和 Safari 尚未实现，建议搭配降级逻辑。
✅ 最佳实践：防御性 RAF + 渲染控制
为兼顾兼容性与确定性，推荐组合策略：
// init.js —— 关键初始化逻辑
function initializeUI() {
document.body.classList.add('js-ready');
// ... 其他 DOM 操作、状态初始化
}
// 方案 1：等待 DOM 就绪 + 强制下一帧执行（最通用）
if (document.readyState === 'loading') {
document.addEventListener('DOMContentLoaded', () => {
requestAnimationFrame(initializeUI);
});
} else {
requestAnimationFrame(initializeUI);
}
// 方案 2：CSS 防抖（零 JS 依赖）
// 在 <head> 中添加：
// <style>body { visibility: hidden; } body.js-ready { visibility: visible; }</style>✅ 总结
| 场景 | 是否 render-blocking | 说明 |
|---|---|---|
<script src="x.js"></script> |
✅（Chrome/Edge） | 最简兼容方案，Firefox 不适用 |
<script blocking="render" defer src="x.js"></script> |
✅（Chrome 125+） | 未来标准，支持异步加载+渲染阻塞 |
<script src="x.js"></script> |
❌ | 仅 parser-blocking，不阻塞渲染，易 flicker |
requestAnimationFrame(...) 在 script 标签前 |
⚠️ 危险 | RAF 可能早于脚本执行，务必包裹在 DOMContentLoaded 或 requestIdleCallback 后 |
核心原则：不要依赖“脚本执行顺序 = 渲染顺序”；始终用 DOMContentLoaded + requestAnimationFrame 组合确保 DOM 就绪且无中间渲染；对关键首屏逻辑，优先采用 中 render-blocking 外部脚本，或等待 blocking="render" 全面落地后升级。
