应使用 <link rel="preload" as="image"> 提前加载首屏关键图片，需确保 href 路径与 <img> 的 src 完全一致、显式声明 as="image" 以复用响应，并避免与 loading="eager" 混淆或 JS 动态创建 Image 实例导致重复请求。
用 <link rel="preload"> 提前加载关键图片
浏览器默认只在解析到 <img> 标签时才开始下载图片，首屏大图容易出现白块或延迟渲染。用 <link rel="preload"> 可在 HTML 解析早期就发起请求，不阻塞渲染，但需手动指定资源类型和路径。
常见错误是漏写 as="image"：没有它，浏览器无法复用预加载的响应，会重复请求；另外 href 必须是绝对或相对有效路径，不能是 JS 动态拼接的字符串。
示例：
<link rel="preload" href="/assets/hero-banner.webp" as="image" fetchpriority="high">
-
fetchpriority="high"适用于首屏核心图（Chrome 101+ 支持），可提升加载优先级 - 不要对所有图片都预加载，只选
<img>渲染前已确定路径、且用户几乎必然看到的关键图 - 预加载的图片仍需在对应位置保留
<img src="/assets/hero-banner.webp">，否则不会显示
避免 loading="eager" 被误当成预加载
loading="eager" 只是禁用原生懒加载，不会提前触发请求 —— 它仍要等到 DOM 中该 <img> 元素被解析到才开始下载，和不加属性基本一致。
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
典型误用场景：在首屏 <img> 上加 loading="eager" 并以为“已经优化了”，结果网络瀑布图里该请求依然排在 HTML 解析靠后位置。
-
loading="eager"仅在loading="lazy"是默认行为的上下文中才有意义（如 Chrome 对非视口内图片自动 lazy） - 它不影响请求发起时机，也不影响资源复用逻辑，和
<link rel="preload">完全不是一回事 - 若想确保某张图不懒加载，直接不写
loading属性更干净（eager是默认值）
JS 动态预加载需注意资源复用边界
用 new Image().src = url 或 fetch(url, {mode: 'no-cors'}) 也能触发下载，但这类方式加载的资源通常无法被后续 <img> 复用，浏览器会当作两个独立请求处理。
原因在于：JS 创建的请求缺乏 as="image" 上下文，响应不能进入图像解码流水线，也无法匹配 <img> 的请求凭证和 MIME 类型校验。
- 如果必须用 JS 控制时机（比如根据用户交互预加载下一页图），优先用
<link rel="preload">动态插入：document.head.appendChild(linkEl) - 动态插入时确保
as="image"和正确的href，且最好在<head>内完成，越早越好 - 避免用
Image()预加载然后赋值给<img>.src，因缓存策略不同，大概率重复下载
预加载 WebP 时要注意格式兼容性 fallback
如果你用 <link rel="preload"> 加载 .webp，但页面中 <img> 用的是 <picture> + <source type="image/webp"> + <img src="fallback.jpg"> 结构，那么预加载的 WebP 在 Safari 14 之前或旧 Edge 中不会生效 —— 浏览器不支持 WebP 就根本不会发那个请求，而预加载标签又没做条件判断。
这意味着：预加载的资源必须和最终渲染所用的资源路径、格式、MIME 完全一致，否则白忙一场。
- 不要预加载
.webp却在<img>中 fallback 到.jpg，除非你用 JS 检测支持后再插入对应<link> - 服务端基于 UA 注入预加载标签更可靠（如 Nginx 或 SSR 框架中判断 WebP 支持）
- CDN 或构建工具能自动为图片生成多格式并注入对应预加载，比手写更可控
<img> 的 src 值是否完全一致 —— 查询参数不同、CDN 域名差异、甚至大小写变化，都会导致缓存不命中。 
