preload、prefetch 和 dns-prefetch 有什么区别？

简化版

preload 提前获取当前导航很快必需的已知资源；prefetch 低优先级准备后续同站导航可能使用的资源；dns-prefetch 只提前解析域名，preconnect 还尝试完成 DNS、连接与 HTTPS 的 TLS 握手。它们都是提示，浏览器可按能力和策略处理，应该少而准并用瀑布验证。

详细版

preload 必须写正确 as，字体和跨源资源还要匹配实际请求的 CORS 模式，否则可能无法复用并重复下载。它只下载缓存，不会像 <script> 或 stylesheet 那样自动执行或应用资源。

prefetch 面向未来导航，优先级通常低于 preload，支持和缓存行为并非所有浏览器一致；当前文档预取还可评估 Speculation Rules。dns-prefetch 成本较低，preconnect 成本更高，只应给当前页确定会访问的少数关键 origin。

资源提示的价值是消除晚发现或连接准备延迟，不是给所有请求提权。fetchpriority 调整同类资源相对优先级，可与 preload 互补，但仍只是浏览器提示。

完整版教学

一、资源提示主要解决“发现太晚”

浏览器的预加载扫描器能从原始 HTML 提前发现常规 img、script 和 stylesheet，但看不到 CSS 背景图、运行时动态导入或客户端稍后生成的 URL。关键资源发现晚，即使很小也要晚开始。

HTML ─发现 CSS→ 下载/解析 CSS ─发现背景图→ 下载图
HTML ─preload 背景图──────────────→ 下载图

记忆钩子：preload 给“当前页确切 URL”，preconnect 给“当前页确切 origin”，prefetch 给“未来页概率资源”。

二、preload 为什么必须与实际消费请求匹配

<link rel="preload"> 安排获取并缓存，不自动执行脚本或应用样式。as 帮浏览器设置请求目的、优先级和安全策略，也帮助后续真实请求复用结果。

<link
  rel="preload"
  href="/fonts/app.woff2"
  as="font"
  type="font/woff2"
  crossorigin
/>

字体请求通常采用 CORS 模式，preload 的 crossorigin 若与实际请求不匹配，缓存键可能不同而重复下载。响应式图片还需保证预载候选与浏览器最终选择一致，否则下载一张、页面又请求另一张。

三、prefetch 面向未来，收益是概率问题

prefetch 告诉浏览器目标可能用于后续同站导航，通常以较低优先级获取。它不是当前页面关键资源的替代品，而且在部分主流浏览器中支持或策略有限。

假设下一页 JS 为 200 KB，1000 次当前页访问只有 300 次跳转；无条件预取下载约 200 MB，其中仅 60 MB 被使用，140 MB 是未命中流量。可以把触发收窄到链接悬停、进入视口或高意图行为。

对文档导航，现代浏览器还可评估 Speculation Rules，但同样要考虑支持、隐私、服务端负载和页面副作用。面试回答应讲目标语义，不把某种提示说成强制执行承诺。

四、dns-prefetch 与 preconnect 的工作量不同

dns-prefetch 只尝试把域名解析成地址；preconnect 进一步建立到 origin 的连接，对 HTTPS 通常还包括 TLS。若最终不请求该 origin，预连接会浪费套接字、CPU 和网络资源。

提示	提前完成	适用信息
dns-prefetch	DNS	可能访问的第三方域名
preconnect	DNS + 传输连接 + TLS	确定很快访问的关键 origin
preload	当前页具体资源获取	已知关键 URL
prefetch	未来页资源获取	高概率后续资源

假设 DNS 40ms、TCP/QUIC 建连 60ms、TLS 70ms，关键第三方 preconnect 理论可遮蔽约 170ms 准备时间；已有连接或缓存时收益会更小，不能把三段固定相加当现场结论。

五、fetchpriority 与 preload 各控制一件事

preload 主要让资源更早被发现并开始获取；fetchpriority="high" 提示浏览器调整相对优先级。一个 LCP 图片即使已在 HTML 中，浏览器初始优先级也可能不够理想，可对最可能的 1–2 张图提高优先级。

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />
<img src="/hero.webp" fetchpriority="high" width="1200" height="675" alt="主视觉" />

提示的实际效果由浏览器决定。给十个资源 high 会失去区分度，也会让它们争抢 CSS、字体和脚本带宽；必须在 DevTools 查看实际 priority 与请求起点。

六、怎样验证提示有效且没有重复请求

先记录无提示时的 waterfall、LCP 分段和缓存状态，再添加最少提示。检查资源是否更早开始、是否只请求一次、是否被页面真正使用，以及关键指标是否改善。

失败现象	常见原因	修正
preload 未使用	URL/候选不一致	对齐真实消费资源
请求两次	`as`/CORS/凭据不匹配	对齐请求模式
LCP 变差	preload 太多抢带宽	删除非关键提示
preconnect 无收益	已复用连接或未请求	只留关键 origin

不要只在热缓存下测，首次访问和重复访问的价值不同。还应在移动弱网检查，因为资源竞争在带宽受限时更明显。

七、常见误区与追问

误区：preload 会自动执行脚本或应用 CSS。 它只提前获取，资源仍要由正常标签消费。
误区：资源提示越多，浏览器加载越智能。 过多提示会覆盖浏览器调度并浪费连接、带宽和缓存。
误区：prefetch 在所有浏览器中都稳定保证命中下一页。 它是有限支持的提示，可能被忽略、取消或受缓存策略影响。
追问：为什么 preload 可能下载两次？ as、CORS、凭据或响应式候选与真实请求不一致，无法复用。
追问：preconnect 为什么要少用？ 每条都会消耗 DNS、连接、TLS 和套接字资源，未使用就是浪费。
追问：fetchpriority 能替代 preload 吗？ 不能，前者提示相对优先级，后者解决已知资源的早发现与获取。
追问：怎样证明资源提示有效？ 对比冷加载瀑布、请求次数、实际优先级和 LCP，而不是只看 HTML 标签存在。

八、加强记忆

用“当页 URL preload、未来资源 prefetch、可能域名 DNS、确定域名连接、同类资源调优先级”区分五种能力。所有提示都服从少而准：请求属性必须和真实消费一致，跨源字体注意 CORS，未来资源看命中率，最终以冷加载瀑布、重复请求和现场指标验证。

简化版

详细版