preconnect适用于1–2秒内必请求的关键第三方资源，如字体、首屏图片；dns-prefetch适用于后续可能使用的域名，如社交分享接口；同源资源无需预解析，盲目添加反而挤占连接池拖慢首屏。
预解析（dns-prefetch、preconnect）不是“多加几个标签就更快”，它只在特定域名和资源调度节奏下起效；盲目添加反而会挤占主站连接数，拖慢首屏。
什么时候该用 preconnect 而不是 dns-prefetch
核心判断标准是：这个第三方域名的资源是否确定会在 1–2 秒内被请求？比如 CDN 上的字体、首屏图片、核心 JS。
- 确定要用 → 选
preconnect：它完成 DNS + TCP + TLS 三步，比dns-prefetch多省掉 200ms+ 握手时间 - 只是“可能用”或“用户交互后才触发” → 选
dns-prefetch：比如分享按钮背后的微博、微信域名，不抢占连接数，副作用小 - 同源资源（如
https://your-site.com/static/）不需要任何预解析，浏览器自动复用连接
示例：<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> —— 必须带 crossorigin，否则 Safari 会忽略；<link rel="dns-prefetch" href="https://platform.twitter.com"> —— 不需要 crossorigin，也不消耗连接槽位。
preconnect 容易踩的三个坑
它不是“越多越好”，而是受限于浏览器并发连接池（通常最多 6 个），且每个 preconnect 都真实建立连接。
- 不要对未使用的域名写
preconnect：比如配置了但实际没加载该域名资源，连接空耗 5–10s 后关闭，白占 slot - 避免和后续资源请求靠太近：比如
preconnect后立刻<img src="https://cdn.example.com/photo.jpg?x-oss-process=image/resize,p_40">，部分浏览器来不及复用连接，仍走新握手 - 别在
底部或里写：必须放在 HTML 解析早期（靠前位置），否则错过预热窗口
字体预加载必须配合 crossorigin 和 font-display: swap
只写 <link rel="preload" href="inter.woff2" as="font" crossorigin> 不够——如果 CSS 里没设 font-display: swap，浏览器仍会阻塞文本渲染（FOIT），首屏仍是空白。
-
crossorigin是硬性要求：字体属于跨域资源，不加该属性，Chrome/Firefox 直接丢弃 preload 请求 -
font-display: swap必须写在@font-face规则里，不能只靠 preload 补救 - 不要 preload 所有字体变体：只 preload 首屏实际用到的字重和样式，比如
Inter-Regular，而非整套Inter-Black、Inter-Italic
如何验证预解析是否生效
不能只看标签写了没，得看 Network 面板里真实连接行为。
- 在 Chrome DevTools 的 Network 面板开启 “Waterfall” 视图，筛选
Other类型，找preconnect条目，确认状态是Finished而非Cancelled - 对比 preconnect 域名的首个资源请求（如字体）的 “Connection Start” 时间戳：应明显早于未 preconnect 的同类请求
- 用 Lighthouse 的 “Opportunities” 检查项：它会提示哪些可 preconnect 却没写，或哪些写了但未被使用
真正起效的预解析，是让关键资源的请求起点前移 100–300ms；但这个收益只在弱网或首次访问时明显，本地高速网络下几乎不可测——别为跑分硬加，按真实链路节奏来。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
