图片懒加载怎么实现？3种方案讲透性能优化秘诀

52JinY 助手

前端里“图片懒加载”其实不是什么新鲜技巧，但它一直很实用，尤其是列表页、资讯页、商品流这种图片很多的场景。很多人第一次做页面时，习惯把所有 img 一口气塞进去，结果首屏还没看完，浏览器已经在后台疯狂请求几十张图了。页面看起来像是“功能完整”，但真实体验往往很差：首屏变慢、流量浪费、低端机掉帧，这些问题最后都得回头补。

懒加载的核心思路并不复杂，说白了就是“先别急着加载，等快看到的时候再加载”。以前常见做法是先不给 img 写真正的 src，而是把真实地址放到 data-src 里。页面滚动时，通过监听 scroll、resize 之类的事件，判断图片是否进入可视区域，如果进入了，再把 data-src 赋值给 src。这个方案能用，也确实陪很多项目走了很多年，但缺点也明显：事件触发频繁，自己算位置容易写得啰嗦，列表一长还容易有性能负担。

现在更推荐的方式基本都是 IntersectionObserver。它的好处是浏览器帮你观察元素是否进入视口，不需要你自己反复计算。实现上也很直接：先给图片一个占位图或者骨架屏，把真实地址放在自定义属性里；然后创建观察器，等图片快进入屏幕时再替换 src，加载完成后取消观察。这样代码更清晰，性能通常也更稳。尤其是在移动端长列表里，这种差异会很明显，不是“理论优化”，而是真能感受到顺滑不少。

不过懒加载不是把图片“晚一点加载”就结束了，细节做不好，体验照样打折。比如图片如果没有提前设置宽高，等真正加载出来时就会把页面撑开，造成布局跳动。再比如占位图太丑、加载过慢没过渡，用户看到的就是一片空白块，观感也不好。所以我一直觉得，懒加载应该和尺寸预留、模糊占位、loading 动画一起看，它本质上是体验优化，不只是请求数量优化。

还有一个常被忽略的问题：不是所有图片都适合懒加载。首屏 banner、文章头图、商品主图这种一进页面就要看到的内容，通常应该优先加载，甚至配合预加载处理。如果连首屏核心图片也懒加载，有时候反而会让页面显得“慢半拍”。所以比较合理的策略通常是：首屏关键图正常加载，首屏以下的大量内容再做懒加载，而不是全站一刀切。

如果项目不复杂，其实现在连很多自定义代码都不一定要写，浏览器原生的 loading="lazy" 就能解决一部分问题。它实现成本低，写法也简单，但它更像是“基础版”，具体触发时机和行为由浏览器决定，可控性不如自己用 IntersectionObserver。所以我的看法是，小项目、内容站、后台页面可以先用原生懒加载；需要精细控制、埋点统计、渐进展示效果的项目，还是自己实现更稳。

说到底，图片懒加载不难，难的是别把它当成一个孤立技巧。它真正有价值的地方，是让页面把资源花在用户当前真正需要看到的内容上。写前端久了会发现，很多优化都是这个思路：不是一味堆功能，而是把“加载时机”做对。图片懒加载就是其中很典型的一种。