preconnect 必须写在 <head> 中且仅对跨域域名有效，href 需为协议+域名、不可带路径，重复声明无效；是否加 crossorigin 取决于目标资源是否需 CORS；建议 3–6 个以内，优先关键早期资源，并搭配 dns-prefetch 使用。
preconnect 必须写在 <head> 里，且只对跨域域名有效
浏览器只在解析 <head> 阶段处理 preconnect，放错位置（比如 <body> 里或 JS 动态插入）完全无效。它不作用于同源地址——https://your-site.com 这类地址加了也没用，浏览器会忽略。
常见错误现象：preconnect 声明后 Network 面板里看不到提前连接、Lighthouse 仍报“Potential savings”警告。
- 确保
<link rel="preconnect" href="https://fonts.googleapis.com">出现在<head>内，且在任何依赖它的资源（如<link href="https://fonts.googleapis.com/css2?...">）之前 - href 值必须是完整协议 + 域名，不能带路径（
https://cdn.example.com/✅，https://cdn.example.com/fonts.css❌） - 避免重复声明同一域名，多个
preconnect到同一源不会叠加效果，反而浪费连接数
要不要加 crossorigin？看目标资源是否带 CORS
crossorigin 不是可选开关，而是行为开关：它决定浏览器是否以 CORS 模式发起连接。如果目标资源（比如字体、API）实际需要 CORS 权限才能加载，但你没加 crossorigin，预连接建立的 TCP/TLS 会被丢弃，后续真实请求仍要重连。
典型场景：
立即学习“前端免费学习笔记（深入）”；
- Google Fonts、CDN 上的
.woff2字体 → 加crossorigin（它们通常返回Access-Control-Allow-Origin: *） - 纯静态 JS/CSS（无 CORS header）→ 不加
crossorigin - API 接口（如
https://api.example.com）→ 若前端 JS 用fetch()调用且服务端配了 CORS，则加；否则不加
错误写法：<link rel="preconnect" href="https://fonts.googleapis.com" crossorigin=""> —— 空值会被浏览器当作匿名模式处理，可能不匹配真实请求的凭据策略。
别乱加，3–6 个是安全上限
每个 preconnect 占用一个空闲 TCP 连接槽位，而现代浏览器对单域名并发连接数有限制（通常 6 个）。盲目添加太多，会挤占真实资源下载的连接，反而拖慢首屏。
优先级判断依据只有两个：
- 该域名是否承载 LCP 关键资源（如首屏字体、核心 CDN JS）
- 该域名是否确定会在页面生命周期早期被访问（比如首屏就发 API 请求）
不该加的典型例子：
- 广告联盟域名（
https://ads.example.com）—— 用户未必触发广告加载 - 分析脚本（
https://analytics.example.com）—— 通常延迟执行，非关键路径 - 备用 CDN（
https://cdn-backup.example.com）—— 主 CDN 失败才用，概率低
和 dns-prefetch 搭配时，顺序与兼容性要注意
dns-prefetch 兼容性更好（IE9+），但只做 DNS 查询；preconnect 更激进，覆盖 DNS+TCP+TLS，但仅支持较新浏览器（Chrome 50+、Firefox 46+、Safari 12.1+）。两者可以共存，浏览器会按能力自动选择执行哪个。
实操建议：
- 先写
preconnect，再紧跟着写同域名的dns-prefetch（顺序不能反） - 例如：
<link rel="preconnect" href="https://cdn.example.com" crossorigin> <link rel="dns-prefetch" href="https://cdn.example.com">
- 不要为同一个域名同时写多个
preconnect或混用不同协议（http://和https://算两个源）
最容易被忽略的一点：preconnect 的收益高度依赖真实网络环境。在本地开发（localhost）、内网或高带宽低延迟环境下几乎测不出差异，务必在 3G/4G 模拟或真实弱网设备上验证效果。
