dns-prefetch仅提前解析dns不建连，必须写在最前、用//开头的纯域名，只对页面真实使用的高频跨域域名有效，否则反而拖慢首屏。
直接结论：页面结构空白（白屏）不是 HTML 没渲染出来，而是浏览器卡在 DNS 解析上，尤其在首次访问、第三方资源多、或用户本地 DNS 服务差时，DNS Lookup 阶段可能耗时 200–300ms 甚至更久——这个阶段浏览器连 HTML 都还没开始下载，自然一片空白。
为什么 dns-prefetch 要写在
浏览器解析 HTML 是流式的，<link rel="dns-prefetch"> 必须在第一个 <script></script> 或 <link rel="stylesheet"> 之前触发，否则会被阻塞。一旦 HTML 解析被同步脚本打断，预解析就晚了。
- 放在
开头（紧贴<meta charset>后），确保它最早被 parser 识别 - 不要包裹在
<script></script>里动态插入——此时 DNS 查询早已错过最佳时机 - 避免用 JS 判断环境再加，
dns-prefetch是声明式提示，不执行 JS 就能生效 - 多个域名建议分行写，而不是合并成一个 href，便于浏览器并行处理
dns-prefetch 和 preconnect 到底该用哪个？
两者目的不同：dns-prefetch 只做域名到 IP 的映射；preconnect 还会提前建立 TCP 连接甚至 TLS 握手。选错会导致浪费资源或被忽略。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 只确定要用某个域名（比如 CDN 或字体库），但暂时不加载资源 → 用
<link rel="dns-prefetch" href="//cdn.example.com"> - 该域名下有关键资源（如首屏 JS/CSS），且你确认一定会用 → 改用
<link rel="preconnect" href="https://cdn.example.com" crossorigin> -
preconnect必须带协议（https://），且若跨域要加crossorigin属性，否则无效 - 别对所有第三方都
preconnect，每个连接消耗内存和 socket，Chrome 建议最多 6 个
哪些域名不该加 dns-prefetch？
不是所有外部域名都适合预解析，加错反而拖慢主线程、触发无意义查询，甚至暴露用户行为。
- 广告、统计类域名（如
//analytics.example.com）慎用——它们常被广告拦截器屏蔽，预解析白费力气 - 用户交互后才加载的域名（如点击“登录”后才请求的 OAuth 提供商）没必要提前查
- 拼写错误或已下线的域名，会触发失败日志并占用 DNS 查询配额
- 带路径的 href（如
href="//api.example.com/v1/user"）是错的，dns-prefetch只接受域名或协议+域名，路径会被忽略但易误导维护者
真正起效的优化不在“加了多少个 dns-prefetch”，而在于是否精准覆盖了 HTML 解析过程中**第一个阻塞性资源请求前**必须解析的域名。漏掉 CDN 或字体域名，白屏时间几乎不变；加多了无关域名，反而增加系统 DNS 缓存压力——这点容易被忽略，但影响真实首屏稳定性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
