preconnect 必须放在 最前面，因为浏览器在 html 解析阶段就处理它，遇 或 dom 构建即停止解析后续 preconnect；放错位置、动态插入或置于 均无效。
rel="preconnect" 是唯一能提前建立 DNS + TCP + TLS 连接的声明式手段，但只对跨域域名有效、必须放 最前几行、加错位置或超量反而拖慢首屏。
为什么 preconnect 必须放在 最前面
浏览器在 HTML parser 阶段就解析 preconnect，一旦开始构建 DOM 或遇到首个 <script></script>，后续的 preconnect 就被忽略。它不等页面加载完成，也不依赖 JS——晚于关键 CSS 或字体加载的 preconnect，基本等于没写。
常见错误现象：
- 放在
<link rel="stylesheet">下方 → DNS 查询被延迟 100–300ms - 动态插入（如
document.head.appendChild(link)）→ 完全无效 - 写在
里 → Chrome DevTools Network 面板里根本看不到任何 preconnect 请求
哪些域名值得 preconnect、哪些不该加
preconnect 只对跨域请求有意义，同域加了无收益；但它不是越多越好，浏览器并发连接数有限（通常 6 个），多连会挤占主站资源。
推荐加的场景：
- CDN 域名（如
https://cdn.example.com） - API 接口域名（如
https://api.example.com） - 第三方统计/埋点服务（如
https://stats.example.net）
明确不该加的：
- 当前站点主域名（如
https://example.com）→ 浏览器已自动复用连接 - 超过 4–6 个域名 → 连接竞争加剧，部分 preconnect 被丢弃
- HTTP/2 或 HTTP/3 支持的域名 → 收益大幅下降，优先考虑
prefetch
crossorigin 属性不是可选，而是强制要求
即使目标域名与当前页同协议、同端口，只要跨域（域名不同），preconnect 就必须带 crossorigin，否则 Safari 和旧版 Chrome 直接忽略该标签。
正确写法：<link rel="preconnect" href="https://cdn.example.com" crossorigin>
错误写法：
-
<link rel="preconnect" href="https://cdn.example.com">→ Safari 不触发 -
<link rel="preconnect" href="//cdn.example.com">→ 协议相对路径被当成非法 URL，静默失败 -
<link rel="preconnect" href="https://cdn.example.com" crossorigin="anonymous">→ 值冗余，crossorigin本身即表示 anonymous
验证 preconnect 是否真起作用
别只看 HTML 有没有那行。打开 Chrome DevTools → Network 面板 → 清空过滤器 → 搜索 preconnect，确认以下三点：
- Initiator 列显示为
preconnect（不是parser或script） - 请求类型是
Other，状态码为200（实际是空响应，但表示连接已建立） - Timing 标签页中 DNS Lookup / Connection Start 时间明显早于后续资源请求
最容易被忽略的是：preconnect 后不能立刻发请求。浏览器需要约 100ms 确保连接真正就绪；如果紧接着就 <img src="https://cdn.example.com/logo.png?x-oss-process=image/resize,p_40">，仍可能触发新连接而非复用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
