rel="preconnect" 应仅用于1–2秒内将发起跨域请求的域名，如字体、分析脚本或首屏CDN资源；需写在head中且href仅为origin，避免滥用导致连接竞争。
rel="preconnect" 是浏览器提前建立 DNS 查询、TCP 握手和 TLS 协商的轻量级提示，但它不是万能的——只有在你明确知道要加载资源、且该域名确实会被后续请求用到时才有效；滥用反而会挤占关键连接资源。
什么时候该加 rel="preconnect"？
只在页面中即将（1–2 秒内）发起跨域请求时才加，比如：
- 页面顶部有
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?...">，就在<head>里提前加<link rel="preconnect" href="https://fonts.googleapis.com"> - 使用了 Google Analytics 的
gtag.js，且脚本在首屏后立即执行，可加<link rel="preconnect" href="https://www.google-analytics.com"> - 你控制的 CDN 域名（如
cdn.example.com）用于加载首屏图片或 JS，且该域名未被其他preconnect或dns-prefetch覆盖
别为所有第三方都加——比如页面底部才加载的广告 SDK（ads.example.com），加了反而抢走主资源连接数。
preconnect 和 dns-prefetch 怎么选？
preconnect 比 dns-prefetch 更激进：它会触发完整 TCP+TLS 建立（HTTPS 下），而后者只做 DNS 查询。这意味着：
立即学习“前端免费学习笔记（深入）”；
- 对 HTTP 域名，两者效果接近，但
dns-prefetch更轻量，兼容性更好（IE11 支持） - 对 HTTPS 域名，
preconnect可省下 100–300ms（取决于网络延迟和证书链），但会占用一个连接槽位（浏览器通常限制同域最多 6 个并发连接） - 如果目标域名不支持 TLS 1.3 或 OCSP Stapling，
preconnect可能因握手耗时反而拖慢首屏
简单判断：优先用 preconnect，但若发现 Chrome DevTools 的 Network → Connection ID 列中出现大量 preconnect 失败（如 net::ERR_CONNECTION_TIMED_OUT），退回 dns-prefetch。
必须避免的写法和常见错误
这些写法看似合理，实际会失效或引发问题：
- 写成
<link rel="preconnect" href="https://fonts.googleapis.com/css2?...">——href必须是 origin（协议+域名+端口），不能带路径或查询参数 - 多个
preconnect指向同一域名（如同时写了https://fonts.googleapis.com和https://fonts.gstatic.com）——浏览器会合并处理，但冗余声明增加 HTML 体积，无收益 - 在
<body>里插入（如通过 JS 动态添加）——多数浏览器忽略非<head>中的preconnect，且动态插入已错过最佳时机 - 对不稳定的第三方（如某些广告平台）盲目预连——失败的
preconnect会阻塞其他连接初始化，尤其在弱网下更明显
如何验证是否生效？
打开 Chrome DevTools → Network 标签页，刷新页面后观察：
- 在瀑布图左侧找到
preconnect行，确认其状态为Finished，且耗时远小于后续真实请求（如stylesheet加载） - 点击该行，在 Timing 标签中查看
Connect Start到Connect End是否显著早于后续资源的连接阶段 - 若看到
Stalled时间长、或preconnect行显示Cancelled，说明该预连被浏览器放弃（通常因连接池满或域名未被后续请求使用）
真正起作用的 preconnect 很安静——它不会出现在资源列表里，只在 Timing 中留下“提前开工”的痕迹。最容易被忽略的是：它只对**后续第一个同 origin 请求**生效，如果中间插了其他高优请求（比如内联 script 阻塞了渲染），效果就打折了。
