link rel="preload" 是唯一能真正提前触发多媒体资源下载且不阻塞渲染的标准方式，仅对当前页有效，必须严格匹配 as 类型（如 font、image、video、audio）及 crossorigin 等上下文参数，否则浏览器直接忽略；适用于首屏立即需用但浏览器发现太晚的资源，如 CSS 中的字体、内联样式中的首屏图、视频 poster 或交互音效，而非 <img> 或 <video src> 等已由浏览器自动优化的元素。
link rel="preload" 是唯一能真正提前触发多媒体资源下载、又不阻塞渲染的标准方式，但它只对当前页有效，且必须严格匹配 as 类型和加载上下文——写错或漏掉关键参数，浏览器就当它不存在。
哪些多媒体资源适合用 preload？
不是所有媒体都该预加载，只有“首屏立即要用、但浏览器发现太晚”的才值得干预：
-
as="font"：CSS 中@font-face引用的.woff2或.woff，否则 FOIT 延迟明显 -
as="image"：首屏<picture>里的关键<source>（如 banner.webp），或内联style中的background-image -
as="video"：带preload="metadata"的视频，若需首帧秒出，可preload其 poster 图或关键片段（注意：不能直接preload整个 MP4，浏览器不支持） -
as="audio"：播客首页的封面音频图标、或交互式音效文件（如点击反馈音），但别 preload 整段播客音频
别对 <img src> 或 <video src> 直接套 preload——浏览器已自动优化这些元素；也别 preload 懒加载区域的图/视频，纯属抢带宽。
as 写错等于没写，常见类型与坑点
as 不是提示，是强制指令。浏览器靠它决定请求头、CORS 策略、缓存分区和优先级。填错直接失效：
立即学习“前端免费学习笔记（深入）”；
-
as="font"必须配crossorigin，哪怕字体同源——不加，Chrome/Safari 加载完也丢弃 -
as="image"不支持srcset或sizes，只认静态 URL；type="image/webp"可提升 MIME 匹配精度，但非必需 -
as="video"和as="audio"仅影响请求优先级和缓存归属，不改变播放行为；它们不触发canplay事件，也不能替代<video preload> - 错写成
as="video/mp4"或as="webp"—— 浏览器无视整个标签；合法值只有video、audio、image、font等基础类型
验证 preload 是否真起作用
光看 HTML 有没有那行代码毫无意义，得进 Chrome DevTools Network 面板确认三件事：
- 筛选资源名后，
Initiator列必须显示preload，不是parser或script -
Priority应为Highest（font）、High（image、style），绝不能是Low - 跳转到下一页后，如果该资源又被用到（比如复用同一张 banner 图），Network 中应显示
200 (from memory cache)或304；若仍是200（disk cache 或网络请求），说明没复用成功
特别注意：preload 资源进的是当前页专属缓存池，路径稍有差异（比如 /img/logo.jpg vs img/logo.jpg）就无法命中，且不会跨页面共享——这点和 prefetch 本质不同。
