预加载需用或JavaScript主动发起，非HTML标签自动行为；loading="lazy"是延迟加载，非预加载；WebP预加载需fallback兜底，且须权衡资源优先级。
图片预加载不是靠 HTML 标签本身“自动完成”的，<img alt="HTML怎么做图片预加载_html图片预加载实现方法【完整版】" > 的 loading="eager" 或 decoding="async" 都不等于预加载；真要提前加载，得靠 JavaScript 主动发起请求，或用 <link rel="preload"> 告诉浏览器“这个图马上要用”。
用 <link rel="preload"> 提前声明关键图片
这是最轻量、最符合语义的预加载方式，适用于首屏核心图（比如 banner、头像、登录页主视觉），浏览器会在空闲时优先获取，且不阻塞渲染。
-
as="image"必须写，否则浏览器无法正确设置请求头和缓存策略 -
fetchpriority="high"可选，对 Chrome 109+ 有效，能进一步提升请求优先级 - 路径必须准确，相对路径基于当前 HTML 文档位置解析，不要写成
./images/hero.jpg却把 HTML 放在子目录下 - 不支持动态路径：不能在
href里写 JS 变量或模板语法，它纯静态
<link rel="preload" as="image" href="/assets/hero.webp" fetchpriority="high">
用 JavaScript 创建 Image 对象触发加载
适合需要逻辑控制的场景：比如用户 hover 某个按钮后预加载下一页的图，或根据设备像素比选择性加载 @2x 版本。
- 创建后立刻赋值
src就会触发加载，无需插入 DOM - 监听
load和error事件可确认是否成功，但注意：失败不会抛异常，得靠回调判断 - 避免内存泄漏：如果预加载大量图，又没保留引用，GC 通常能回收；但若挂到全局变量或闭包里长期持有，需手动清理
src = '' - 不要在循环里密集 new Image() —— 浏览器有并发请求数限制（通常 6~8 个），建议加节流或队列
const img = new Image();<br>img.onload = () => console.log('预加载完成');<br>img.onerror = () => console.error('预加载失败');<br>img.src = '/assets/detail-2x.jpg';
别把懒加载（loading="lazy"）当预加载用
这是最常见的误解。设置 loading="lazy" 是推迟加载，不是提前加载；哪怕你给首屏图片也加了它，Chrome 仍可能延迟到滚动前 500px 才发起请求，完全违背预加载意图。
立即学习“前端免费学习笔记（深入）”；
-
loading="eager"是默认行为，显式写出来也没错，但它只是“不懒”，不等于“提前” -
decoding="async"只影响解码时机（避免主线程卡顿），和下载时机无关 - 如果你发现某张图“怎么还没出来”，先检查是不是误用了
loading="lazy"，而不是急着加预加载
预加载 WebP 时记得 fallback 兜底
预加载的资源如果浏览器不支持（比如旧版 Safari 不支持 WebP），<link rel="preload"> 会静默失败，后续 <img src alt="HTML怎么做图片预加载_html图片预加载实现方法【完整版】" > 仍会按原路径请求——但此时可能已错过最佳加载时机。
- 推荐做法：只用
<link rel="preload">预加载基础格式（如 JPEG/PNG），WebP 交给<picture></picture>在运行时协商 - 如果坚持预加载 WebP，务必同步预加载 fallback 图，并用 JS 检测支持性后决定最终
src - 注意 Service Worker 缓存策略：预加载的资源若被 SW 拦截但没匹配规则，可能直接 404，比不预加载还糟
真正难的不是写那几行代码，而是判断“这张图到底值不值得预加载”——预加载太多会挤占带宽，影响关键资源；预加载太少又留白明显。上线前最好用 Chrome DevTools 的 Network 面板勾选 “Disable cache”，反复刷几次，看真实弱网下首屏图像的请求瀑布流节奏。
