dns-prefetch 标签必须写对 href 才生效，仅支持协议相对路径（如“//cdn.example.com”）或显式 HTTPS 协议，且须置于 head 靠前位置；仅对后续异步请求的第三方域名有效，同源无效；与 preconnect 混用时后者优先。
dns-prefetch 标签写错 href 就等于没写
浏览器只从 href 属性中提取主机名，其余内容全被忽略，且不报任何错误——写错格式根本查不到问题。常见错误包括：
-
href="https://cdn.example.com"：显式协议在 HTTPS 页面里可能被跳过，旧版 Safari 尤其敏感 -
href="//cdn.example.com/js/main.js"：含路径，整个<link rel="dns-prefetch">标签被静默丢弃 -
href="cdn.example.com"：缺协议标识，被当成本地相对路径处理，查的是当前域下的子路径
✅ 正确写法只有两种：<link rel="dns-prefetch" href="//cdn.example.com">（推荐，适配当前页协议）或 <link rel="dns-prefetch" href="https://fonts.googleapis.com">（HTTPS 页面更稳，避免协议降级）。
必须放在 <head> 靠前位置，晚了就白加
浏览器是流式解析 HTML 的，<link rel="dns-prefetch"> 一旦被读到就立即排队执行 DNS 查询。如果放得太晚，相关资源请求早就发出去了。
- ✅ 理想位置：
<meta charset>和<title>之后、首个<link rel="stylesheet">或<script>之前 - ❌ 无效位置：塞在
<body>里、包裹在<template>中、用 JS 动态创建并插入（如document.createElement('link')） - ⚠️ 注意：它不阻塞渲染，但若排在大量 CSS/JS 后面，DNS 查询可能被首屏关键资源抢占调度优先级
只对确定会用的第三方域名生效，同源域名加了也白费
dns-prefetch 不加速当前页面首屏资源，只影响后续异步请求（如懒加载图片、首屏后 fetch 的 API、字体 CSS 加载等）。加错对象反而浪费 DNS 并发队列（通常限 6～10 个）。
立即学习“前端免费学习笔记（深入）”；
- ✅ 值得加：
//cdn.example.com（真实加载了图片/JS/CSS）、//api.example.com（首屏后立即发起 AJAX）、//hm.baidu.com（统计脚本初始化必调） - ❌ 不该加：
//your-site.com（同源域名浏览器已缓存解析）、//service.qq.com（用户点击才跳转，更适合rel="prefetch"） - ⚠️ 特别注意：如果目标域名只支持 HTTPS，但当前页是 HTTP，
//写法会降级为 HTTP 协议导致失败——这种场景应改用<link rel="preconnect">并显式声明crossorigin
和 preconnect 混用同一域名，后者会直接覆盖前者
dns-prefetch 只做 DNS 解析；preconnect 会进一步建连 + TLS 握手，开销更大但收益更高。两者目标重叠，浏览器不会同时执行。
- ✅ 推荐策略：对“一定会用、且几秒内就发请求”的域名（如首屏关键 CDN JS），直接上
<link rel="preconnect" href="https://cdn.example.com" crossorigin> - ✅ 对“有可能用、但不确定是否触发”的域名（如备用埋点、分享按钮背后的社交平台），用
dns-prefetch更稳妥 - ❌ 同一域名既写
preconnect又写dns-prefetch：后者被忽略，纯属冗余
实际效果依赖网络环境和浏览器调度，Safari 对 dns-prefetch 执行更保守，常延迟到空闲或用户交互后；DNS 缓存默认仅 60–300 秒，长停留后点击仍可能重新查——这些细节容易被忽略，但直接影响优化是否真正落地。
