dns-prefetch对第三方CSS加载仅在特定条件下有效：需异步加载或位于首屏关键CSS之后，且域名未预解析；同步CSS无加速效果。必须严格匹配主机名、置于head靠前位置、避免同源或无效域名。
dns-prefetch 对第三方 CSS 加载是否有效？
只在特定条件下有效：当 <link rel="stylesheet"> 是异步加载（比如通过 JS 动态插入）、或位于首屏关键 CSS 之后、且域名未被预解析时，dns-prefetch 才可能缩短其 DNS 阶段耗时。它对 <head> 中同步加载的第三方 CSS 没有加速效果——浏览器解析到 <link> 标签时才开始 DNS 查询，此时再往前加 dns-prefetch 已来不及。
href 域名写法必须严格匹配 CSS 实际请求地址
常见错误是直接复制 CSS 的完整 URL，比如：https://fonts.googleapis.com/css2?family=Roboto，然后填进 href。这会导致整个 <link rel="dns-prefetch"> 被浏览器静默丢弃。
- ✅ 正确做法：只取协议相对主机名，如
//fonts.googleapis.com或显式 HTTPS 主机名https://fonts.googleapis.com - ❌ 错误写法：
//fonts.googleapis.com/css2（含路径）、http://fonts.googleapis.com（HTTPS 页面下常被跳过）、fonts.googleapis.com（缺协议标识，被当成本地路径） - ⚠️ 注意：如果该域名只支持 HTTPS（如 Google Fonts），而当前页面是 HTTP，
//写法会降级为 HTTP 请求失败；此时应改用<link rel="preconnect">并带上crossorigin
必须放在 <head> 靠前位置，且不能晚于对应 CSS 的 <link>
浏览器流式解析 HTML，dns-prefetch 一旦被读到就立即排队执行 DNS 查询。若它出现在目标 CSS 的 <link> 标签之后，或者被塞在 <body> 里、由 JS 动态创建，等于没写。
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- ✅ 推荐位置：
<meta charset>和<title>之后、首个样式表或脚本之前 - ❌ 无效位置：包裹在
<template>中、放在<script>后面、或紧跟在<link rel="stylesheet" href="https://fonts.googleapis.com/...">后面 - ⚠️ 即使位置正确，若前面堆了大量阻塞渲染的 CSS/JS，DNS 查询可能被调度延迟——它不抢占优先级，只是“排队等空闲”
别给同源或已缓存域名加 dns-prefetch
每个 dns-prefetch 占用浏览器 DNS 并发队列（通常最多 6～10 个），乱加反而挤占真实请求资源。
立即学习“前端免费学习笔记（深入）”；
- ✅ 值得加：页面后续 JS 中会
fetch的 API 域名、懒加载图片所用 CDN、字体 CSS 所在第三方域名（如//fonts.gstatic.com） - ❌ 不该加：
//your-site.com（同源，DNS 已缓存）、//cdn.your-site.com（子域共享主域缓存）、//ad.doubleclick.net（广告域名不稳定、常被拦截或延迟高） - ? 小技巧：用 Chrome DevTools 的 Network → Filter → “dns” 查看实际触发的 DNS 查询，验证是否生效
