最可靠HTML原生预加载图片的方式是<link rel="preload">，它让浏览器在解析HTML早期发起请求，不阻塞渲染且不触发解码，适用于关键首屏图。
用 <link rel="preload"> 预加载图片最可靠
HTML 原生预加载图片，唯一推荐方式是 <link rel="preload">。它让浏览器在解析 HTML 早期就发起图片请求，不阻塞渲染，也不触发解码，适合关键首屏图（如 banner、头图）。rel="prefetch" 或 rel="preconnect" 都不适用——前者是低优先级后台获取，后者只针对域名。
常见错误是把 as 属性写成 "image" 却漏掉 type，导致部分浏览器（尤其是 Safari）忽略预加载或降级为普通 fetch：
-
as="image"必须配合type，例如type="image/webp"或type="image/jpeg" - 如果图片格式不确定（比如 CMS 动态输出），宁可省略
type，也不要硬填错值；现代 Chrome/Firefox 仍能预加载，Safari 则退化为as="fetch"（仍有效，但优先级略低） - 路径必须是绝对或根相对路径（如
/assets/hero.webp），不能用./或../，否则某些构建工具或 CDN 会解析失败
<img> 的 loading="eager" 不是预加载
loading="eager" 只是禁用懒加载，让 <img> 在 HTML 解析时立即触发请求，但它无法早于 DOM 构建完成，更无法在 CSS/JS 加载前启动。相比 <link rel="preload">，它晚一个渲染周期以上，且会立刻触发解码和布局计算，对性能提升有限。
典型误用场景：
立即学习“前端免费学习笔记（深入）”；
- 在
<head>里放<img loading="eager" src="/logo.png">—— 无效，<img>不允许出现在<head> - 用
opacity: 0; position: absolute;把<img>藏在可视区外，指望“提前加载”——这仍是普通图片请求，没有预加载语义，还可能触发无谓的重排
响应式图片要分别预加载
如果你用 <picture> + srcset + sizes，<link rel="preload"> 无法自动匹配媒体条件。浏览器不会根据当前视口选 media 对应的资源去预加载，它只认你写的 href。
所以必须手动判断关键断点，为最可能匹配的资源单独预加载：
- 桌面首屏大概率加载
hero-desktop.webp？那就加一条<link rel="preload" as="image" type="image/webp" href="/img/hero-desktop.webp"> - 移动端用户多？补一条
<link rel="preload" as="image" type="image/webp" href="/img/hero-mobile.webp" media="(max-width: 768px)">—— 注意：media属性仅控制是否应用该<link>，不改变预加载逻辑 - 不要试图用 JS 动态插入
<link>来“精准匹配”，那已错过预加载的最佳时机（DOMContentLoaded 之前）
验证是否生效看 Network 和 Timing
预加载是否真起作用，不能只看资源是否下载了，得看它是不是最早一批请求：
- 打开 DevTools → Network，过滤
Img，找对应图片，看Initiator列是不是Preload - 看
Timing标签页里的Start Time：理想情况应比html文档的End Time还早，或至少与CSS/JS请求并行 - 如果看到
Preload请求状态是cancelled，大概率是href路径 404，或type值与服务端实际Content-Type不符（比如服务器返回image/jpeg但你写了type="image/webp"）
预加载不是万能的——图片太大、CDN 缓存未命中、或用户网络极差时，它只能抢到请求队列的靠前位置，解码和绘制仍需等待。真正影响体验的，往往是后续的渲染阻塞和布局抖动，这点容易被忽略。
