dns-prefetch是浏览器原生支持的轻量级优化,仅提前解析指定域名DNS,需用双斜杠协议写法、置于head靠前位置,优先关键第三方域名,不保证执行。
dns-prefetch 是浏览器原生支持的轻量级优化手段,它只做一件事:在页面加载早期,空闲时悄悄把指定域名的 DNS 解析完成。只要用对了,能省下几十毫秒——尤其对跨域资源多、用户点击跳转频繁的页面很实在。
浏览器需要根据当前页面协议(http 或 https)自动适配,所以 href 值不能写死 http:// 或 https://,否则在 HTTPS 页面里触发 HTTP 预解析会失败或被忽略。
<link rel="dns-prefetch" href="//cdn.example.com">
<link rel="dns-prefetch" href="http://cdn.example.com">
<link rel="dns-prefetch" href="https://api.example.com">
另外,href 只需填域名(含子域),不带路径、参数、端口。例如 //fonts.googleapis.com 可以,//fonts.googleapis.com/css 不行。
浏览器解析 HTML 是流式进行的。dns-prefetch 标签越早出现,DNS 查询启动得越早。如果塞在 <body> 里,或者被 JS 动态插入,大概率已错过最佳时机。
立即学习“前端免费学习笔记(深入)”;
<meta charset> 和 <title> 后面<script> 后、或通过 document.createElement 动态添加dns-prefetch 标签之间无顺序依赖,但浏览器通常按出现顺序发起查询不是所有外部域名都适合。浏览器对并发 DNS 查询数有限制(通常 6–10 个),盲目添加反而挤占资源、触发节流,甚至引发隐私质疑。
//cdn.example.com)、核心 API 域名(//api.example.com)、字体服务(//fonts.googleapis.com)//blog.example.com)//stats.example.com)、广告域名、未确认是否真会用到的备用域名dns-prefetch 不触发真实请求,不发 Cookie,也不受 CORS 限制 —— 所以不用配响应头dns-prefetch 只管 DNS 解析;preconnect 则更激进:DNS + TCP 连接 + TLS 握手全包。后者开销大,也更容易被浏览器拒绝(比如连接池满、空闲时间不足)。
dns-prefetch,再对真正「马上要用」的 1–2 个关键域名补 preconnect
preconnect,结果多数被忽略,还拖慢首屏真正容易被忽略的是:它不保证执行。浏览器有权根据网络状况、内存压力、用户设置(如“节省数据”模式)跳过所有 dns-prefetch。所以它只是锦上添花,不能替代资源加载逻辑本身。