dns-prefetch仅提前解析DNS，不建连接；preconnect则完成DNS+TCP+TLS全过程。前者轻量毫秒级，后者省200–600ms但有连接池开销。同域名二者不可共存，关键资源用preconnect，次要确定资源用dns-prefetch。
dns-prefetch 只查 IP，不建连接
它干的事非常轻量：告诉浏览器「这个域名我后面大概率要用，你先去 DNS 服务器查一下 IP 地址」。查完就停，不发 TCP 包，不走 TLS，也不占用 HTTP 连接槽位。dns-prefetch 的本质就是一次异步 DNS 查询，毫秒级开销，IE11 都支持。
常见错误现象：Failed to parse 'dns-prefetch' link directive —— 多半是 href 写错了，比如漏了 https:// 或带了路径（https://cdn.example.com/js/app.js 会被整个忽略）。
- ✅ 正确写法：
<link rel="dns-prefetch" href="//fonts.googleapis.com">或<link rel="dns-prefetch" href="https://api.example.com"> - ❌ 错误写法：
<link rel="dns-prefetch" href="fonts.googleapis.com">（无协议，当成本地路径）、<link rel="dns-prefetch" href="http://cdn.example.com">（HTTPS 页面下常被跳过） - 必须放在
<head>靠前位置，建议在<meta charset>和<title>之后、首个<link rel="stylesheet">之前；塞在<body>里或 JS 动态插入，基本无效
preconnect 做完三步：DNS + TCP + TLS
preconnect 不是“更快的 dns-prefetch”，它是另一个量级的动作：提前把整个连接链路跑通——DNS 解析 → TCP 握手 → TLS 协商（HTTPS 下）。等你真正 fetch() 或加载 <img> 时，连接已就绪，直接发数据。
实测在移动网络或高 RTT 场景下，能省掉 200–600ms。但它有代价：每个 preconnect 占用一个 HTTP/1.1 连接池 slot，HTTP/2 下压力小些，但仍建议总数 ≤6。
立即学习“前端免费学习笔记（深入）”；
- ✅ 必须带
crossorigin属性才能复用连接，尤其涉及 CORS 资源时：<link rel="preconnect" href="https://cdn.example.com" crossorigin> - ✅ 适用场景明确：首屏必加载的第三方资源，如
https://fonts.googleapis.com、https://api.example.com、主 CDN 域名 - ❌ 别给 analytics、广告、社交分享这类“可能用但不紧急”的域名上
preconnect——它们更适合dns-prefetch
同一域名不能同时写 dns-prefetch 和 preconnect
浏览器对 preconnect 的优先级更高，且它已隐含 DNS 解析。两者混用同一域名，dns-prefetch 会被忽略，纯属冗余，还可能干扰 DNS 查询队列调度。
调试时打开 Chrome DevTools → Network → Timing 标签页，观察 DNS 查找是否提前出现、TCP/TLS 时间是否压缩。若没变化，先检查控制台是否有解析失败警告，再确认目标域名是否真在后续 JS 中被请求（没请求就不会触发预连接）。
- ✅ 合理组合：
<link rel="preconnect" href="https://cdn.example.com" crossorigin>（关键资源） +<link rel="dns-prefetch" href="https://stats.example.com">（次要但确定会访问） - ❌ 错误组合：
<link rel="dns-prefetch" href="https://cdn.example.com"><link rel="preconnect" href="https://cdn.example.com" crossorigin> - 注意 Safari 对
dns-prefetch执行更保守，常延迟到空闲或用户交互后；而preconnect在主流现代浏览器中基本立即执行
选哪个，关键看“下一步动作”发生的时间和确定性
这不是配置项选择题，而是对资源加载节奏的判断：如果 JS 里第一行就 fetch("https://api.example.com/data")，那就该 preconnect；如果只是“用户点分享按钮后才可能请求微信 SDK”，那 dns-prefetch 更稳妥。
容易被忽略的一点是：同源域名加了也白加，浏览器已自动优化；子域（如 admin.example.com）通常共享主域 DNS 缓存，没必要单独声明；广告联盟域名不稳定、常被拦截，加了反而浪费查询配额。
- 别迷信数量：每个
dns-prefetch都是一次真实 DNS 查询，浏览器并发上限一般为 6～10 个 - 别信“反正加了也没坏处”：无效的
dns-prefetch会挤占队列，拖慢真正关键的 DNS 查询 - 别忘了验证：加完后一定要在真实弱网环境（如 Chrome DevTools 的 Slow 3G 模拟）下测 Timing，否则看不出效果
