preload更适合大图/字体等关键静态资源，因为它强制浏览器立即高优先级加载且不阻塞渲染，而prefetch仅空闲时低优先级加载、无法保障首屏时机；preload必须指定as属性（如as="image"或as="font"）并为字体添加crossorigin，否则资源可能被丢弃。
为什么 link rel="preload" 比 link rel="prefetch" 更适合大图/字体等关键静态资源
因为 preload 是强制提前发起请求、不阻塞渲染，而 prefetch 是空闲时才加载、不保证时机。对首屏可见的大图、Web Font 或关键 CSS 中引用的 @font-face 资源，用 prefetch 基本等于“等用户划到那儿再加载”，起不到优化效果。
-
preload必须指定as属性（如as="image"、as="font"），否则浏览器无法正确设置请求优先级和 CORS 行为 - 字体必须加
crossorigin属性，否则即使预加载了也会被浏览器丢弃（因字体加载策略要求匿名 CORS） - 不要对非首屏图片滥用
preload，它会抢占带宽，反而拖慢真实首屏渲染
如何让大图下载不阻塞 DOM 解析和 JS 执行
直接写 <img src="big.jpg"> 会让浏览器立即触发下载，并在解析 HTML 时阻塞后续脚本执行（尤其当 JS 在 <head> 中）。更可控的方式是延迟触发加载，但又不牺牲用户体验。
- 用
loading="lazy"仅适用于非首屏图片；首屏大图必须设为loading="eager"（默认值），否则可能被延迟到用户滚动后 - 对关键大图，可先用
<link rel="preload" as="image" href="hero.jpg">提前拉取，再配合<img src="hero.jpg" fetchpriority="high">确保解码和渲染优先级 - 避免在
<head>写<script>同步加载逻辑去动态创建<img>——这会引入额外 JS 解析/执行延迟，且失去 preload 的早期网络调度优势
fetchpriority 和 importance 在实际加载队列中的作用差异
两者都影响浏览器内部资源调度优先级，但生效层级不同：fetchpriority 控制网络请求排队顺序，importance（用于 <iframe> 或 <script>）影响任务调度器分配 CPU 时间片。对静态资源下载，只看 fetchpriority 就够了。
-
fetchpriority="high"可让图片、脚本请求插队到当前高优先级队列（如导航、关键 CSS 之后，但早于 background 图片） -
fetchpriority="low"不代表“不加载”，而是排在所有未标记资源之后；慎用于首屏大图 - Chrome 101+ 支持
fetchpriority，Safari 当前（2026）仍忽略该属性，需靠preload+ 正确as值兜底
CDN 缓存头与 Cache-Control 配置如何影响非阻塞下载效果
再好的前端加载策略也架不住服务端返回 Cache-Control: no-cache 或过短的 max-age —— 浏览器每次都要走完整 HTTP 请求流程，根本谈不上“非阻塞下载”的收益。
立即学习“前端免费学习笔记（深入）”；
- 对不变的大图、字体文件，应配
Cache-Control: public, max-age=31536000, immutable（1 年 + immutable 防止协商缓存） - 若资源路径含哈希（如
logo.a1b2c3.png），可放心设长缓存；若用查询参数（logo.png?v=1.2），部分 CDN 会忽略缓存，优先改用文件名哈希 - 确保 CDN 开启 HTTP/2 或 HTTP/3，否则多个
preload请求仍可能因队头阻塞互相拖慢
真正容易被忽略的点：资源是否被浏览器视为“可复用”——比如同一张图在页面中出现两次，但一次用了 preload、一次没用，浏览器不会自动复用前者的结果，除非两次请求 URL 完全一致且缓存策略允许。
