dns-prefetch仅对后续异步请求生效，需正确格式（如//cdn.example.com）、置于meta/title后首个外部资源前，且不超并发上限；同源或已解析域名无需添加，滥用反拖慢性能。
dns-prefetch 不加速首屏资源加载
它只对 JS 中 fetch()、懒加载图片、字体 CSS 引入、点击后动态加载的第三方组件等「后续异步请求」生效。首屏直接写在 HTML 里的 <script src="https://cdn.example.com/app.js"> 或 <link rel="stylesheet" href="https://cdn.example.com/main.css">，浏览器解析到就立刻发请求，dns-prefetch 再早也赶不上——除非你把预解析标签放在这些标签之前，且目标域名尚未被解析过。
href 格式错一点就完全失效，且零报错
浏览器只提取 href 中的主机名，其余内容全丢弃，写错等于没写，控制台不提示、Network 面板无记录，极难排查。
-
//cdn.example.com✅ 正确（协议相对 URL，推荐） -
https://fonts.googleapis.com✅ 可接受（HTTPS 页面更稳） -
https://cdn.example.com/js/app.js❌ 含路径，整个标签被静默忽略 -
cdn.example.com❌ 缺//，被当成本地路径处理 -
http://api.example.com❌ HTTPS 页面中 Safari 等常跳过
位置放错等于白加，且 Safari 行为更保守
必须紧接在 <meta charset> 和 <title> 之后、首个外部资源（如 <link rel="stylesheet"> 或 <script src>）之前。塞进 <body>、插在 JS 后、或用 JS 动态插入，DNS 查询根本不会触发。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- Safari 14+ 虽支持，但常延迟到页面空闲或用户 hover 后才执行，不像 Chrome 那样在 HTML 解析阶段就排队
- 即使位置正确，若前面堆了大量 CSS/JS，DNS 查询可能被首屏关键资源抢占调度优先级
- uBlock Origin 等广告拦截扩展会主动屏蔽
dns-prefetch请求，实测时需禁用扩展验证
并发上限硬限制，乱加反而拖慢真实请求
每个 dns-prefetch 都是一次真实 DNS 查询，浏览器并发队列通常仅开放 6～10 个槽位。无效或冗余的预解析不仅浪费系统资源，还可能挤占后续真实请求的查询机会。
立即学习“前端免费学习笔记（深入）”；
- 同源域名（如
//your-site.com）没必要加，浏览器已缓存或自动优化 - 子域共享主域 DNS 缓存（如
//admin.example.com和//cdn.example.com），加一个就够了 - 广告、社交分享等“可能用但不紧急”的域名，更适合用
rel="prefetch"，而非dns-prefetch - 同一域名不能同时写
dns-prefetch和preconnect，后者会覆盖前者，纯属冗余
