dns-prefetch必须置于和之后、首个外部资源标签之前才真正起作用；位置错误（如塞在、插在后或js动态插入）等于没写，且无报错。
dns-prefetch 标签写在哪才真正起作用
位置错了等于没写。浏览器是流式解析 HTML 的，<link rel="dns-prefetch"> 一被读到就排队执行，但必须赶在首个依赖它的跨域资源标签之前。
常见失效场景：标签塞在 里、插在 <script src="https://cdn.example.com/app.js"></script> 后面、或用 JS 动态插入——这些都来不及触发预解析。
-
正确顺序：
<meta charset>→<title></title>→<link rel="dns-prefetch" href="//cdn.example.com">→ 首个<link rel="stylesheet">或<script src="..."></script> - Safari 更保守，若放在大量 CSS/JS 后面，可能被首屏关键资源抢占调度优先级，甚至延迟到空闲时才执行
- 禁用 uBlock Origin 等扩展，它们会主动屏蔽
dns-prefetch请求，导致实测失真
href 写成 //domain.com 是硬性要求，不是可选项
浏览器只从 href 中提取主机名做 DNS 查询，其余内容全被丢弃。格式错一点，整个标签就被静默忽略，控制台不报错、Network 面板没记录，极难排查。
- ✅ 正确：
<link rel="dns-prefetch" href="//cdn.example.com">（协议相对 URL，兼容性好） - ✅ 可接受（HTTPS 页面更稳）：
<link rel="dns-prefetch" href="https://fonts.googleapis.com"> - ❌ 错误：
<link rel="dns-prefetch" href="https://cdn.example.com/js/app.js">（含路径，整个标签被忽略） - ❌ 错误：
<link rel="dns-prefetch" href="http://api.example.com">（HTTPS 页面中 Safari 可能跳过） - ❌ 错误：
<link rel="dns-prefetch" href="cdn.example.com">（缺//，被当成本地路径处理）
只对确定会用的第三方跨域域名加，别碰同源和备用链
每个 dns-prefetch 都是一次真实 DNS 查询，浏览器并发上限通常为 6～10 个。无效查询不仅白耗系统资源，还可能挤占真实请求的队列。
- ✅ 值得加：
//cdn.example.com（图片/JS/CSS 真实加载）、//api.example.com（首屏后立即fetch）、//hm.baidu.com（统计 SDK 初始化必发） - ❌ 不该加：
//your-site.com（同源，浏览器已缓存或自动优化）、//admin.example.com（子域共享主域 DNS 缓存） - ⚠️ 注意：
//fonts.googleapis.com和//fonts.gstatic.com是两个独立域名，必须分别声明；//*.example.com通配符不支持
怎么验证它真起作用了，而不是自我安慰
别对比「加了 vs 没加」的平均首屏时间——JS 执行、渲染阻塞等噪声会淹没真实收益。专注单个跨域资源的 Timing 面板，才是唯一可靠证据。
- Chrome DevTools → Network → 找到目标资源（比如
https://fonts.googleapis.com/css）→ 切换到「Timing」标签页 - 确认「DNS Lookup」阶段是否出现在页面加载早期（比如在
Start render之前），且耗时明显低于未加时的基线值 - 清空浏览器 DNS 缓存：
chrome://net-internals/#dns→ 点「Clear host cache」 - 首次访问 + 无缓存 + 弱网环境（如 4G）下才容易测出 20–120ms 收益；缓存命中时 DNS 时间为 0 属正常，不是优化失效
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
