async脚本不影响TTFB，因TTFB由服务端决定；它仅让浏览器在HTML接收后异步下载执行，不阻塞解析，但前提是HTML已开始传输——若TTFB高（如1200ms），说明服务端阻塞，async无效。
async 脚本不影响 TTFB，但会掩盖真实瓶颈
async 属性本身不延长 TTFB，它只控制浏览器如何加载和执行 <script></script>，而 TTFB 完全由服务端响应首个字节的时间决定。但很多人误以为加了 async 就“优化了首屏”，结果发现 TTFB 没变、FCP 也没快——问题其实不在 HTML 标签，而在服务端还没吐出第一个字节。
常见错误现象是：页面里一堆 <script async src="..."></script>，Chrome Network 面板里 document 的 TTFB 仍卡在 1200ms，说明服务端生成 HTML 的过程被阻塞了，浏览器根本还没拿到任何内容可解析。
- async 不改变 HTML 文档传输顺序，也不影响服务端写响应流的时机
- 它只让浏览器在收到 HTML 后，异步下载并执行脚本，不阻塞 parser —— 但这前提是 HTML 已开始传输
- 如果 TTFB 高，
async再多也无济于事；必须先解决服务端阻塞（如fs.readFileSync、未 await 的数据库查询）
async 和 defer 在服务端 flush 场景下的行为差异
当你用 res.write('<script async src="/a.js"></script>') + res.flush() 时，浏览器确实能立刻开始下载 /a.js，但这个下载动作发生在 TTFB 之后，对 TTFB 数值毫无影响。
真正关键的是：服务端是否在 结束后就 flush，而不是等整个 HTML 渲染完。此时 async 脚本能尽早触发资源请求，但 defer 不行——因为它要等 DOM 解析完成才执行，而 DOM 解析又依赖 HTML 流式到达。
-
async脚本在 HTML 流中一出现就会被浏览器识别并发起 fetch（即使只收到了前半段 HTML） -
defer脚本要等到或document.readyState === 'interactive'才开始执行，无法利用早期 flush - 若你用 streaming SSR（如 Next.js
experimental.streaming: true），async是更匹配的加载策略
容易被忽略的 async 使用陷阱
async 看似安全，但在动态 HTML 场景下可能暴露服务端逻辑缺陷。比如模板里写了 <script async src="/user-data.js?uid=<%=%20userId%20%>"></script>，而 userId 是从数据库查来的——如果这个查询没 await，整个响应会卡住，TTFB 飙升，但浏览器控制台却看不到任何 JS 错误，因为连 HTML 都没收到。
- async 不会触发服务端报错，但它会让“服务端慢”变得更难定位：Network 面板里 JS 请求状态是 pending，容易让人误判为 CDN 或网络问题
- 第三方统计脚本常用
async，但如果它们的 URL 是拼接生成的（如含用户 ID、时间戳），且拼接逻辑依赖阻塞 IO，TTFB 就会直接受拖累 - 不要在
里混用async和同步内联脚本：后者会阻塞 parser，抵消async的收益
验证 async 是否真起作用的实操方法
别只看 HTML 源码有没有 async，要看浏览器实际行为。打开 Chrome DevTools → Network → 刷新页面 → 找到那个 script 请求 → 点开它的 Timing 选项卡：
- 如果 “Start Time” 明显早于 HTML document 请求的 “End Time”，说明它确实在 HTML 流中被提前发现并发起请求
- 如果 script 请求的 “Queueing” 时间很长，甚至晚于 HTML 完全加载，那大概率是服务端没做 flush，或者该脚本路径本身触发了重定向（比如
src="//cdn.example.com/app.js"被 CDN 重定向到 https） - 用
curl -I https://yoursite.com/确认主 HTML 请求没有 301/302 —— 重定向会串行增加延迟，让所有后续请求（包括 async 脚本）都晚起步
async 是个客户端调度开关，不是服务端加速器。它生效的前提，是你已经把服务端的 TTFB 压到了合理范围（比如
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
