dns-prefetch 的收益是将 dns 查询提前剥离出请求链路，典型节省 20–120ms；其生效需满足三要素：href 仅含协议+域名、置于 head 靠前位置、目标域名确被后续异步请求使用，否则静默无效。
dns-prefetch 的收益不是固定毫秒数，而是「把 DNS 查询从串行链路里提前剥离」带来的释放效应——实际节省值只在首次访问、无缓存、弱网条件下可测，典型为 20–120ms；4G 弱网下可达 150ms+，本地 DNS 或 DoH 环境下可能压到 10ms 以内。
为什么 DevTools 里 DNS 时间没变短？
不是代码无效，而是你观察的请求根本没走预解析——最常见原因有三个：
- 目标域名刚被访问过，系统或浏览器 DNS 缓存未过期（TTL 通常 60–300 秒），Timing 面板显示 DNS 时间为 0 属正常，不是优化失效
- dns-prefetch 标签位置太靠后，等它被解析时，
<script src="https://cdn.example.com/app.js"></script>已经发出请求 - href 写成了
https://cdn.example.com或//cdn.example.com/js/main.js，浏览器静默忽略整个标签，且不报错
怎么验证它真起作用了？
别看首屏时间，专注单个跨域资源的 Timing 面板：
- 用 Chrome DevTools → Network → 找到目标资源（比如
https://fonts.googleapis.com/css）→ 切换到「Timing」标签页 - 确认「DNS Lookup」阶段是否出现在页面加载早期（比如在
Start render之前），且耗时明显低于未加时的基线值 - 禁用 uBlock Origin 等广告拦截扩展，它们会主动屏蔽
dns-prefetch请求 - 清空浏览器 DNS 缓存：
chrome://net-internals/#dns→ 点「Clear host cache」
哪些场景下收益接近于零？
写对了、放对了、也加对了域名，但实测几乎没收益，大概率是以下情况：
- 当前页是 HTTPS，但写了
//api.example.com，而该 API 只支持 HTTPS —— 在 HTTP 页面中它会降级为 HTTP 请求并失败；这种场景应改用<link rel="preconnect" href="https://api.example.com" crossorigin> - 同一主域下的多个子域（如
cdn1.example.com和cdn2.example.com）共用权威 DNS，加一个就够了，重复加只会挤占并发队列 - 目标域名实际并未被页面 JS 或懒加载触发请求，比如加了
//backup.cdn.com，但首屏和后续交互中根本没用到它——预解析就是空转 - Safari 用户占比高：Safari 14+ 虽支持，但常延迟到页面空闲或用户 hover 后才执行，无法保证 HTML 解析阶段即时生效
真正影响收益的从来不是“加没加”，而是“加得准不准、放得早不早、用得上不上”。它不报错、不警告、也不留日志，唯一证据藏在 Timing 面板里那个稍纵即逝的 DNS 阶段——盯住它，比什么都实在。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
