rel="preconnect"仅对后续真实发生的跨源HTTPS请求有效，应优先用于CDN、字体、分析等域名，须写在head中且带正确协议和crossorigin属性，错误使用反而浪费连接资源。
rel="preconnect" 确实能提前建立 DNS 查询、TCP 握手和 TLS 协商，但只在真正需要跨源请求时才值得加，乱用反而可能挤占关键资源。
什么时候该加 rel="preconnect"
它只对后续会发起跨源请求的域名有效——比如你页面里用了 https://fonts.googleapis.com 的字体，或向 https://api.example.com 发送 fetch 请求。如果只是同源链接、静态资源（如本地 style.css）或根本不会触发网络请求的 <a href>，加了没用，还白耗浏览器连接数。
- 典型适用场景：CDN 域名（
cdn.jsdelivr.net）、字体服务（fonts.gstatic.com）、分析 SDK（www.google-analytics.com） - 不适用：
rel="stylesheet"引入的同域 CSS、<img src="./logo.png">、未被 JS 实际调用的 API 域名 - 注意：Chrome 限制最多预连 6 个不同源，超出的会被丢弃
preconnect 和 dns-prefetch 到底差在哪
dns-prefetch 只做 DNS 查询，轻量但收益有限；preconnect 走完 DNS + TCP + TLS 全流程，开销大但对 HTTPS 资源更直接有效。现代项目优先选 preconnect，除非目标域名不支持 HTTPS（极少见）或你明确知道只需查 DNS（比如旧版 IE 兼容兜底）。
-
<link rel="dns-prefetch" href="//cdn.example.com">→ 仅 DNS -
<link rel="preconnect" href="https://cdn.example.com">→ DNS + TCP + TLS - 不要混用：同一域名同时写两者，后者会覆盖前者，前者冗余
常见错误写法和后果
写错 href 值或协议，会导致预连接失败甚至阻塞渲染。浏览器不会报错，但 DevTools 的 Network 标签页里看不到对应预连记录，Performance 面板中也观察不到 TLS 时间下降。
立即学习“前端免费学习笔记（深入）”；
- ❌
<link rel="preconnect" href="cdn.example.com">— 缺少协议，被当成相对路径 - ❌
<link rel="preconnect" href="http://cdn.example.com">— 若实际资源走 HTTPS，HTTP 预连无法复用 - ❌ 放在
<body>里 — 大部分浏览器忽略，必须在<head>中尽早声明 - ✅ 正确：
<link rel="preconnect" href="https://cdn.example.com" crossorigin>（含crossorigin才能用于带凭据的请求）
真正起效的前提是：那个域名后续确实被 JS 或 CSS 触发了网络请求。别把它当“加载加速万金油”，漏掉真实瓶颈（比如未压缩的图片、阻塞渲染的 JS）才更耽误事。
