HTML异步会影响脚本阻塞吗_HTML异步适配脚本阻塞策略【最全】

作者：袖梨 2026-08-04

HTML异步会影响脚本阻塞吗_HTML异步适配脚本阻塞策略【最全】的重点在于把前置条件、操作顺序和容易误判的地方分清楚。

HTML脚本阻塞取决于执行时机：无async/defer会同步阻塞解析；async仅异步下载但执行仍阻塞且无序；defer异步下载且按序在DOM解析后执行，最安全。

HTML 异步本身不会消除脚本阻塞，它只是把“阻塞点”从下载阶段转移到执行阶段，或干脆移出 HTML 解析主线程——关键看用的是 async 还是 defer，以及脚本是否依赖 DOM 或其他脚本。

不加 async/defer 的 script 为什么一定阻塞

浏览器解析 HTML 时，遇到没有 async 或 defer 的 <script> 标签，会立刻暂停 DOM 构建，同步下载、解析、执行脚本。哪怕脚本只有一行 console.log(1)，也会卡住后续所有 HTML 解析和渲染。

  1. DOM 构建中断 → document.getElementById 可能返回 null
  2. 页面白屏时间直线上升，尤其当脚本放在 <head> 中
  3. 多个无属性脚本按顺序串行加载，总延迟 = 所有下载 + 执行时间之和

async 脚本执行时仍会阻塞 DOM 解析

async 只解决“下载不阻塞”，不解决“执行不阻塞”。脚本一旦下载完成，浏览器会立即中断当前 HTML 解析，执行该脚本。

  1. 执行时机不可控：谁先下完谁先执行，不保证顺序
  2. 若脚本 A 依赖脚本 B 声明的全局变量（如 lodash），async 下可能报 ReferenceError
  3. 适合完全独立的脚本，比如统计代码、广告 SDK、错误监控 —— 它们不读 DOM、不改 DOM、不依赖其他 JS
  4. 注意：async 对内联脚本（无 src）无效，只作用于外部脚本

defer 是更安全的“非阻塞主逻辑”方案

defer 让脚本异步下载，但推迟到 DOM 解析完成后、DOMContentLoaded 触发前，再按书写顺序执行。

  1. 不阻塞 HTML 解析 → 页面能持续构建 DOM、逐步渲染
  2. 保证执行顺序：多个 defer 脚本按 <script defer src="a.js"></script> 出现顺序执行
  3. 仅对带 src 的外部脚本生效；内联脚本加 defer 会被忽略
  4. 适合主业务逻辑、Vue/React 初始化、需要操作完整 DOM 的代码

容易被忽略的细节和兼容性坑

很多人以为加了 async 或 defer 就万事大吉，其实还有几个硬性限制和隐性行为：

  1. document.write() 在 async 或 defer 脚本里会直接报错或清空整个页面，必须彻底移除
  2. defer 脚本在 IE9- 中被忽略，降级为同步加载；若需兼容老 IE，得靠动态插入或条件注释
  3. 服务器返回 404 的 defer 脚本，会触发 error 事件但不中断后续脚本执行；而 async 404 同样不中断，但没机会重试
  4. type="module" 脚本默认表现类似 defer（即使没写），但模块脚本之间有严格的依赖顺序和顶层 await 支持，别混用 defer 和 type="module"

真正决定是否阻塞的不是“异步”这个词，而是脚本何时执行、是否依赖上下文、以及浏览器是否允许它插队。别只看有没有 async，得看它执行那一刻，DOM 是否 ready、变量是否已定义、用户是否还在等首屏内容。

相关文章

精彩推荐