SSR渲染阻塞控制优化全解析

本文彻底澄清了一个常见误区：HTML 中并不存在标准属性 `blocking="render"`，它既不被浏览器识别，也无法影响脚本的渲染阻塞行为——所有相关尝试都是徒劳的；真正决定脚本加载与执行时机、进而直接影响页面渲染性能的，只有三个标准机制：`async`（异步立即执行，适合无依赖脚本）、`defer`（异步下载、DOM 构建完成后按序执行，适合需操作 DOM 的逻辑）和默认同步模式（最重阻塞，应尽量避免）；文章还剖析了该误写背后的典型混淆来源，并给出切实可行的优化路径——从合理选用 `defer`/`async`、动态导入懒加载，到网络层压缩与预连接，直击白屏时间（FCP）和可交互时间（TTI）等真实用户体验指标。

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"（用于 或