前端页面滚动卡顿：从性能定位到优化落地

页面能快速打开，不代表滚动时一定流畅。滚动卡顿常见于长列表、图片流、复杂仪表盘，以及包含吸顶、视差和入场动画的页面。真正有效的优化，需要先判断耗时发生在哪里，再减少对应的工作。

推荐的处理顺序是：录制滚动过程 → 判断瓶颈 → 修改一个相关因素 → 在同样条件下复测。给所有事件加节流、给所有元素加 GPU 加速，都不能替代定位。

1. 先识别“卡顿”的具体表现

2. 用 Performance 录制真实滚动

使用接近线上环境的生产构建，打开 DevTools 的 Performance 面板，等页面稳定后录制 5～10 秒滚动，经过容易卡顿的位置，再选中问题附近的时间段。

先看 Frames 判断是否掉帧，再看 Main 的任务分布，使用 Bottom-up 或 Call tree 找到主要耗时函数。不要只看整个录制的平均值，短时间的集中开销往往更能解释体感问题。

3. 减少滚动回调里的工作

滚动时遍历所有节点、反复读取元素位置、更新整个页面的状态，或者执行排序和序列化，都可能挤占渲染时间。先问清楚每段逻辑真正需要什么频率。

例如，记录阅读位置通常不需要逐帧执行，可以使用一个保存最新位置的时间节流：

function observeReadingProgress(report) {
  let timer = null;
  let latestY = window.scrollY;

  function onScroll() {
    latestY = window.scrollY;
    if (timer !== null) return;

    timer = window.setTimeout(() => {
      timer = null;
      report(latestY);
    }, 100);
  }

  window.addEventListener("scroll", onScroll);

  return () => {
    window.removeEventListener("scroll", onScroll);
    if (timer !== null) window.clearTimeout(timer);
  };
}

这里的 100ms 是业务参数，适合允许低频更新的统计或记录，不适合需要紧跟手势的动画。report 自身仍应保持轻量；如果需要网络上报，还要单独控制请求频率和并发。

4. 正确使用 passive，避免阻塞滚动启动

监听 touchstart、touchmove 或 wheel 时，如果不需要取消默认行为，可以明确声明 passive: true，让浏览器知道无需等待回调来判断是否允许滚动。

element.addEventListener("touchmove", onTouchMove, {
  passive: true,
});

element.addEventListener("wheel", onWheel, {
  passive: true,
});

5. 避免反复触发同步布局

典型问题是先修改样式，再立刻读取几何信息。浏览器为了给出最新结果，可能必须提前计算布局；在循环中反复交替读写，就会形成布局抖动。

// 容易反复触发布局：写入和测量交替发生
for (const item of items) {
  item.style.width = "200px";
  const height = item.offsetHeight;
  processHeight(height);
}

如果要获取修改宽度后的高度，可以集中写入，再集中读取：

for (const item of items) {
  item.style.width = "200px";
}

const heights = items.map((item) => item.offsetHeight);
heights.forEach(processHeight);

前提是 processHeight 不继续交替修改样式和测量页面。offsetHeight、getBoundingClientRect() 并非每次调用都强制布局，关键在于之前的操作是否让布局失效，以及当前是否必须同步取得结果。

6. 长列表优先评估虚拟化

几千行表格、聊天记录或信息流会带来大量 DOM 和组件实例。虚拟列表保留完整数据，只挂载可见区域及其附近的内容，并通过占位尺寸维持整体滚动范围。

• 使用稳定的数据 ID，避免无谓重建。
• 动态行高需要测量和缓存，图片加载后可能需要修正。
• 缓冲区太小，快速滚动可能出现空白。
• 保留焦点、键盘导航、无障碍和滚动位置恢复能力。
• 无限加载不等于虚拟列表；不断追加 DOM 仍会越滚越重。

对于长文章或相对独立的内容区块，也可以试验屏外渲染跳过：

.article-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 600px;
}

7. 用 IntersectionObserver 处理可见性需求

图片懒加载、内容入场和接近底部加载，一般无需在每次滚动时遍历所有元素。

const observer = new IntersectionObserver(
  (entries) => {
    for (const entry of entries) {
      if (!entry.isIntersecting) continue;
      entry.target.classList.add("is-visible");
      observer.unobserve(entry.target);
    }
  },
  {
    root: null,
    rootMargin: "200px 0px",
    threshold: 0,
  }
);

