先说几个关键结论:即便你在页面中加入了 标签,也不意味着它一定会发挥作用。在实际项目中,约 90% 的失效场景,归根结底都是由于 href 地址配置错误、标签放置位置不当、或者将其添加给了本不需要预解析的域名。

添加 并不等于它已生效,绝大多数失效原因都集中在 href 写错、标签位置有误、或选错了优化目标域名这三个方面。
href 必须使用 // 开头的纯域名格式
浏览器仅识别 href 属性中的主机名部分,其余多余内容会被直接忽略,并且不会给出任何错误提示——一旦写错,这条标签就相当于白写。
- ✅ 标准写法:
,采用协议相对 URL,能自动适应当前页面的 HTTP 或 HTTPS 环境。 - ✅ 备选写法:
,但仅适用于 HTTPS 页面,可避免旧版 Safari 在协议降级时出现的问题。 - ❌ 常见错误:
,在 HTTPS 页面环境下经常被浏览器主动跳过。 - ❌ 常见错误:
,一旦包含路径信息,整条标签会被浏览器静默丢弃而不生效。 - ❌ 常见错误:
,缺少协议标识符,浏览器会将其误判为本地相对路径进行处理。
必须放在 中靠前位置,且早于首个外部资源请求
浏览器采用流式解析 HTML 的方式工作,当读到 标签时,会立即将其加入 DNS 查询队列。如果放置过晚,页面上的其他资源请求早已发出,这个标签的预解析价值就会大打折扣。
- ✅ 建议放置顺序:
→→ 多个→ 首个或。 - ❌ 无效放置场景:放在
中、嵌套在内部、或通过 JavaScript 动态生成(例如document.createElement('link')),这些方式都无法触发预解析。 - ⚠️ 即使标签位置正确,如果前面堆积了大量阻塞渲染的 CSS 或 JavaScript 资源,DNS 查询的调度时机仍可能被延迟,实际执行效果会变得不可控。
只对后续真实请求的第三方域名产生效果
该标签并不会加速同源资源的首屏加载,它主要影响的是 JavaScript 中的 fetch() 调用、懒加载图片、以及字体 CSS 加载这类异步请求。
- ✅ 值得添加的域名类型:
//cdn.example.com(页面中实际加载了图片、JS、CSS 等资源)、//api.example.com(首屏后立即发起 AJAX 数据请求)、//hm.baidu.com(统计脚本初始化时必须调用的域名)。 - ❌ 不建议添加的域名:
//your-site.com(同源域名,DNS 已被浏览器缓存)、//ad.doubleclick.net(广告域名稳定性差,常被拦截)、//admin.example.com(子域名与主域名共享 DNS 缓存,预解析意义不大)。 - ⚠️ 浏览器的 DNS 并发查询数量通常限制在 6 到 10 个,添加过多域名会挤占有限队列,反而拖慢关键资源的解析速度。
避免与 preconnect 作用于同一域名
preconnect 已经内置了 DNS 解析步骤,当两者同时出现时,dns-prefetch 会被浏览器忽略,甚至可能干扰正常的资源调度逻辑。
- ✅ 场景分工策略:对于“确定即将使用”的 1 到 2 个关键域名(例如字体服务、主要 API 接口),直接使用
;其余确定会用到但非首屏关键的域名,则采用dns-prefetch进行轻量预解析。 - ❌ 典型错误:为
//cdn.example.com同时配置dns-prefetch和preconnect,后者会覆盖前者,前者完全成为冗余代码。 - ⚠️
preconnect的资源开销较大(涉及 TCP 连接和 TLS 握手),失败时还可能占用连接池资源;dns-prefetch虽然轻量,但带来的性能收益也相对有限,不能指望它解决所有网络延迟问题。
这项技术的真正难点,并不在于添加标签这个操作本身,而在于准确判断“这个域名接下来到底会不会被真实请求”“它是否值得占用一个宝贵的 DNS 并发名额”——这些决策无法完全依赖自动化工具,必须结合网站自身的资源加载逻辑和真实的用户行为数据来综合判断。
