preconnect仅对马上使用的跨域HTTPS域名有效，必须置于<head>顶部、写全协议+域名，且字体和CORS资源需加crossorigin或crossorigin="anonymous"才复用连接；超6个或加错域名反拖慢首屏。
加 rel="preconnect" 确实能省 TLS 时间，但只对「马上要用的跨域 HTTPS 域名」有效；加错位置、漏 crossorigin、超 6 个，反而拖慢首屏。
哪些域名必须加 crossorigin 才真正起作用
不加 crossorigin，浏览器会建一个“无凭据连接”，而字体、带 credentials: 'include' 的 fetch() 请求需要的是“带凭据连接”，两者无法复用——预连白做。
-
https://fonts.googleapis.com和https://fonts.gstatic.com：Google Fonts 强制 CORS 加载，必须加crossorigin -
https://api.your-domain.com：只要服务端返回了Access-Control-Allow-Origin（哪怕只是*），就建议加crossorigin="anonymous" -
https://cdn.example.com：如果 JS/CSS 是公开资源、不带凭据，可不加；但加了也无害，且兼容性更稳 -
crossorigin=""是非法写法，会被浏览器忽略；正确写法只有crossorigin或crossorigin="anonymous"
preconnect 必须放 <head> 最顶部，且不能动态插入
浏览器解析 HTML 是流式的，preconnect 必须在遇到第一个外部资源请求前就被识别，否则连接来不及建好。动态插入的 <link rel="preconnect"> 完全无效。
- 最佳位置：紧跟
<meta charset>后，早于所有<link rel="stylesheet">、<script>、<link rel="preload"> -
href值只能是协议 + 域名，例如https://cdn.example.com✅，https://cdn.example.com/main.js❌（带路径或查询参数会被忽略） - 放在
<body>里，Chrome、Firefox 直接忽略；Safari 可能部分支持但行为不一致
加几个、加谁，才不会拖慢页面
Chrome 当前硬性限制最多同时进行 6 个 preconnect，再多的标签会被排队甚至丢弃。每个连接还占用 DNS 缓存槽位和 TLS 会话票证内存。
立即学习“前端免费学习笔记（深入）”；
- 优先级排序：首屏必现资源（如字体、核心 CDN JS） > 首屏后 1 秒内大概率触发的资源（如首屏接口） > 其他
- 别为广告、统计 SDK（如
www.google-analytics.com）加preconnect——它们更适合dns-prefetch - 同源域名（如
https://your-site.com）加了没效果，浏览器默认复用已有连接 - 子域名不算共享连接：
a.example.com和b.example.com需要各自预连，容易超限
怎么验证 preconnect 是否生效
它不报错也不提示，失效时你根本不知道——得靠 DevTools 主动查。
- 打开 Chrome DevTools → Network 标签页 → 切换到 Timing 子标签 → 找对应域名的请求 → 看 “Connection Start” 时间是否明显提前（相比没加时）
- Performance 面板录制页面加载过程，筛选
Network事件，观察是否有preconnect对应的 DNS/TCP/TLS 阶段提前完成 - 如果 Network 里完全看不到该域名的预连记录，大概率是写法错误（缺协议、放错位置、没加
crossorigin）或目标域名后续根本没发起真实请求
最容易被忽略的点是：它只对「后续真实发生的跨源 HTTPS 请求」起效。你加了 5 个 preconnect，但其中 2 个域名在当前页面里压根没被 JS 或 CSS 触发任何请求，那这 2 个就是纯浪费资源——不仅没提速，还挤占了真正关键域名的连接名额。
