<link rel="dns-prefetch" href="//cdn.example.com"> 必须置于 <head> 中，href 以 // 开头（不带协议），仅提前解析域名，开销极低；适用于 CDN、API、字体等关键跨域域名，避免写入 <body> 或使用 http:///https:// 前缀。
怎么写 <link rel="dns-prefetch"> 才有效
必须放在 <head> 里，且 href 值要以 // 开头（不是 http:// 或 https://），否则浏览器可能忽略或解析失败。浏览器会根据当前页面协议自动补全，也避免了混合内容风险。
常见错误包括：
- 写成
<link rel="dns-prefetch" href="https://api.example.com">—— 多余协议头，部分旧版 Safari 会跳过 - 把标签丢在
<body>里 —— 大多数浏览器不处理，等于白加 - href 写错域名，比如漏掉子域：
//cdn.example.com和//api.example.com是两个独立 DNS 查询，不能互相替代
dns-prefetch 和 preconnect 到底该选哪个
两者都作用于外部域名，但成本和效果不同：dns-prefetch 只做 DNS 解析，开销极低；preconnect 会进一步建立 TCP 连接 + TLS 握手（如果是 HTTPS），资源占用高，且受浏览器并发限制（通常最多 6 个）。
推荐按这个逻辑选：
立即学习“前端免费学习笔记（深入）”；
- 只确定会发请求、且该域名支持 HTTPS → 用
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> - 只是“有可能”用到，或不确定是否真加载（如备用 CDN、埋点上报域名）→ 用
<link rel="dns-prefetch" href="//metrics.example.com"> - 同一域名既写了
preconnect又写了dns-prefetch→ 后者被忽略，冗余
哪些域名值得加 dns-prefetch
优先级排序很关键：浏览器对 dns-prefetch 不保证执行，尤其在弱网或内存紧张时会跳过。所以只加真正影响首屏或核心交互的域名。
典型可加场景：
- CDN 域名（
//cdn.example.com），尤其是图片、JS、CSS 的托管地址 - API 接口域名（
//api.example.com），特别是首屏数据请求来源 - 字体服务（
//fonts.googleapis.com、//fonts.gstatic.com），注意后者常需preconnect+crossorigin - 统计/埋点域名（
//stats.example.com），只要它在页面初始化阶段就触发
明确不该加的：
- 广告联盟、第三方弹窗等低优先级或用户触发后才加载的域名
- 你根本没在页面中引用的域名（比如只在 JS 里拼接 URL 但未实际 fetch）
- 内部子域（如
//admin.example.com）—— 和主站同域时，DNS 缓存已共享，无需额外预解析
怎么验证 dns-prefetch 是否生效
不能光看代码写了就以为起作用。打开 Chrome DevTools → Network 面板 → 筛选 Other 类型，找带有 domainlookup 字段的条目。如果某个域名后续真实请求的 domainlookup 时间接近 0ms，说明预解析成功命中缓存。
更直接的方式是：在地址栏输入 chrome://net-internals/#dns，刷新页面后搜索目标域名，能看到是否出现在 DNS 缓存列表里，以及 TTL 剩余时间。
容易被忽略的一点：移动端 WebView（尤其 Android 系统 WebView）对 dns-prefetch 支持不一致，部分版本完全忽略。如果业务重度依赖 App 内嵌页，得实测机型+系统组合，不能默认它一定工作。
