dns-prefetch典型收益为20–120ms，4G弱网下可达150ms+，本地DNS或DoH环境下可压至10ms以内，仅在首次访问无缓存时生效，且必须用//协议相对URL、置于首个跨域资源标签之前才起效。
dns-prefetch 能省多少毫秒？别信理论值，看真实链路
它只解决 DNS 查询这一环，典型收益是 20–120ms，取决于用户本地 DNS 服务器响应速度、TTL 缓存状态和网络类型。4G 弱网下可能达 150ms+，而本地 DNS（如 114.114.114.114）或 DoH 环境下可能压到 10ms 以内。
这不是固定数值，而是「把原本串行的 DNS + TCP + TLS 拆开，提前干掉第一个环节」带来的释放效应。
- 收益只在「首次访问该域名且无缓存」时明显；缓存命中时
DNS时间为0属正常，不是优化失效 - 别对比「加了 vs 没加」的平均首屏时间——JS 执行、渲染阻塞等噪声会淹没真实收益
- 专注单个跨域请求的
DNS时间差：Chrome DevTools → Network → Timing 标签页，找目标资源的DNS Lookup阶段是否提前并缩短 - 禁用
uBlock Origin等扩展，它们可能主动屏蔽dns-prefetch请求，导致实测失真
href 必须写成 //example.com，否则大概率白加
协议相对 URL（//example.com）不是可选项，是强制要求。浏览器根据当前页面协议自动补全 http:// 或 https://，硬写 https://example.com 在 HTTP 页面里会失败，部分 Safari 版本甚至直接忽略整个 link 标签。
- ✅ 正确：
- ✅ 正确：
- ❌ 错误：
（Safari 可能跳过） - ❌ 错误：
（HTTPS 页面直接失效） - ❌ 错误：
（含路径，整个标签被静默忽略） - ❌ 错误：
（通配符不支持）
放在哪儿才真正起作用？位置错了等于没写
浏览器流式解析 HTML，dns-prefetch 必须出现在**首个依赖它的跨域资源标签之前**。比如页面有 在 中第 5 行，那么 就得放在第 1～4 行，越早越好。
- ✅ 推荐顺序：
→× N → 首个或<script src></script> - ❌ 无效位置：丢在
里、用 JS 动态插入、塞在后面但晚于首个外部资源 - ⚠️ 即使位置正确，若顶部堆了大量阻塞渲染的 CSS/JS，DNS 查询也可能被调度延迟——Safari 尤其保守，常等到空闲或用户交互后才执行
哪些域名值得加？加错反而拖慢首屏
每个 dns-prefetch 都是一次真实 DNS 查询，浏览器并发上限通常为 6～10 个。加错对象，反而挤占关键请求的资源调度优先级。
- ✅ 值得加：
//cdn.example.com（首屏图片/JS/CSS 真实加载）、//api.example.com（首屏后立即fetch）、//hm.baidu.com（统计 SDK 初始化必发） - ❌ 不该加：
//your-site.com（同源，DNS 已缓存）、//ad.doubleclick.net（广告常被拦截、不稳定）、//admin.example.com（子域共享主域 DNS 缓存） - ⚠️
//fonts.googleapis.com和//fonts.gstatic.com是两个独立域名，必须分别声明 - ⚠️ 若目标域名只支持 HTTPS（如多数现代 CDN），但当前页是 HTTP，
//写法会降级为 HTTP 请求并失败——这种场景应改用并显式设crossorigin
最易被忽略的是：它完全静默，写错格式不会报错，查不到日志，只能靠 Network 面板确认 DNS Lookup 时间是否下降。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
