dns-prefetch不加速首屏，仅优化首屏后异步请求（如懒加载图片、fetch API、字体CSS、统计SDK）的DNS解析；必须置于<meta charset>和<title>之后、首个外部资源标签之前，href须为//domain.com格式，错误则静默失效。
dns-prefetch 在首屏**不直接加速**——它只对首屏之后发起的异步请求（比如懒加载图片、首屏后 fetch、字体 CSS 加载、统计 SDK 初始化）起作用。指望它缩短 FCP 或 LCP 是错的。
为什么加了 dns-prefetch 却没看到首屏变快
浏览器解析到 <link rel="dns-prefetch"> 时，确实会排队做 DNS 查询，但这个动作本身不触发资源下载，也不影响 HTML 解析或 CSS/JS 加载流程。首屏资源（如主 CSS、关键 JS、首屏图）若来自第三方域名，真正生效的是 preconnect，不是 dns-prefetch。
- 首屏资源已通过
<link rel="stylesheet">或<img src>显式声明 → 浏览器立刻发起请求，此时 DNS 查询若还没完成，就只能等；dns-prefetch若放得晚，根本赶不上 -
dns-prefetch只影响后续异步请求：比如首屏渲染完，JS 才调用new Image().src = "//img1.cdn.com/logo.png"，这时才用得上预解析结果 - Safari 更保守，常延迟到空闲或用户交互后才执行
dns-prefetch，首屏时间线里基本不参与
哪些域名值得加 dns-prefetch（且必须写对）
只加当前页面**确定会用、且是跨域**的域名，每个都得满足：href 是 // 开头、仅含协议+域名、无路径无端口。
- ✅ 推荐加：
//cdn.example.com（首屏后懒加载图）、//api.example.com（首屏后立即fetch("/user")）、//hm.baidu.com（统计脚本初始化必发） - ❌ 别加：
//your-site.com（同源，DNS 已缓存）、//admin.example.com（子域通常共享主域 DNS 缓存）、//ad.doubleclick.net（不稳定、常被拦截，还占队列） - ⚠️ 注意：
//fonts.googleapis.com和//fonts.gstatic.com是两个独立域名，不能省掉任一个；也不支持通配符，//*.example.com完全无效
位置和格式错误等于没写
dns-prefetch 标签写错格式，浏览器会静默忽略——控制台不报错、Network 面板不显示、你根本查不到问题。
立即学习“前端免费学习笔记（深入）”；
- ✅ 正确位置：
<meta charset>和<title>之后、首个<link rel="stylesheet">或<script>之前 - ✅ 正确格式：
<link rel="dns-prefetch" href="//cdn.example.com">（协议相对，无路径） - ❌ 错误格式：
href="https://cdn.example.com"（旧版 Safari 忽略）、href="//cdn.example.com/js/app.js"（含路径，整个标签被丢弃）、href="cdn.example.com"（缺//，当成本地路径）
和 preconnect 混用反而坏事
同一域名上同时写 dns-prefetch 和 preconnect，后者会覆盖前者；而且 preconnect 开销大（建连 + TLS 握手），浏览器并发数通常只有 6 个，多连会抢主站连接。
- 如果目标域名你**确定会在首屏用到**（比如字体、CDN 图片），直接上
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>，别加dns-prefetch - 如果只是首屏后才用、且兼容性要求高（比如要保 iOS 14 以下），才考虑用
dns-prefetch作兜底 - 别为了“多加一层保险”把两者都写上——浏览器不会叠加收益，只会浪费调度资源
真正容易被忽略的是：dns-prefetch 不保证执行。它依赖浏览器空闲度，可能被首屏 CSS/JS 抢占优先级，也可能因 DNS 队列满（通常限 6～10 个）而静默丢弃。它不是性能瓶颈的解药，而是已有优化到位后的微调手段。
