HTML中Link标签DNS-Prefetch在多域CDN环境下的加速阈值-html教程-PHP中文网

应只加真正影响首屏的2～3个cdn域名，如//img0.cdn.com和//js.cdn.com；多余dns-prefetch会被静默丢弃，且需协议相对写法、置于head中meta/title后script前，避免与preconnect混用。

html中link标签dns-prefetch在多域cdn环境下的加速阈值

dns-prefetch 在多域 CDN 场景下到底该加几个

加太多反而拖慢首屏——浏览器对 dns-prefetch 的并发执行数有硬限制，通常为 6～10 个，超出部分会被静默丢弃或延迟调度。多域 CDN（如 //img0.cdn.com、//img1.cdn.com、//js.cdn.com、//fonts.cdn.com）看似要全加，实际只应保留真正影响首屏加载的那几个。

常见错误是把所有 CDN 子域都列一遍，结果前 3 个没被解析完，后 4 个根本没触发。

优先保 //img0.cdn.com 和 //js.cdn.com：首屏图片和关键 JS 很可能从这两域加载
舍弃 //img2.cdn.com 或 //backup.cdn.com：除非你明确在首屏 JS 中做了 new Image().src = "https://img2.cdn.com/..." 这类主动请求，否则它属于“备用路径”，不值得占队列
注意 //fonts.cdn.com 和 //fonts.googleapis.com 是两个独立域名，不能互相替代；但若你只用 Google Fonts，就别再加自家字体 CDN
同一主域下的多个子域（如 cdn1.example.com 和 cdn2.example.com）是否都要加？仅当它们由不同权威 DNS 管理、且实际被首屏资源分别引用时才加；否则 DNS 缓存可共享，加一个就够了

href 写 `//img0.cdn.com` 还是 `https://img0.cdn.com`？

必须用双斜杠协议相对写法：//img0.cdn.com。显式写 https:// 在旧版 Safari（尤其是 iOS 15 之前）中大概率被跳过；写 http:// 在 HTTPS 页面里直接失效，控制台还可能报混合内容警告。

Doc To HTML

使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

下载

协议相对写法让浏览器自动补全当前页协议，兼容性更稳，也避免中间代理或 CDN 边缘节点误判。

✅ 正确：<link rel="dns-prefetch" href="//img0.cdn.com">
❌ 错误：<link rel="dns-prefetch" href="https://img0.cdn.com">（Safari 忽略）
❌ 错误：<link rel="dns-prefetch" href="//img0.cdn.com/logo.png">（含路径，整个标签被静默忽略）
⚠️ 注意：//img0.cdn.com:443 这种带端口的写法无效，DNS 解析不关心端口

为什么加了 dns-prefetch，DevTools 里 DNS Lookup 时间没变短

不是代码没生效，而是浏览器压根没执行——最常见原因是位置放错了。DNS 预解析依赖 HTML 流式解析时机，它必须在浏览器遇到第一个跨域资源请求前就被读到。

✅ 正确位置：<meta charset> 和 <title></title> 之后、首个 <script src="https://..."></script> 或 <link rel="stylesheet" href="https://..."> 之前
❌ 错误位置：塞在里、包在 <template></template> 中、或用 JS 动态创建并 append（document.head.appendChild(link)）——这些都不会触发预解析
⚠️ 验证方法：打开 Chrome DevTools → Network → 找任意一个跨域请求 → Timing 标签页里看 “DNS Lookup” 是否明显早于 “Initial connection”。如果仍是灰色或为 0ms，说明 DNS 已缓存；如果始终没提前，大概率是标签没被识别或位置太晚
? 小技巧：在本地用 chrome://net-internals/#dns 清空 DNS 缓存后重刷，能更真实观察效果

dns-prefetch 和 preconnect 能不能一起用在同一个 CDN 域名上

不能。浏览器看到同一域名同时存在 dns-prefetch 和 preconnect，会直接忽略前者，只执行后者。而 preconnect 开销远高于 dns-prefetch：它要建 TCP 连接 + 完成 TLS 握手，受浏览器并发连接数限制（通常最多 6 个），还会占用 socket 资源。

✅ 推荐组合：对高频、确定必用、支持 HTTPS 的 CDN 域名（如字体服务），直接上 <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
✅ 对低频、异步加载、或只用于埋点上报的 CDN 域名（如 //log.cdn.com），用 dns-prefetch 更稳妥
❌ 同时写两者：<link rel="dns-prefetch" href="//img0.cdn.com"> <link rel="preconnect" href="https://img0.cdn.com"> —— 后者生效，前者白写，还多发一次解析请求
⚠️ 特别注意：preconnect 必须显式声明 crossorigin（即使目标资源本身没配 CORS），否则在多数现代浏览器中会被降级为普通连接，失去预连意义