document.querySelectorAll(".reveal").forEach((element) => {
  observer.observe(element);
});

// 页面或组件销毁时调用 observer.disconnect()

8. 简化昂贵效果，谨慎使用图层

如果主要耗时在 Paint、Raster 或合成相关工作，继续给 JavaScript 加节流未必有明显收益。可以逐项关闭大面积背景模糊、复杂阴影、透明叠加、固定背景和动态图形，对照性能记录判断影响。

阅读进度条等效果也可考虑 CSS 滚动驱动动画，减少 JavaScript 联动代码：

.progress {
  position: fixed;
  inset: 0 0 auto;
  height: 3px;
  background: #2563eb;
  transform: scaleX(0);
  transform-origin: left;
}

@supports (animation-timeline: scroll()) {
  .progress {
    animation: reading-progress linear both;
    animation-timeline: scroll(root block);
  }
}

@keyframes reading-progress {
  to { transform: scaleX(1); }
}

9. 控制图片像素尺寸，预留布局空间

压缩文件小，不代表解码后的图片占用小。4000 × 3000 的图片，按每像素 4 字节粗算，一份像素数据约为 48MB；实际总开销还取决于浏览器实现和资源副本。

• 根据展示尺寸和设备像素比提供合适的图片，使用 srcset、sizes。
• 设置正确的 width、height 或 aspect-ratio，避免加载后把页面撑开。
• 屏外图片按需使用 loading="lazy"，首屏关键图片需要及时加载。
• 按场景使用 decoding="async"；它不会消除解码工作。
• 避免进入视口时集中初始化大量大图、GIF、视频和 Canvas。

<img
  src="/images/card-800.webp"
  width="800"
  height="500"
  loading="lazy"
  decoding="async"
  alt="内容描述"
/>

如果只是内容尚未加载，但已有页面能流畅滚动，应进一步区分网络等待和渲染卡顿，避免把所有问题都归因于下载速度。

10. 限制 React / Vue 的高频更新范围

为了控制一个返回顶部按钮，却把每个 scrollY 都放在页面顶层状态中，可能带动大量无关组件更新。优化时应让状态影响范围与实际功能范围一致。

• 只关心是否超过 200px 时，只在这个布尔值发生变化时更新状态。
• 将滚动状态放到实际使用它的小组件中，避免广播到全局。
• React 中不参与渲染的高频临时值可放入 useRef；ref 变化不会触发重渲染。
• 用 Profiler 确认更新昂贵的组件，再评估 memo 和稳定 props。
• Vue 中同样要避免高频修改被大量组件依赖的响应式数据。

11. 检查与滚动竞争主线程的其他任务

卡顿发生在滚动期间，不代表原因一定在 scroll 回调中。请求完成后的大批量 DOM 插入、数组排序、图表初始化、同步存储和第三方脚本，都可能在此时占用主线程。

处理大量纯计算可以评估 Web Worker；Worker 不能直接操作 DOM，也需要考虑消息传输成本。大量更新可分批执行，非必要初始化可推迟，并清理已经销毁页面的定时器、观察器、监听器和订阅。

需要特别避免两个误区：给函数加 async 不会自动把计算移出主线程；await Promise.resolve() 也不等于为渲染让出机会，连续微任务仍可能阻塞渲染。

12. 用同样场景验收优化效果

固定设备、浏览器、数据量和滚动路径，每次只修改一组相关因素，再对照录制结果。优先关注问题时间段，不要只看 Lighthouse 分数或整个过程的平均 FPS。

• 问题位置的掉帧是否减少，帧耗时分布是否改善。
• 滚动相关函数、Layout 和 Paint 的耗时是否下降。
• DOM 是否随无限滚动持续增长，返回页面后是否仍保留大量对象。
• 快速滚动是否出现空白、跳位、重复请求或滚动位置丢失。
• 吸顶、弹窗、触摸手势、键盘导航和无障碍是否正常。
• 优化在目标手机和目标浏览器上是否仍然有效。

CPU 降速可以暴露部分主线程问题，但无法完整模拟手机的 GPU、内存、触摸输入和温控。真实设备上的持续滚动测试仍然必要。

实际排查时，先检查高频事件与框架更新，再检查反复布局和长列表，最后根据性能记录处理图片、视觉效果和图层。每项修改都对应一个明确的耗时来源，并用同样场景确认收益，才能建立可重复的优化方法。