跳到主要内容

DNS 预解析

面试速答（30 秒版 TL;DR）​

  • DNS 预解析（DNS Prefetch） 是让浏览器在资源真正发起请求前，先把域名解析成 IP。
  • 它优化的是 “连出去之前的第一步”，不是完整建连；因此它只能省掉一部分等待时间。
  • 最适合的场景是：当前页面大概率马上会访问某个跨域静态资源域名，比如图片 CDN、字体 CDN、埋点域名。
  • 最常见写法：
<link rel="dns-prefetch" href="//static.example.com" />
  • 面试里最好顺手补一句：dns-prefetch 只做 DNS，preconnect 才会继续做 TCP/TLS 建连。

一、先建立心智模型：它到底在优化哪一段？​

浏览器访问一个跨域资源，通常至少会经过这样几步：

  1. 解析域名
  2. 建立 TCP 连接
  3. 如果是 HTTPS，再做 TLS 握手
  4. 发送 HTTP 请求
  5. 接收响应

DNS 预解析只提前做第 1 步，所以它不是“万能提速”，而是把本来要在关键路径里发生的 DNS 查询，尽量挪到浏览器空闲时做掉。

一句话理解：

DNS 预解析优化的是“未来请求的起跑动作”，不是整个请求生命周期。

二、它解决的是什么问题？​

如果页面要用到多个第三方域名，浏览器第一次访问每个域名时都要先查 DNS。这个动作在弱网、移动网络、冷启动场景里会更明显。

典型场景包括：

  • 页面首屏会马上拉取图片 CDN 资源
  • 页面很快会请求字体 CDN
  • 跳转后的下一页大概率会访问某个 API 域名
  • 页面内嵌了第三方评论、统计、地图、客服脚本

如果这些域名在真正请求前就完成了解析，后续请求就能少等一步。

三、什么时候值得用，什么时候别乱用？​

适合使用​

  • 跨域且高概率会用到 的域名
  • 数量不多但访问价值高的关键域名
  • 用户进入页面后很快就会访问的资源域名

不太适合使用​

  • 根本不确定会不会访问的域名
  • 一次性塞很多第三方域名
  • 当前页面根本不依赖的长尾资源域名
  • 同源资源场景下指望它带来明显收益

这里最容易犯的错是：看见“预”字就全开。实际上 DNS 查询也有成本，域名越多，越可能造成无意义的提前解析。

四、dns-prefetch 和 preconnect 到底差在哪？​

这是面试高频追问。

能力dns-prefetchpreconnect
提前 DNS 解析是是
提前 TCP 建连否是
提前 TLS 握手否是（HTTPS 下）
成本更低更高
适用对象次关键域名当前页面马上就要访问的关键跨域域名

推荐答法：

  • dns-prefetch 更轻，适合“可能很快会用到”的域名。
  • preconnect 更激进，适合“当前页马上就要用”的关键域名，比如首屏字体源、关键 API、关键图片 CDN。

示例：

<link rel="dns-prefetch" href="//img.example.com" />
<link rel="preconnect" href="https://font.example.com" crossorigin />

别把它们理解成互斥关系。很多项目里是：

  • 非关键域名用 dns-prefetch
  • 真正关键域名用 preconnect

五、最小可用写法​

1. 基础写法​

<link rel="dns-prefetch" href="//static.example.com" />

注意点：

  • href 写域名即可，不需要具体文件路径
  • 常见写法是 //domain.com，表示协议跟随当前页面

2. 一个更贴近真实项目的示例​

<head>
  <link rel="dns-prefetch" href="//img.example-cdn.com" />
  <link rel="dns-prefetch" href="//font.example-cdn.com" />
  <link rel="preconnect" href="https://font.example-cdn.com" crossorigin />
</head>

这里的思路是：

  • 图片域名很快会请求，但不是最关键，所以做 DNS 预解析
  • 字体域名会直接影响首屏文本展示，所以进一步做 preconnect

六、真实收益怎么判断？​

不要把它当成“加了就一定肉眼可见”的优化项。它更像一个低成本细节优化，收益通常取决于：

  • 用户网络环境是否较差
  • 域名是否是首次访问
  • DNS 解析是否本来就慢
  • 后续资源是否真的很快发起请求

工程上更务实的做法是：

  1. 先在 DevTools 的 Network 面板看是否存在明显的 DNS 阶段耗时
  2. 只挑少数关键跨域域名做实验
  3. 对比优化前后的瀑布图和首屏指标

如果一个域名本来就复用得很好，或者浏览器缓存命中率很高，那么收益可能不明显。

七、典型题与标准答法​

Q1：什么是 DNS 预解析？​

答法：

DNS 预解析就是浏览器在资源真正请求前，先把目标域名解析成 IP。这样后续真正发请求时可以省掉 DNS 查询时间。它适合跨域静态资源较多、并且这些域名很快就会被访问的场景。

Q2：它和 preconnect 有什么区别？​

答法：

dns-prefetch 只提前做 DNS；preconnect 会继续把 TCP 和 TLS 也做掉，所以更重，但收益也可能更大。当前页马上要访问的关键域名更适合 preconnect，次关键域名可以先用 dns-prefetch。

Q3：为什么不能滥用？​

答法：

因为提前解析本身也要占用系统和网络资源。如果页面一次性对很多不会访问的域名做预解析，就会造成无效工作，甚至干扰真正关键资源的调度。

八、常见误区​

  • 误区 1：把 DNS 预解析当成完整预连接。 它不负责 TCP/TLS，别高估收益。

  • 误区 2：对所有第三方域名一股脑都加。 这通常是在制造噪音，不是在优化关键路径。

  • 误区 3：忽略跨域资源的真实优先级。 关键域名更应该考虑 preconnect，而不是只停留在 dns-prefetch。

  • 误区 4：只会背标签，不会解释适用场景。 面试时最好能补出“高概率访问的跨域域名”这个前提。

九、速记要点​

  • DNS 预解析 = 提前做域名解析。
  • 它只优化 DNS，不优化 TCP/TLS。
  • 轻量，适合高概率会访问的跨域域名。
  • 关键域名优先考虑 preconnect。
  • 不要批量乱加，先看真实关键路径。