从蜗牛快递到火箭物流——IntersectionObserver 拯救你的网页加载速度

我想说一句
273 阅读6分钟

今天在代码世界里，我经历了一场惊心动魄的"图片大逃杀"！故事的主角是六个磨人的小妖精——它们占据着400像素高的豪华单间，却空着手不肯工作（src属性全为空）。这感觉就像请了六个装修工人，结果他们全在阳台上晒太阳不搬砖！😤

第一章：图片世界的交通大堵塞

想象一下这样的场景：你打开一个电商网站，首页有50张高清大图同时加载。这就像早高峰的地铁站，50辆卡车同时挤进单行道：

<img src="巨无霸图片地址1.jpg">
<img src="巨无霸图片地址2.jpg">
...
<img src="巨无霸图片地址50.jpg">

结果会怎样？浏览器这个可怜的交通警察会崩溃！会造成："网页打不开，用户直接跑路"。更糟的是，用户可能只看前3张图，剩下47张还在拼命加载——典型的"吃力不讨好"。

解决方案？给图片们装上智能导航系统——懒加载！

第二章：偷梁换柱的艺术

懒加载的核心思想堪称"图片界的谍战戏"：

  1. 把真实身份（原始URL）藏在特工腰带里（data-original属性）
  2. 表面伪装成路人甲（src留空或放占位图）
  3. 只有进入监控区（可视区域）才亮明身份
<!-- 007式图片特工 -->
<img src="" 
     lazyload="true"
     data-original="真实图片地址.jpg">

当用户滚动页面时，JavaScript侦探开始扫描："报告长官！3号特工已进入可视区！"——于是立即更换src装备。

第三章：scroll事件的噩梦

早期的懒加载实现就像人工监控：

window.onscroll = function() {
  // 每次滚动都要检查所有图片位置
  imgs.forEach(img => {
    const rect = img.getBoundingClientRect();
    if(rect.top < window.innerHeight) {
      img.src = img.dataset.original;
    }
  });
}

这带来两个致命问题：

  1. scroll事件疯狂触发：轻轻一滚就触发几十次，控制台数字飙升如火箭

    var a = 1
window.onscroll = function() {
  a++
  console.log(a); // 滚两下就输出：2,3,4...99,100...
}

这滚动一下，数字增加的比血压还高，很难不让人血压飙升

B1E595BDE5B620084827_converted.gif

  1. getBoundingClientRect引发性能雪崩：这个API需要重新计算布局，相当于每次滚动都让整个页面重新排座位表。在readme.md中被吐槽："带来了新的性能问题"。

关于为什么会引起重新布局运算，和浏览器怎么计算布局，大家可以看看这篇大佬的文章，真的写得超级详细，真的膜拜啊「一道面试题」输入URL到渲染全面梳理中-页面渲染篇

第四章：救世主IntersectionObserver驾到！

当我在代码战场节节败退时，天降神兵——IntersectionObserver！它就像给浏览器装了智能监控探头：

const observer = new IntersectionObserver(changes => {
  changes.forEach(change => {
    if(change.intersectionRatio > 0) { // 目标进入视野
      const img = new Image();
      img.src = change.target.dataset.original;
      img.onload = () => {
        change.target.src = change.target.dataset.original;
      }
    }
  });
});

// 给所有懒加载图片装上监控器
document.querySelectorAll('img[lazyload]').forEach(img => {
  observer.observe(img);
});

这个方案的精妙之处在于：

  1. 异步侦察兵：Observer在后台默默工作，不再阻塞主线程
  2. 精确制导：只有当图片真正进入视口才触发（intersectionRatio > 0）
  3. 零成本计算：浏览器自动计算交叉区域，不再需要getBoundingClientRect

"不再需要onscroll，不需要节流"——就像从手动安检升级到人脸识别闸机！ 浏览器会自动帮我们检测图片有没有进入视窗，很智能，不需要我们再傻傻地用scroll、document.documentElement.ClientHeight、getBoundingClientRect 来计算图片有没有在视窗内，并且不会傻傻地“血压飙升”

ntersectionObserver API 提供了一种高效且性能更优的方式来检测元素是否进入视口（viewport），从而实现图片或其他资源的懒加载，相比于传统的基于scroll事件监听的方法，它具有以下几个显著优点：

  1. 性能提升：传统的scroll事件处理方式可能会在页面滚动时频繁触发，导致大量的计算和重绘操作，影响页面性能。而IntersectionObserver则是异步通知目标元素与祖先节点或顶级文档视口的交叉状态变化，不会对滚动流畅性产生负面影响。
  2. 简化代码逻辑：使用IntersectionObserver可以大大简化懒加载的实现逻辑。开发者不需要手动监听scroll、resize等事件来判断元素是否可见，只需要定义一个观察器并指定要观察的目标元素即可。
  3. 更好的浏览器优化：IntersectionObserver被设计为低级API，允许浏览器对其进行深度优化。例如，它可以批量处理多个元素的可见性检查，减少不必要的布局重新计算，这使得它比手动实现的解决方案更加高效。
  4. 支持更多场景：除了基本的懒加载功能外，IntersectionObserver还可以用于实现无限滚动列表、广告曝光统计等多种需要监测元素可见性的场景。
  5. 跨平台兼容性：尽管一些旧版浏览器可能不支持IntersectionObserver，但可以通过polyfill库（如intersection-observer）来提供兼容性支持，使得现代和传统浏览器都能良好运行。

第六章：新世界的美好生活

采用IntersectionObserver后，网页加载就像升级了交通系统：

指标传统方式Observer方案
事件触发频率滚动时洪水般触发静默后台监测
性能影响导致布局抖动接近零成本
代码复杂度需手动节流防抖原生支持简单优雅
精准度需手动计算位置浏览器自动计算

更重要的是，首屏加载时间从"等一壶水烧开"变成"微波炉热牛奶"——用户还没滚动，第一屏图片已经就绪；当用户慢悠悠滚动时，新图片恰好在进入视野时加载完成。

终章：未来已来

从scroll事件到IntersectionObserver，就像从马车时代跃入自动驾驶纪元。今天的探索让我想起readme.md的经典总结："浏览器主人给我们提供了IntersectionObserver"——这位主人慷慨赠送的礼物，我们怎能不好好利用？

下次当你看到图片优雅地随滚动浮现，请记得背后是Observer在默默指挥："注意！3点钟方向图片进入视口，立即激活！" 🕵️♂️

本文技术总结：

  1. 懒加载=藏src于data-original+视口激活
  2. Scroll监听是性能杀手
  3. IntersectionObserver是现代解决方案
  4. 预加载+onload确保完美替换
  5. 记得任务完成后unobserve
avatar
文章
阅读
粉丝