用 <link rel="preload"> 预加载横幅图片可提前发起请求，需指定 as="image" 和绝对或根相对路径，配合 fetchpriority="high" 提升优先级，避免重复请求需 URL 完全一致且合理配置缓存。
用 link rel="preload" 预加载横幅图片最直接
浏览器默认不预加载 <img> 标签里的图片，等解析到 DOM 才开始请求。横幅（banner）通常是首屏关键内容，延迟加载会导致白屏或闪烁。用 <link rel="preload"> 可在 HTML 解析早期就发起请求，且不阻塞渲染。
关键点：必须指定 as="image"，否则浏览器无法正确设置请求优先级和 CORS 行为；href 必须是绝对路径或根相对路径（如 /images/banner.webp），不能是文档相对路径（如 ./banner.jpg），否则可能 404。
示例写法（放在 <head> 中）：
<link rel="preload" href="/images/banner.webp" as="image" fetchpriority="high">
-
fetchpriority="high"是可选但推荐的，显式提升优先级（Chrome 101+ 支持） - 如果横幅图带
srcset或sizes，预加载只针对主图 URL，无法自动适配不同 DPR/宽度，需按实际首屏加载的版本写死 - 不要对所有 banner 图都预加载——比如轮播中非首帧的图，会浪费带宽
为什么不用 img loading="eager" 替代
loading="eager" 只是告诉浏览器“别懒加载”，但仍要等 DOM 构建到该 <img> 节点才发起请求，比 <link preload> 晚一个解析周期。实测在慢网下，预加载可提前 200–600ms 发起请求。
立即学习“前端免费学习笔记（深入）”；
更关键的是：如果 banner 由 JS 动态插入（比如 CMS 渲染后挂载），<img> 标签根本不会出现在初始 HTML 中，loading 属性完全无效；而 <link preload> 写在 <head> 里，只要 HTML 返回了就能生效。
- 动态渲染场景下，必须靠服务端注入
<link preload>，或在 JS 中用document.createElement('link')+appendChild手动添加（但时机难控） -
img的decoding="async"和fetchpriority是补充优化，不能替代预加载
WebP / AVIF 等现代格式的预加载要注意 MIME 类型
浏览器根据 as="image" 推断请求头 Accept，但服务器若未正确返回 Content-Type: image/webp，部分旧版 Safari 会拒绝解码，导致图片不显示。
验证方法：打开 DevTools → Network → 找到预加载的图片请求 → 查看 Response Headers 中的 content-type。
- CDN 或 Nginx 需配置对应 MIME 类型，例如 Nginx 加：
types { image/webp webp; image/avif avif; } - 不要在
<link>里加type属性——它不被支持，会被忽略 - 如果同时提供 JPEG 备用，预加载只能选一种格式，建议按
Accept请求头做服务端判断后注入对应<link>
预加载后如何避免重复请求
浏览器能识别同一 URL 的预加载和后续 <img src>，自动复用已下载资源，无需额外处理。但前提是 URL 完全一致：协议、域名、路径、查询参数（包括大小写）都必须相同。
- 常见坑：
/banner.jpg和/BANNER.JPG被视为两个资源 - 带时间戳参数的 URL（如
?v=123）必须前后一致，否则预加载失效 - 使用
srcset时，确保<link href>指向的 URL 和srcset中实际被选中的那个 URL 完全匹配
真正容易被忽略的是缓存策略——如果预加载的图片响应头是 Cache-Control: no-store，即使复用成功，下次页面打开仍会重新请求。横幅图建议设为 public, max-age=31536000 并用内容哈希命名。
