blocking="render" 不是标准 html 属性，浏览器完全不识别，加了也无效；真正控制脚本渲染阻塞的只有 async、defer 和默认同步模式。
script 的 blocking="render" 是个不存在的属性
直接说结论：blocking="render" 不是标准 HTML 属性，浏览器完全不识别，加了也无效。你看到的可能是拼写混淆（比如和 async、defer 搞混），或是某框架/构建工具自定义的非标准 data 属性，但它对脚本加载、执行、渲染阻塞行为零影响。
真正控制 script 渲染阻塞的只有三个标准属性
浏览器只认 async、defer 和默认的同步执行模式。它们决定脚本何时下载、何时执行、是否阻塞 HTML 解析与页面渲染：
-
async：脚本异步下载，下载完立刻执行（可能中断 HTML 解析，也可能在 DOM 构建中途执行）；适合完全独立、无依赖的脚本（如统计代码） -
defer：脚本异步下载，但等到 HTML 解析完成、DOM 构建完毕后、DOMContentLoaded触发前按顺序执行；适合需要操作 DOM 且有执行顺序要求的脚本 - 不加任何属性（默认）：脚本同步下载 + 同步执行 —— 遇到就暂停 HTML 解析，等它下载、编译、执行完才继续；这是最重的阻塞方式
为什么有人误写 blocking="render"？常见混淆点
这个写法大概率源于对以下概念的误解：
- 把
loading="lazy"（用于<img>或<iframe></iframe>）错记成 script 的属性 - 看到某些 SSR 框架（如 Next.js）在
<script></script>组件里支持strategy="afterInteractive"这类配置，误以为是原生 HTML 属性 - 将 CSS 的
media="print"或disabled状态类比到 script 上，以为也能“条件性阻塞” - 调试时手动加了
blocking="render"试图“标记用途”，但没意识到它只是无意义字符串
想真正减少 script 对渲染的影响？这样做才有效
别折腾不存在的属性，聚焦真实可落地的优化手段：
- 首屏关键 JS 用
defer（尤其含 DOM 操作的初始化逻辑） - 第三方分析、广告、埋点脚本一律用
async，并确保它们不修改全局状态或依赖其他脚本 - 超大脚本（如图表库、编辑器）考虑动态 import() 懒加载，配合
await import('./chart.js') - 检查 network 面板：确认 script 请求是否被卡在 queue 中（常见于大量同域并发请求），可通过拆分域名或使用
rel="preconnect"优化 - 服务端启用 Brotli 压缩 + HTTP/2，缩小传输体积本身就能缩短阻塞窗口
真正影响用户感知的是白屏时间（FCP）和可交互时间（TTI），而不是某个虚构属性有没有加对。
