加 <link rel="dns-prefetch"> 有效，但必须放 <head> 最前面、用 // 协议相对路径、仅限首屏必用域名，否则反而拖慢首屏。
直接说结论：加 <link rel="dns-prefetch"> 有效，但加错位置、写错格式、乱加域名，反而拖慢首屏——关键不是“有没有”，而是“加给谁”和“怎么加”。
href 必须用 // 协议相对写法，不能带 http:// 或 https://
浏览器会根据当前页面协议（HTTP/HTTPS）自动补全，硬写协议头在某些旧版 Safari 或混合协议场景下会被跳过，等于白加。
- ✅ 正确：
<link rel="dns-prefetch" href="//cdn.example.com"> - ❌ 错误：
<link rel="dns-prefetch" href="https://api.example.com">（显式 HTTPS，部分 Safari 忽略） - ❌ 错误：
<link rel="dns-prefetch" href="http://fonts.googleapis.com">（HTTP 页面可能勉强行，HTTPS 页面直接失效） - ⚠️ 注意：
//fonts.gstatic.com和//fonts.googleapis.com是两个独立域名，不能互相替代
必须放在 <head> 最前面，不能塞在 <body> 或 JS 动态插入
浏览器是流式解析 HTML 的，<link rel="dns-prefetch"> 需在首次遇到跨域资源前就被读到，否则来不及触发预解析。
- ✅ 正确位置：
<head>开始后、首个<link rel="stylesheet">之前 - ❌ 错误做法：丢在
<body>底部、用document.write()注入、或等 JS 执行完再appendChild - ⚠️ 它不阻塞渲染，但浏览器只在空闲时执行；放太晚，可能被首屏 CSS/JS 抢占 CPU 和网络带宽
只加确定会用的第三方域名，别为子域或广告联盟凑数
每个 dns-prefetch 都是一次真实 DNS 查询，浏览器并发上限通常 6～10 个，无效查询既耗资源又干扰真实请求优先级。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- ✅ 值得加：
//cdn.example.com（图片/JS/CSS）、//api.example.com（首屏接口）、//stats.example.com（初始化埋点） - ❌ 别加：
//ad.doubleclick.net（广告域名不稳定、常被拦截）、//backup-cdn.example.com（备用 CDN 实际未加载）、//admin.example.com（同主域，DNS 缓存已共享） - ⚠️ 不支持通配符：
//*.example.com无效；也不必为cdn1、cdn2分别加，除非它们由不同权威 DNS 管理
别和 preconnect 混用同一域名
dns-prefetch 只做 DNS 解析，开销极低；preconnect 会进一步建 TCP 连接 + TLS 握手，资源占用高，且受浏览器并发限制（通常最多 6 个）。
- ✅ 同一域名只选一个：
preconnect更激进，适合确定高频使用且支持 HTTPS 的域名（如字体服务） - ✅ 若只是“可能用到”或“用户触发后才发请求”，用
dns-prefetch更稳妥 - ❌ 同时写两者：
preconnect会覆盖dns-prefetch，后者被忽略，纯属冗余
最容易被忽略的一点：它不保证执行。弱网、内存紧张、或浏览器忙于首屏渲染时，dns-prefetch 可能被直接跳过。所以别指望它兜底，只把它当作“锦上添花”的轻量提示，核心优化还得靠资源压缩、CDN、缓存策略这些实打实的手段。
