网页底部图片通常不值得预加载，因其往往不会被用户看到，强行预加载会抢占首屏关键资源带宽、降低lighthouse评分，且缓存命中率低；应优先使用loading="lazy"或优化图片格式与cdn缓存。
网页底部图片通常不值得预加载——浏览器默认的资源调度机制已经足够高效，强行预加载反而可能挤占首屏关键资源带宽，拖慢用户最关心的部分。
为什么不该预加载底部图片
预加载的本质是“告诉浏览器：这张图马上要用”，但底部图片往往在用户滚动很久后才进入视口，甚至根本不会被看到。浏览器对 link rel="preload" 的请求会提升优先级，可能抢占 banner、logo、首屏 hero 图的下载带宽；Chrome 的资源调度器还会将它纳入关键路径评估，影响 Lighthouse 性能评分。
- loading="lazy" 是它的天然归宿：浏览器会在滚动前约 500px 才发起请求，既节省流量又不阻塞首屏
- 如果页面很短（底部接近首屏），那它本就属于常规同步加载范围，无需额外干预
- 用
link rel="preload"加载底部图，相当于让浏览器“提前做无用功”，缓存命中率低，还浪费 HTTP/2 连接数
什么情况下可以考虑预加载底部内容
极少数真实场景下，底部存在必须快速响应的交互元素，比如“回到顶部”按钮的 hover 状态图、“客服二维码”弹层主图，或页脚导航图标组。这时预加载才有意义，但对象不是“整个页脚”，而是其中明确会高频触发的资源。
- 只对具体
img元素或其背景图 URL 单独处理，而非整块 footer 区域 - 确保该资源确实会被立即使用（例如 hover 后 100ms 内就要显示），否则仍是干扰
- 优先用
link rel="preload"（写在中），而不是 new Image() —— 后者在页脚 DOM 尚未解析时执行容易出错 - 必须配
as="image"和准确路径，例如：<link rel="preload" as="image" href="/assets/footer-qr.webp">
更稳妥的替代方案：按需触发 + 缓存复用
如果你发现用户滚动到底部后，某张图加载有明显延迟，问题大概率不在“是否预加载”，而在图片本身体积大、格式旧、CDN 缓存未命中。与其提前加载，不如优化交付链路：
- 检查该图是否用了 WebP/AVIF 格式；若仍为 JPG/PNG，压缩率和尺寸很可能没调优
- 确认 CDN 是否对该路径设置了合理缓存头（
Cache-Control: public, max-age=31536000） - 给
<img>加上decoding="async"，避免解码阻塞主线程（尤其多图并排时） - 如果页脚有 JS 控制的动态模块（如“订阅表单”的验证图标），可在模块初始化时用
new Image()按需加载，且务必先绑定onload/onerror再赋值src
真正需要预加载的，永远是用户睁眼第一秒就该看到的东西；底部图片的使命是“安静待命”，不是“抢跑”。别用预加载掩盖交付质量的问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
