只有当图片确定首屏快速显示且浏览器默认加载太晚时才该用link rel="preload"，如Banner、轮播首图等；必须写在head中、指定as="image"、href用绝对或根相对路径，URL需与实际img标签完全一致才能复用。
什么时候该用 link rel="preload" 加载图片
只有当图片确定会在首屏快速显示、且浏览器默认加载时机太晚时，才值得手动预加载。比如轮播图第一张、Banner 主视觉、关键按钮悬停态图片——这些资源如果等 DOM 解析完再发起请求，可能造成闪动或延迟渲染。别对所有 img 标签都加 preload，它不替代懒加载，也不解决 CDN 缓存问题，只是提前触发网络请求。
link rel="preload" 的写法和关键参数
必须指定 as="image"，否则浏览器不会复用该请求；href 必须是绝对路径或根相对路径（如 /assets/banner.webp），不能是文档相对路径（如 ./img/hero.jpg）；fetchpriority="high" 可选，但仅在 Chromium 内核生效，对 Safari 无效。
<link rel="preload" as="image" href="/assets/hero.webp" fetchpriority="high">
- 不要写
type="image/webp"：现代浏览器靠响应头判断类型，写错反而导致不复用 - 避免重复 preload 同一资源：多个相同
href的link标签不会叠加优先级，只取第一个 - 不要在
body里放link：必须放在head中，否则部分浏览器会忽略
预加载的图片怎么和实际 img 标签关联上
浏览器自动复用的前提是：URL 完全一致（包括查询参数）、as 类型匹配、CORS 设置兼容。常见断联原因：
-
img的src带了时间戳参数（如?v=1712345678），而preload没带 → 请求 URL 不同，无法复用 -
img使用srcset，但preload只写了其中某一分辨率 → 浏览器按实际选中的源匹配，没命中就重发 - 图片托管在跨域 CDN，但
preload没加crossorigin属性，而img有 → CORS 凭证不一致，缓存隔离
稳妥做法：用 preload 对应 img 最终会加载的那个 URL，且保持参数、协议、域名完全一致。
立即学习“前端免费学习笔记（深入）”；
比 preload 更省事的替代方案
如果只是想让首屏图片更快，优先检查是否已启用 loading="eager"（默认值）和 decoding="async"，再确认服务器是否开启 HTTP/2 多路复用与 Brotli 压缩。真正需要 preload 的场景其实很少——多数性能瓶颈不在请求发起时间，而在图片体积、格式、CDN 路径或渲染阻塞上。一个 500KB 的 WebP 图片，即使 preload 了，首字节时间也救不了渲染卡顿。
