<img> loading='lazy'与Intersection Observer懒加载优劣对比

直接说结论：自定义IO方案不是无意义的重复造轮子，值不值得做完全看你当前的业务需求，不存在绝对的冗余一说。

先搞懂原生loading="lazy"的能力边界 #

你现在已经给所有图片加了原生懒加载，其实已经拿到了这部分优化的基础收益：没有额外JS运行时开销，由浏览器直接管控加载逻辑，还会根据用户滚动速度、网络状态做预判预加载，减少用户等图的时间。但原生方案从设计上就留了几个没法绕开的限制：

• 触发加载的阈值完全不可控：不同浏览器内置的预加载距离是固定的，通常是距离视口1-2屏左右，你没法根据自己的页面布局调整。比如做高密度瀑布流的话可能想提前3屏加载避免滑动卡顿，或者弱网环境下想把触发距离缩到100px以内省流量，原生都做不到。
• 占位和加载体验没法定制：图片加载完成前原生只会显示空白或者裂图占位，你要加骨架屏、低质量模糊占位图、加载淡入动画这些体验优化，还是得自己额外写逻辑监听元素状态。
• 异常处理成本高：如果图片请求失败，原生方案没法很方便地自动重试、切换备用CDN地址，只能靠全局error事件兜底，很容易漏处理。
• 首屏识别容易出错：浏览器判断哪些图片属于首屏需要立即加载，是基于页面初始布局计算的。如果你的首屏图片是动态异步挂载的、或者用了偏移/绝对定位这类特殊布局，浏览器很容易误判，把本该首屏加载的核心图片延迟加载，反而拖慢LCP指标。
• 兼容范围固定：如果你的产品需要覆盖Safari 15以下版本、或者国内一些存量较大的旧版套壳webview，原生懒加载会直接失效，所有图片会在页面加载时同时请求。

自定义Intersection Observer方案的独有价值 #

如果你刚好踩中了上面说的几个原生方案的痛点，那做IO自定义方案的投入完全划算，能拿到原生给不了的优化空间：

• 加载策略完全自主可控：你可以自由设置触发加载的视口阈值，甚至可以结合用户网络状态动态调整：WiFi/5G环境下提前3屏加载保证滑动流畅，弱网下缩短预加载距离减少不必要的流量消耗。
• 全链路体验可定制：从未加载状态的占位样式、加载中的过渡动画，到加载失败的重试、兜底图切换，整个流程完全可控，对于图片占比极高的内容类站点，这些细节对用户体验的提升非常明显。
• 能进一步降低运行时性能消耗：原生懒加载只是不加载图片资源，img标签对应的DOM节点还是会在页面渲染时全部挂载。如果你的页面是无限滚动的长内容，几百上千张图的DOM节点堆在一起，内存占用会很高。用IO方案可以做到元素进入视口再挂载实际的img节点，甚至滚出视口一定距离后回收非关键节点，大幅降低长列表场景下的内存压力。
• 方便做数据统计：你可以很自然地在图片触发加载、加载完成、加载失败、曝光等节点埋点，统计图片加载成功率、曝光率、平均加载耗时这些业务指标，原生方案很难准确拿到这些数据。

什么情况下没必要额外开发？ #

如果你符合下面所有情况，那直接用原生loading="lazy"就够了，额外写IO方案纯属浪费时间：

• 页面布局规整，首屏内容都是同步渲染的，不存在动态注入、特殊定位的图片，浏览器不会出现首屏资源误判
• 不需要做自定义占位、过渡动画、失败重试这类体验优化，图片直接加载显示即可
• 不需要兼容低版本浏览器/旧webview，目标用户全部使用支持原生懒加载的主流版本
• 页面不是无限滚动长列表，单页图片总量不大，不会出现DOM节点过多导致的性能问题

最后提个实操建议：不用从零手搓整套IO逻辑，React生态里已经有封装成熟的懒加载组件，只需要根据业务需求调整配置就行，开发成本很低。另外两者并不冲突，你可以用IO方案控制渲染时机、占位和异常逻辑，同时给最终渲染的img标签加上loading="lazy"，作为极端场景下的兜底，两层优化不会有冲突。

内容的提问来源于stack exchange，提问作者AndyGUY