预解析通过dns-prefetch（仅dns查询）和preconnect（dns+tcp+tls）提前准备网络连接，需精准匹配资源时机与域名特征，避免冗余或错误配置导致无效。
加载速度能通过预解析提前完成网络准备阶段，把原本串行的“DNS→TCP→TLS”耗时步骤挪到页面解析早期并行执行，从而让真实资源请求一发出就能直接传输数据。关键不在“多加标签”，而在精准匹配资源使用节奏和域名特征。
dns-prefetch：只查域名，轻量无负担
它只做一件事：在浏览器解析到该标签时，立刻发起 DNS 查询，把域名（如 //fonts.googleapis.com）转成 IP 并缓存。不建 TCP 连接、不走 TLS 握手，也不占浏览器并发连接槽位。
- 适用场景：后续可能用到、但不确定何时触发的跨域域名，比如分享按钮调用的微博、微信接口
- 必须写成协议相对路径：//cdn.example.com，不能带
https://或路径（如//cdn.example.com/js/），否则静默失效 - 放在
里<meta charset>和<title></title>之后、首个 CSS 或 JS 标签之前才来得及生效
preconnect：真建连接，专供关键资源
它比 dns-prefetch 多走两步：在 DNS 解析基础上，直接完成 TCP 三次握手和 TLS 协商，相当于把“热连接”提前准备好。省下的不只是几十毫秒 DNS 时间，而是 200ms 以上的完整建连延迟。
- 适用场景：1–2 秒内确定会请求的资源，比如首屏字体、核心 CDN 图片、关键第三方 JS
- 必须带 crossorigin 属性（如
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>），否则 Safari 等浏览器会忽略 - 每个 preconnect 占用一个浏览器连接槽位（通常上限 6 个），写错或冗余会挤占主站资源，反而拖慢首屏
别踩这些坑，否则等于没做
预解析不是“写了就快”，浏览器不会报错提醒你写错了，所有错误都静默忽略——只能靠 Network 面板验证是否真生效。
- 同源资源（如
https://yoursite.com/static/）完全不需要任何预解析，浏览器自动复用连接 - 子域名共享主域 DNS 缓存（如
api.yoursite.com和cdn.yoursite.com都属于yoursite.com），只预解析主域即可 - 不要对不稳定或常被拦截的域名（如广告类
//ad.doubleclick.net）做 preconnect，空连 5–10 秒后关闭，纯属浪费 - 不支持通配符写法，
//*.example.com无效；//a.example.com和//b.example.com必须分别声明
怎么确认它真的起了作用
打开 Chrome DevTools 的 Network 面板，开启 Waterfall 视图，筛选类型为 Other，找 preconnect 或 dns-prefetch 条目：
- 状态显示 Finished 表示成功；显示 Ca（Canceled）说明被中断或未触发
- 对比 DNS 时间列：同一域名后续真实请求（如
<img src="//cdn.example.com/photo.jpg">）的 DNS 时间应明显趋近于 0 - 若页面中根本没发往该域名的请求，预解析就是空转，删掉更干净
