Chrome团队把1个API藏了8年，前端发现后加载速度翻倍

2016年，Chrome 51发布时埋了个彩蛋。当时没人注意，直到3年后，全球前1000万网站里有47%的页面加载时间超过3秒——而罪魁祸首，是开发者们用了十几年的滚动监听。

那个彩蛋叫Intersection Observer（交叉观察器）。简单说，它让浏览器替你盯着元素有没有进可视区域，不用你写死循环去问了。

传统做法有多蠢？打个比方：你想知道外卖到哪了，老办法是每分钟打一次电话问骑手。新办法是骑手到了自动打给你。前者把你的时间撕成碎片，后者只在关键时刻响一声。

浏览器里的"打电话"，就是监听scroll事件然后调getBoundingClientRect()。每次调用都强制页面重排（reflow），像推倒积木重新搭。移动端上，这能让帧率跌到20fps以下，肉眼可见的卡顿。

Intersection Observer的底层逻辑：从轮询到推送

这个API的核心设计是异步+阈值触发。它不会告诉你"现在元素在屏幕的哪个坐标"，而是告诉你"元素刚刚进入/离开了可视区域"。

技术实现上，浏览器内部维护了一个观察列表。当渲染引擎完成一帧绘制后，它会检查这些目标元素与根元素（默认是视口）的几何关系。只有跨越了设定的阈值，才会把结果批量推送给你的回调函数。

这意味着什么？你的JavaScript主线程被解放了。不需要每16毫秒（60fps的帧间隔）跑一次计算，只在状态变化时收一次通知。

代码结构分三步：定义回调、配置选项、绑定目标。回调接收两个参数：IntersectionObserverEntry对象的数组，以及观察者实例本身。每个entry包含isIntersecting布尔值、intersectionRatio（可见比例）、boundingClientRect等只读属性。

配置选项里，root指定参照容器（默认viewport），rootMargin可以向外扩展观察范围（比如"100px"表示元素距离视口还有100像素时就触发），threshold是0到1之间的数值或数组，控制触发精度。

一个细节：threshold: 0.5表示元素50%可见时触发，而[0, 0.25, 0.5, 0.75, 1]会让回调在多个阶段都执行，适合做渐进式加载动画。

懒加载实战：从概念到可落地的代码

图片懒加载是Intersection Observer最经典的场景。原理很简单：初始时img标签的src放一个占位图，真实的图片地址存在data-src里。当图片进入视口，再把data-src的值换过去。

但这里有坑。如果图片已经在浏览器缓存里，直接换src会瞬间加载完成，你可能看不到加载过程。更好的做法是配合CSS过渡，或者先预加载再淡入。

代码层面，记得在回调里调用observer.unobserve(entry.target)。否则元素每次进出视口都会触发，造成重复加载。对于无限滚动场景，这反而是需要的——底部加载指示器要一直被观察，直到没有更多数据。

无限滚动的实现逻辑稍复杂。你需要一个"哨兵元素"（sentinel）放在列表末尾，当哨兵进入视口，就发起下一页请求。请求过程中可以暂时取消观察，避免重复触发；新数据渲染完成后，重新观察哨兵（如果还有下一页）。

性能数据很直观。Google的Case Study显示，某新闻网站用Intersection Observer替换scroll监听后，主线程空闲时间提升了40%，低端安卓设备的卡顿反馈减少了67%。

兼容性处理：渐进增强的策略

2016年的API，现在兼容性如何？Can I Use数据显示，全球95%以上的用户环境支持原生Intersection Observer。剩下的5%主要是IE11和部分旧版安卓WebView。

对于这5%，有两种处理思路。一是直接放弃优化，让老浏览器走传统方案——反正他们的设备性能也差，不差这点开销。二是用polyfill，比如WICG官方提供的intersection-observer库，体积约6KB，gzip后2KB出头。

polyfill的原理是用requestIdleCallback或setTimeout模拟异步检查，用getBoundingClientRect计算位置关系。性能不如原生，但比scroll监听好很多。

现代框架的封装也值得提。React有react-intersection-observer，Vue有vue-observe-visibility，都帮你处理了ref绑定、生命周期清理这些脏活。但理解底层API仍然重要——封装库出bug时，你得知道往哪挖。

一个容易忽视的点：rootMargin对性能的影响。设置太大的margin（比如"500px"）会让浏览器提前计算大量屏幕外的元素，抵消了懒加载的收益。建议根据网络环境和设备性能动态调整，慢网环境用较小的margin，减少无效请求。

进阶场景：不只是懒加载

Intersection Observer的潜力被低估了。除了资源加载，它还能做曝光统计、动画触发、阅读进度计算，甚至替代部分滚动监听实现的视差效果。

曝光统计是广告行业的刚需。传统方案用元素坐标手动计算可见比例，误差大、性能差。Intersection Observer的intersectionRatio直接给出0到1的精确值，结合时间戳可以计算"有效曝光时长"——广告行业标准通常是50%以上可见且持续1秒。

动画触发更有意思。CSS动画的触发时机一直是个痛点：用scroll事件太卡，用Waypoint这类库又太重。Intersection Observer可以精确控制元素进入视口某个范围时添加动画类，配合CSS的animation-delay实现错开效果。

阅读进度计算以前需要监听scroll并遍历所有段落。现在给每个段落绑一个Observer，threshold设成1（完全可见），记录进入和离开的时间戳，就能算出用户实际读了多久、哪些段落被跳过了。

视差效果的替代方案稍微反直觉。传统视差是多层背景以不同速度滚动，需要实时计算位置。用Intersection Observer可以改为"进入视口后触发动画"，牺牲一点实时性换取流畅度。对于非游戏类网站，用户其实察觉不到差异。

Chrome团队还在迭代这个API。v2版本增加了对可遮挡性的检测——能判断元素是否被其他内容覆盖、是否在iframe里、是否被CSS变换扭曲。这对广告防作弊和付费内容保护很有价值。

回到2016年那个彩蛋。8年过去了，还有大量网站在用scroll监听做懒加载。不是技术门槛高，是惯性太大。就像很多人知道外卖App能看骑手位置，还是忍不住打电话问。