dns-prefetch 不能缩短 TTFB，因其仅提前执行 DNS 查询，不影响 TCP 连接、TLS 握手及服务器处理等后续环节；它仅在域名未缓存时生效，且依赖严格的位置、格式与使用场景。
dns-prefetch 本身不降低首包延迟（TTFB），它只提前做 DNS 查询；首包延迟由服务器响应、网络链路、TLS 握手等决定，dns-prefetch 对这些环节完全无影响。
为什么 dns-prefetch 不能缩短 TTFB
DNS 查询只是建立连接前的第一步。TTFB = DNS Lookup + TCP Connect + TLS Handshake + Server Processing + First Byte。而 dns-prefetch 只覆盖第一个环节，且仅在「该域名尚未解析过」时才有作用。一旦 DNS 缓存命中，它就彻底不触发——此时你看到的 TTFB 里 DNS 时间为 0，不是优化生效，是浏览器根本没查。
- TTFB 降低必须靠
preconnect（完成 DNS+TCP+TLS）或服务端优化（如启用 HTTP/3、减少后端处理耗时） -
dns-prefetch的收益体现在后续请求的「DNS Lookup 阶段是否被提前并缩短」，比如首屏后 JS 调用fetch("https://api.example.com/data")时，DNS 已就绪，直接进 TCP 连接 - 在 Chrome DevTools → Network → Timing 标签页中，观察目标资源的 DNS Lookup 时间线：若显示为「(pending)」或明显早于其他阶段开始，说明预解析生效；若仍和 TCP Connect 紧挨着，大概率没起作用
dns-prefetch 生效的前提非常苛刻
它不是加了就跑，而是依赖位置、格式、使用场景三重对齐：
- href 必须是
//cdn.example.com这种协议相对域名，带https://或路径（如//cdn.example.com/js/app.js）会静默失效 - 必须放在
<meta charset>和<title>之后、首个<link rel="stylesheet">或<script>之前——晚于这些标签，首屏资源请求早已发出 - 只对当前页面真实发起请求的第三方域名有效；写了个
//ad.doubleclick.net但页面压根没加载广告脚本，等于白占一个 DNS 并发槽位（浏览器通常限 6～10 个）
和 preconnect 混用同一域名反而拖慢首屏
如果你已经写了 <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>，就不要再加 <link rel="dns-prefetch" href="//fonts.gstatic.com">。原因很实际：
立即学习“前端免费学习笔记（深入）”；
-
preconnect已包含 DNS 解析，再加dns-prefetch属于重复劳动，浪费一个并发连接名额 - 浏览器对
preconnect的调度优先级更高，dns-prefetch可能被降级或跳过，尤其在 Safari 下它本就延迟执行 - 现代浏览器（Chrome 73+、Firefox 81+、Edge 79+）已全面支持
preconnect，dns-prefetch更适合作为兼容性兜底，而非主力手段
真正容易被忽略的是：它不保证执行。即使位置和格式全对，浏览器也可能因内存紧张、CPU 占用高或空闲队列未就绪而跳过查询——所以别把它当作首屏性能的关键杠杆，它只是对「确定要用、且首次访问」的跨域请求的一次轻量提醒。
