没生效反而更慢，是因为href与img.src不一致、滥用loading="lazy"、动态路径或cdn重定向导致重复请求或缓存失效。
预加载图片加载太慢，不是 preload 本身慢，而是它被误用或与其他机制冲突——比如和 loading="lazy" 同时出现、没配对正确格式、或 preload 的 URL 和最终 img.src 不一致，导致浏览器重复请求甚至跳过预加载。
为什么 link rel="preload" 没生效，反而更慢
浏览器的预加载器（preload scanner）在解析 HTML 时就发起请求，但它只认静态、确定的 href。一旦你写的是动态路径、带查询参数的占位符，或和后续 img.src 值不完全相同，它就无法命中缓存，等于白忙。
-
href必须和最终img标签里实际加载的 URL 完全一致（包括大小写、斜杠、查询参数），否则不会复用连接和响应体 - 别在
href里写hero.jpg?version=1，而img.src是hero.jpg?version=2——这会触发两次下载 - 如果用了
picture+srcset，preload只能指定其中某一个具体资源（如hero-800w.webp），不能只写hero.jpg - 写了
preload却又给同一张图加loading="lazy"：现代浏览器会忽略 preload，因为 lazy 表示“非关键”，而 preload 表示“最高优先级”，逻辑矛盾
preload 该用在哪些图上，怎么选 URL
只对真正影响 LCP（最大内容绘制）的 1–2 张图做 preload，比如首屏 banner、登录头像、主产品图。其他图一律不用。
- 优先选
.webp或.avif格式，且确保服务端已开启对应 MIME 类型支持（image/webp），否则浏览器可能拒绝解码 - URL 必须是最终渲染所用的那张——如果你用
srcset，就 preload 其中匹配当前设备最可能被选中的那个，比如移动端用户大概率用hero-400w.webp - 不要 preload 所有尺寸：例如
hero-400w.webp、hero-800w.webp、hero-1200w.webp全 preload，会抢占带宽，拖慢 CSS/JS 下载
preload 和 loading="eager" 冲突怎么办
Chrome 98+ 开始，loading="eager"（默认值）会覆盖 preload 的优先级判断逻辑，尤其当图片在 DOM 中位置靠后时，浏览器可能延迟发起请求。
- 显式写
loading="eager"没必要，删掉即可；loading属性默认就是 eager - 若发现 preload 后图片仍延迟渲染，检查是否父容器有
overflow: hidden或transform，这会让 IntersectionObserver 失效，间接影响浏览器对 eager 图的调度 - 更稳妥的做法：对关键图直接内联 base64（仅限 ≤ 2KB 小图标），或用 CSS
background-image+content-visibility: auto配合，绕过 img 标签的解析延迟
CDN 和服务端配置让 preload 白费力气的坑
即使 preload 写对了，CDN 缓存策略、服务端自动重定向、或缺失 Cache-Control 头，也会让预加载变成空转。
- 确认 CDN 对
.webp资源返回了Cache-Control: public, max-age=31536000，否则每次都是重新拉 - 避免服务端对图片请求做 302 重定向（比如从
/img/hero.jpg重定向到/cdn/abc123/hero.jpg）——preload 的 URL 必须是最终地址 - 检查响应头是否有
Vary: Accept，它会让 CDN 缓存分裂，Accept: image/webp和Accept: image/jpeg被当成两个资源，浪费缓存空间
真正难的不是写 preload，而是确认它真的被用了：打开 Chrome DevTools → Network → 刷新页面 → 找到那张图的请求，看 Initiator 是 Preload Scanner 还是 img。如果不是前者，说明它没生效——这时候回去查 href 是否一致、是否被 lazy 干扰、CDN 是否重定向，比反复改标签有用得多。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
