dns-prefetch 典型收益为20–120ms，4g弱网可达150ms+，本地dns或doh下可低于10ms；仅在首次访问且无缓存时生效，缓存命中时dns时间为0属正常。
dns-prefetch 能省多少毫秒？别信理论值，看真实链路
它只解决 DNS 查询这一环，典型收益是 20–120ms，取决于用户本地 DNS 服务器响应速度、TTL 缓存状态和网络类型。4G 弱网下可能达 150ms+，而本地 DNS（如 114.114.114.114）或 DoH 环境下可能压到 10ms 以内。这不是固定数值，而是「把原本串行的 DNS + TCP + TLS 拆开，提前干掉第一个环节」带来的释放效应。
关键点在于：这个收益只在「首次访问该域名且无缓存」时明显。如果用户刚打开过同域名页面、或系统/浏览器 DNS 缓存未过期，dns-prefetch 就不会触发真实查询——此时你看到 Timing 面板里 DNS 时间为 0，不是优化失效，是它本就不需要工作。
- 实测建议用 Chrome DevTools → Network → 切换到「Timing」标签页，找目标资源的 DNS 阶段是否出现在页面加载早期（比如
- 不要对比「加了 vs 没加」的平均首屏时间，那会被 JS 执行、渲染阻塞等噪声淹没；专注单个跨域请求的 DNS 时间差
- 注意排除干扰：禁用 uBlock Origin 等扩展，它们可能主动屏蔽
dns-prefetch请求
href 必须写成 //example.com，否则大概率白加
协议相对 URL（//example.com）不是可选项，是强制要求。浏览器根据当前页面协议自动补全 http:// 或 https://，硬写 https://example.com 在 HTTP 页面里会失败，部分 Safari 版本甚至直接忽略整个 link 标签。
常见错误写法包括：https://fonts.googleapis.com、http://cdn.example.com、//cdn.example.com/js/main.js（含路径非法）、//*.example.com（通配符不支持）。
-
//fonts.googleapis.com和//fonts.gstatic.com是两个独立域名，必须分别声明 - 如果目标域名仅支持 HTTPS（比如某些 API 服务），但当前页是 HTTP，
//写法会降级为 HTTP 请求并失败——这种场景应改用preconnect并显式设crossorigin - 端口一般省略，除非你明确用了非标端口（如
//api.example.com:8080）
放在 多靠前才算“来得及”？
浏览器流式解析 HTML，dns-prefetch 必须出现在**首个依赖它的跨域资源标签之前**。比如页面 <link rel="stylesheet" href="https://cdn.example.com/main.css"> 在 中第 5 行，那么 <link rel="dns-prefetch" href="//cdn.example.com"> 就得放在第 1～4 行，越早越好。
丢在 里、用 JS 动态插入、或塞在 <meta> 后面都无效——解析器已经往下跑了，来不及触发预解析。
- 推荐位置：
开始后、紧挨着<meta charset>和<title></title>，比所有<link rel="stylesheet">和<script></script>都早 - 它不阻塞渲染，但会占用浏览器空闲时的 DNS 并发槽位；放太晚，可能被首屏 CSS/JS 抢占网络带宽和 CPU
- Chrome 最大并发
dns-prefetch数量约 6～10 个，超出的会被丢弃，所以宁缺毋滥
和 preconnect 混用同一域名，等于多写了一行废代码
preconnect 已包含 DNS 解析步骤，再加 dns-prefetch 不会叠加效果，反而浪费一个并发名额。浏览器遇到重复域名时，以 preconnect 为准，dns-prefetch 直接被忽略。
选择依据很简单：你是否确定「1 秒内必发请求」？如果是字体、首屏 JS/CSS、核心 API，用 preconnect；如果是分享按钮、埋点上报、懒加载图片，用 dns-prefetch 更稳妥。
- 移动端弱网下，
preconnect可能抢占连接数，导致主资源排队；dns-prefetch几乎无副作用 - IE11 支持
dns-prefetch但不支持preconnect，兼容性要求高时只能选前者 - 别为「备用 CDN 域名」或「广告联盟子域」加
dns-prefetch——没请求就是纯消耗
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
