preconnect仅对明确几秒内必发的HTTPS第三方请求有效，须置于head最顶部、带crossorigin（若需CORS）、限3–6个首屏强依赖域名，同源或HTTP域名无效。
preconnect 能显著减少 TLS 握手耗时，但只在你明确后续会从该域名发起带凭据或需加密通道的请求时才真正生效；盲目加 preconnect 不仅不省时间，反而可能因抢占连接名额拖慢首屏。
哪些域名加了 preconnect 才真能省 TLS 时间
只有 HTTPS 域名且后续资源实际走 TLS 连接时，preconnect 的 TLS 协商步骤才有意义。常见有效场景包括：
-
https://fonts.gstatic.com：Google Fonts 字体文件强制 CORS 加载，必须带crossorigin，否则预建的连接无法复用 -
https://cdn.example.com（托管了首屏 JS/CSS）：如果这些资源是 HTTPS 且未被缓存，预连可跳过完整 TLS 握手 -
https://api.your-domain.com：首屏就fetch()的接口，且服务端返回了Access-Control-Allow-Origin - 同源域名（如
https://your-site.com）加preconnect没效果——浏览器默认复用已有连接，不额外开销
crossorigin 属性不是可选项，而是复用前提
如果不加 crossorigin，浏览器会以“无凭据模式”建立连接；而字体、带 credentials: 'include' 的 fetch 请求等，需要的是“带凭据连接”，两者不兼容，预连白做。
- 必须加
crossorigin的典型情况：https://fonts.googleapis.com+https://fonts.gstatic.com、任何返回Access-Control-Allow-Credentials: true的 API - 写法只能是
crossorigin或crossorigin="anonymous"，crossorigin=""是非法 HTML，会被浏览器忽略 - 如果目标资源根本不需要 CORS（比如普通 CDN 上的公开 CSS），可不加，但加了也无害
为什么放在
浏览器解析 HTML 是流式的，preconnect 必须在遇到第一个外部资源请求前就被识别，否则空闲窗口已过，连接来不及建好。
立即学习“前端免费学习笔记（深入）”；
- 最佳位置：紧跟
<meta charset>后，早于所有<link rel="stylesheet">、<script></script>和<link rel="preload"> - href 值只能是协议+域名，不能带路径或查询参数，例如
https://cdn.example.com✅，https://cdn.example.com/main.js❌ - 动态插入
<link rel="preconnect">无效——浏览器只在初始 HTML 解析阶段响应它
加几个才合理，Chrome 实际并发数只有 6 个
Chrome 当前硬性限制最多同时进行 6 个 preconnect，再多的标签会被排队甚至丢弃。每个连接还占用 DNS 缓存槽位和 TLS 会话票证内存。
- 优先级排序：首屏必现资源 > 首屏后 1 秒内大概率触发的资源 > 其他
- 别为广告、埋点、分享按钮等低确定性域名加
preconnect，改用dns-prefetch更稳妥 - HTTP/2 多路复用下，同一域名多个资源共用一个连接，所以不必为子域名（如
static.example.com和cdn.example.com）都加——除非它们证书不同、无法共享 TLS 会话
最容易被忽略的一点：TLS 握手节省的时间，取决于你是否真的在首屏关键路径里发起了对应域名的 HTTPS 请求。没请求，预连就是空转；有请求但没配对 crossorigin，等于建了个打不开的门。
