rel="preconnect"会提前完成DNS解析、TCP握手和TLS协商，而rel="dns-prefetch"仅做DNS解析；前者适用于即将高频加载的关键第三方域名，后者适合可能用到但非必需的场景。
什么是 rel="preconnect 和 rel="dns-prefetch"
它们不是 CDN 缓存命中率的直接开关，而是浏览器提前建立连接的提示符，间接影响资源是否能更快、更稳定地从 CDN 节点加载——尤其在首次访问或跨域场景下。CDN 命中率本身由缓存策略、URL 一致性、响应头决定，但若浏览器连 DNS 解析或 TCP 握手都卡住，再高的命中率也白搭。
常见误判：看到页面加载变快，就以为 CDN 命中率提升了；其实只是连接更快了，资源可能仍从源站返回（x-cache: MISS）。
-
rel="preconnect"：让浏览器提前与 CDN 域名建立 DNS 查询 + TCP 连接 + TLS 握手（如果 HTTPS），适用于即将被<script></script>或<img alt="怎么在静态资源部署中利用 HTML 的资源提示符优化 CDN 节点的命中率" >加载的第三方域名 -
rel="dns-prefetch"：只做 DNS 查询预热，开销更小，适合不确定是否一定会用到该域名的场景 - 二者都必须写在
中，且只对明确知道的 CDN 域名有效（如https://static.example.com），不能写https://cdn.jsdelivr.net后又加载https://cdnjs.cloudflare.com却不加对应提示
什么时候该加 preconnect？看 Network 面板里的「Connection Start」时间
打开 DevTools → Network → 刷新页面 → 找一个关键 JS/CSS 请求（比如 app.abc123.js），点开它，在 Timing 标签页里看「Connection Start」到「Request Start」之间的 gap。如果超过 100ms，尤其是首次访问时，说明 DNS/TLS 拖慢了加载，这时加 preconnect 才有价值。
不要盲目加一堆：preconnect 会抢占浏览器并发连接数（通常上限 6 个），加多了反而阻塞其他资源。
立即学习“前端免费学习笔记（深入）”；
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 只对真正会用到的 CDN 域名加，例如你用了
https://static.example.com放 JS/CSS，就加：<link rel="preconnect" href="https://static.example.com"> - 如果同时用了多个 CDN（比如字体走
fonts.googleapis.com，图标走cdn.jsdelivr.net），每个都要单独写一行，不能合并 - 不要对
http://域名使用preconnect（现代浏览器会忽略），也不要在 HTTP 页面里对 HTTPS CDN 域名 preconnect（会失败）
preconnect 为什么不能替代缓存策略？
它解决的是“连接快”，不是“内容新”或“命中稳”。即使你加了 preconnect，如果 CDN 返回的响应头是 Cache-Control: no-cache，或者 URL 没带哈希（比如 main.js 总是同一个路径），那每次请求还是得回源，命中率照样低。
真实瓶颈常藏在别处：
- HTML 里写了
<script src="/js/main.js"></script>，但构建后没自动加 CDN 前缀，结果请求发到了源站而非 CDN - 图片用
import logo from './logo.png'引入，Vite 自动重写为 CDN 地址；但模板里硬写的<img src="logo.png" alt="怎么在静态资源部署中利用 HTML 的资源提示符优化 CDN 节点的命中率" >没被处理，仍走相对路径 - CDN 控制台没开启「忽略查询参数」，而你资源 URL 带了
?v=20240613，导致同一文件被当成多个 URL 缓存
验证是否真起作用：看 Timing + x-cache 头缺一不可
加完 preconnect 后，不能只看页面整体变快了就认为成功。要分两步验证：
- 在 Network 面板里，找那个 CDN 域名的请求（比如
https://static.example.com/js/app.abc123.js），展开 Timing，确认「Connection Start」明显提前（理想是接近 0ms） - 同时检查 Response Headers，必须看到类似
x-cache: HIT或x-cdn-cache: HIT字段，且 Size 列显示真实字节数（不是from memory cache） - 禁用浏览器缓存（DevTools → Network → ✅ Disable cache），再刷新，否则你看到的可能是本地缓存，不是 CDN 边缘节点响应
最容易被忽略的是：preconnect 只加速首次连接，后续复用连接靠的是 HTTP/2 多路复用和浏览器连接池管理——它不改变缓存逻辑，也不修复 CORS 或路径错误。真正决定 CDN 命中率的，永远是 URL 稳定性、缓存头配置、以及构建工具是否把所有资源路径都正确指向了 CDN 域名。
