rel="preconnect"会提前完成dns解析、tcp握手和tls协商，使后续请求直接发送数据；而rel="dns-prefetch"仅做dns解析，不建立连接，因此preconnect在高延迟网络下可节省100–300ms，提速更显著。
rel="preconnect" 会干啥，为什么比 dns-prefetch 快
rel="preconnect" 不只是查 DNS，它会提前走完三步：DNS 解析 → TCP 握手 → TLS 协商（HTTPS 下）。等你真正 fetch 或 <img> 请求发出时，连接已经 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，否则连接可能还没就绪，浏览器会重试，反而拖慢。
真正难的不是写对标签，而是判断“这个域名到底算不算关键”——它取决于你的资源加载链路，而不是域名本身是否知名。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
