DNS预解析与预连接区别及优化建议

`rel="preconnect"` 和 `rel="dns-prefetch"` 都是前端性能优化的关键手段，但它们并非等价替代：前者通过提前完成DNS解析、TCP握手和TLS协商，让关键跨域请求“即发即传”，在高延迟网络下可节省100–300ms；后者仅预查DNS，轻量兼容却提速有限。真正决定效果的不是标签本身，而是你是否精准识别出“页面首屏1秒内必用”的核心域名（如字体、API、主CDN），并克制地控制数量（≤6个）、避免滥用在非紧急资源上——用对时机，才能让毫秒级优化转化为用户可感知的流畅体验。

rel="preconnect" 会干啥，为什么比 dns-prefetch 快

rel="preconnect" 不只是查 DNS，它会提前走完三步：DNS 解析 → TCP 握手 → TLS 协商（HTTPS 下）。等你真正 fetch 或 请求发出时，连接已经 ready，直接发数据。实测在移动网络或高 RTT 场景下，能省掉 100–300ms 延迟。

rel="dns-prefetch" 只做第一步：DNS 查询。它轻量、兼容性好（IE11 都认），但后续还得等 TCP/TLS，对首屏关键资源提速有限。

简单说：preconnect 是“电话已拨通、对方已接起”，dns-prefetch 是“只查到了对方手机号”。

什么时候该用 preconnect，而不是 dns-prefetch

只对当前页面**马上就要用**的第三方域名用 preconnect，比如：

• 字体服务（https://fonts.googleapis.com）
• 核心 API 域名（https://api.example.com）
• 主 CDN（https://cdn.example.com）

满足以下条件才考虑 preconnect：

• 你确定接下来 1 秒内就会发起请求（比如首屏 JS 里立刻 fetch）
• 该域名支持 HTTPS（HTTP 下部分浏览器会忽略或警告）
• 你控制了并发数（建议 ≤6 个，避免挤占主域连接）

别给 analytics、广告这类“可能用、但不紧急”的域名上 preconnect——它们更适合 dns-prefetch。

dns-prefetch 的真实适用场景和坑点

dns-prefetch 适合那些“确定会访问、但不急着加载”的跨域域名，典型例子：

• 统计脚本（https://stats.example.com）
• 社交分享接口（https://platform.twitter.com）
• CDN 备用域名或灰度域名

容易踩的坑：

• 写了但后续根本没请求该域名 → 白跑一次 DNS 查询（虽小，但无意义）
• 写成 HTTP 协议（http://）→ 现代浏览器通常忽略，或触发不安全提示
• 放在 里 → 大部分浏览器只在 中解析 link[rel]，放错位置等于没写

preconnect 和 dns-prefetch 能不能一起用

可以，而且推荐组合用法：

• 对最关键的 1–2 个域名（如字体、API），只用 preconnect
• 对其他确定会访问、但优先级低的域名（如统计、广告），补上 dns-prefetch

示例：

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://api.example.com">
<link rel="dns-prefetch" href="https://stats.example.com">
<link rel="dns-prefetch" href="https://ads.example.com">

注意：preconnect 后不要立即发请求——建议间隔 ≥100ms，否则连接可能还没就绪，浏览器会重试，反而拖慢。

真正难的不是写对标签，而是判断“这个域名到底算不算关键”——它取决于你的资源加载链路，而不是域名本身是否知名。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《DNS预解析与预连接区别及优化建议》文章吧，也可关注golang学习网公众号了解相关技术文章。