preconnect适用于页面确定立即使用的关键跨域资源，如字体、首屏js/css或api，它提前完成dns+tcp+tls三步，弱网下可省200–600ms；dns-prefetch仅做dns查询，适合可能访问或兼容性要求高的场景。
什么时候该用 preconnect 而不是 dns-prefetch
当你确认页面一定会从某个跨域域名加载关键资源（比如 Google Fonts、CDN 上的首屏 JS/CSS、或立即调用的 API），就该用 preconnect；dns-prefetch 只做 DNS 查询，而 preconnect 会提前完成 DNS + TCP + TLS 三步——在弱网或移动端能省下 200–600ms 连接延迟。
以下情况优先选 preconnect：
- 用了
https://fonts.googleapis.com加载字体，且页面中声明了<link rel="stylesheet" href="https://fonts.googleapis.com/..."> - 静态资源托管在
https://cdn.example.com，且 HTML 中直接引用了该域名下的.js或.css - 首屏 JS 里立即执行
fetch("https://api.example.com/...")
以下情况改用 dns-prefetch 更安全：
- 目标站只支持 HTTP（
preconnect在 TLS 协商阶段会失败） - 只是“可能”会访问的域名（如用户点击后才加载的第三方评论组件）
- 需要兼容老版本 Safari 或 IE（
preconnect不被支持）
preconnect 必须带 crossorigin 才生效
即使目标是 HTTPS 同协议同域（如 https://cdn.example.com），漏写 crossorigin 也会导致连接无法复用——浏览器把带和不带 crossorigin 的连接视为两个独立连接池。
正确写法：
<link rel="preconnect" href="https://fonts.googleapis.com" crossorigin><link rel="preconnect" href="https://cdn.example.com" crossorigin>
常见错误：
-
<link rel="preconnect" href="https://fonts.googleapis.com">（漏crossorigin） -
<link rel="preconnect" href="http://cdn.example.com" crossorigin>（协议不一致，TLS 失败） -
<link rel="preconnect" href="//cdn.example.com" crossorigin>（协议相对路径，部分浏览器不识别）
preconnect 标签必须放
浏览器解析到 preconnect 就立刻开始建连，如果它被卡在一堆 CSS 或 JS 后面，就错过了最佳时机。实测晚于首屏样式表 200ms 以上，连接建立可能赶不上首屏资源请求。
建议顺序：
- 字符集声明（
<meta charset="utf-8">） -
preconnect标签（最多 4–6 个） - 关键
<link rel="stylesheet">和<script defer></script>
不要超过 6 个：Chrome 限制并发 preconnect 数量，超出项会被静默丢弃，还可能挤占主站连接数。
怎么验证 preconnect 真正起作用了
不能只看代码有没有写对，得进 Chrome DevTools 看真实行为：
- Network → Filter 输入目标域名（如
fonts.googleapis.com）→ 点开任一资源 → Timing 标签页 → 观察 “Connection Start” 是否明显早于 “Request Start” - Filter 输入
Initiator: preconnect→ 确认有对应条目，且状态码为 200（说明连接建立成功） - 同一域名下其他资源（如
font.woff2）的 Priority 显示为Highest或High，说明连接被复用了
容易被忽略的一点：preconnect 是连接预热，不是资源下载。它不会触发任何实际资源请求，也不会出现在缓存列表里——它的价值体现在后续真实请求的 “Connection Start” 时间大幅提前。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
