HTML 中的 <link rel="dns-prefetch"> 和 <link rel="preconnect"> 才真正加速 JS 资源加载：前者仅预解析 DNS，轻量且适用于可能延迟触发的跨域请求；后者完成 DNS+TCP+TLS 预连接，适用于确定性高频资源，但需带 crossorigin 且避免冗余混用，且必须置于 <head> 靠前位置。
JavaScript 本身不直接控制 DNS 解析或 TCP 连接建立，但页面加载中大量 JS 资源（尤其是跨域 SDK、埋点脚本、字体加载器、动态 import 的 CDN 模块）的请求时机，高度依赖网络层准备是否就绪。真正起加速作用的是 HTML 中的 <link rel="dns-prefetch"> 和 <link rel="preconnect">，它们为 JS 发起的 fetch、XMLHttpRequest 或资源加载铺平道路——关键不在 JS 写法，而在 HTML 预置策略是否精准。
dns-prefetch：只查 IP，轻量无负担
它告诉浏览器：“这个域名我后面大概率要用，你先悄悄去查下 IP，别等 JS 执行到 fetch('https://api.example.com/user') 才开始手忙脚乱。” 查完即停，不建连接、不占并发槽位、毫秒级开销，IE11 都支持。
-
必须写对 href：只接受协议相对路径（
//api.example.com）或显式 HTTPS 域名（https://fonts.googleapis.com）。带路径（//cdn.example.com/js/app.js）、缺协议（api.example.com）、HTTP 协议（http://xxx）全被静默忽略——调试时 Network Timing 里根本看不到 DNS 查找提前，等于没写。 -
只对跨源有效：同站域名（如
https://your-site.com）无需加，浏览器自动复用已有连接；加了也无效。 - 适合“可能用”或延迟触发的场景：比如用户点击分享按钮才加载微博 SDK，或表单提交后才调用风控接口——这些由 JS 控制的异步行为，提前做 DNS 解析就能省掉首次请求的 50–300ms 延迟。
preconnect：连通链路，省下 200–600ms
它不只是查 IP，而是把整个“DNS → TCP 握手 → TLS 协商”三步全跑完，等 JS 调用 fetch() 或 new Image().src 时，连接已就绪，数据直接发。
-
必须带 crossorigin：尤其涉及 CORS 资源（如字体、CDN 图片、API）时，漏掉
crossorigin属性，Safari 会直接忽略该 preconnect —— Chrome 可能勉强生效，但无法复用连接，白费力气。 - 有真实开销：每个 preconnect 占用一个 HTTP/1.1 并发连接槽位（通常最多 6 个），移动端更敏感。别给分析脚本、广告、社交按钮这类非首屏必需的域名上 preconnect。
-
只用于确定性高频资源：比如页面一打开 JS 就立即 fetch 的主 API 域名、首屏必加载的字体托管域名（
https://fonts.gstatic.com）、核心静态资源 CDN。实测在 4G 或高延迟网络下，能稳省 200–600ms。
二者不能混用同一域名
如果同时写了：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
<link rel="dns-prefetch" href="//api.example.com"><link rel="preconnect" href="https://api.example.com" crossorigin>
浏览器会直接忽略 dns-prefetch —— 因为 preconnect 已隐含 DNS 解析，重复声明纯属冗余，还可能干扰调度队列。选一个：确定马上用，选 preconnect；只是“备用”，选 dns-prefetch。
位置决定成败
两个标签都必须放在 <head> 靠前位置：<meta charset> 和 <title> 之后、首个外部 CSS 或 JS 之前。浏览器是流式解析 HTML 的，放得太晚，JS 脚本已经发起请求了，预解析根本来不及生效。塞在 <body> 里或用 JS 动态插入，基本无效。
