网页卡顿怎么定位性能瓶颈：从长任务到重排的 3 步

先给结论：定位网页性能瓶颈有固定三步——先用性能面板把卡顿量化成一个数字并找出长任务，再判断这段时间是被脚本计算占用还是被布局重排占用，最后按结论选择拆分任务或减少重排。不要凭感觉猜。

网页卡顿怎么定位性能瓶颈？

新手最常见的做法是直接开始改：听人说加节流就加节流，听人说用虚拟列表就上虚拟列表，改完还是卡。原因是一直没定位，改的方向不一定对得上真正的瓶颈。卡顿的成因虽然多，但能落到大类上的就两个：主线程被一段长时间的计算占住，或者同一帧里反复触发布局计算。

本文用一段可以复制进任意页面的最小代码，把测量、定位、验证三步串起来。示例基于现代浏览器通用的性能接口，不依赖任何框架。

先看结论

先量化：没有数字就没有性能瓶颈可言，先用计时接口测出单次操作的耗时。
再分类：长任务要么来自脚本计算，要么来自布局重排，两者的修复手段完全不同。
后验证：改完必须重测同一个指标，数字下降才算修好，感觉流畅不算。

浏览器渲染相关的属性记不清时，翻 HTML DOM 教程里按对象分类的章节最快。

一、先把卡顿量化成数字

把问题定死：点击一个按钮之后页面明显卡一下。定位性能瓶颈的第一步不是改代码，而是测出这一次操作到底花了多久。

function measure(name, fn) {
  const t0 = performance.now();
  const result = fn();
  const t1 = performance.now();
  console.log(name + ' 耗时 ' + (t1 - t0).toFixed(1) + ' 毫秒');
  return result;
}

measure('批量插入', () => {
  const box = document.getElementById('list');
  for (let i = 0; i < 5000; i++) {
    const li = document.createElement('li');
    li.textContent = '第 ' + i + ' 项';
    box.appendChild(li);
  }
});

这段做的是给一段操作包上计时，并把耗时打印出来。预期结果（未在本机执行）：一次性插入数千个节点时，耗时会明显超过单帧预算，肉眼表现为点击后停顿。

有了这个数字之后，改动才有对照。判断标准是浏览器一帧的预算只有十几毫秒，超过这个数的单次操作就必然导致掉帧。

二、长任务从哪来

长任务指的是占用主线程超过一帧预算的连续工作，它是最典型的一类性能瓶颈。它最典型的表现是：点击之后按钮的按下态迟迟不变，页面完全不响应滚动。

function heavy() {
  let sum = 0;
  for (let i = 0; i < 3000000; i++) {
    sum += Math.sqrt(i);
  }
  return sum;
}

console.log(measure('纯计算', heavy));

这段做的是跑一段纯计算并计时。这类任务的特征是耗时长但不碰界面，界面表现为整体冻结。

拆分是最直接的修复手段：把一整段计算切成若干小段，让浏览器有机会在中间处理用户输入和绘制。

function chunked(total, done) {
  let i = 0;
  function step() {
    const end = Math.min(i + 20000, total);
    for (; i < end; i++) { /* 处理一项 */ }
    if (i < total) {
      requestAnimationFrame(step);
    } else {
      done();
    }
  }
  requestAnimationFrame(step);
}

这段做的是把循环切成每帧处理固定数量。适用边界要讲清：拆分只能缓解"计算太集中"，不能减少总工作量。总量特别大时，正确的方向是把计算挪到工作线程，或者干脆减少要处理的数据量。

三、重排与重绘的代价

第二类长任务不来自计算，而来自布局。读取布局属性会强制浏览器立刻完成一次布局计算，如果在循环里反复读写，就会触发成百上千次重排。

// 反面示例：读写交替
const items = document.querySelectorAll('.item');
items.forEach(el => {
  const h = el.offsetHeight;          // 读，触发布局
  el.style.height = (h + 10) + 'px';  // 写，让布局失效
});

这段做的是在循环里交替读取和写入布局相关的属性。每一次读取都迫使浏览器重新计算一次布局，节点一多耗时就成倍增长。

改法是读写分离：先把要读的值一次性读完，再统一写入。

const items = document.querySelectorAll('.item');
const heights = Array.from(items, el => el.offsetHeight);
items.forEach((el, i) => {
  el.style.height = (heights[i] + 10) + 'px';
});

这段做的是先批量读取再批量写入，把重排次数从 N 次降到 1 次。

定位性能瓶颈的三步流程

区分重排和重绘很重要：改几何属性会触发重排，改颜色这类不影响布局的属性只触发重绘，代价通常小得多。改之前先想清楚这次改动会不会让别的元素位置发生变化。

💡 小提示：想快速确认瓶颈是不是布局，可以在浏览器性能面板里看这段时间的构成。如果大部分时间标着布局或样式计算，就是重排问题；如果标着脚本执行，就该去拆计算。

四、修复手段与验证清单

4.1 脚本型卡顿：拆分或转移

长时间纯计算优先拆成小段，实在拆不动就放进工作线程。转移之后主线程只负责接收结果，界面就不会冻结。

4.2 布局型卡顿：读写分离与批量改

循环里出现布局属性读取，一律改成先读后写。需要连续改动多个元素时，先让容器脱离文档流再改，改完再放回，能把重排范围限制在子树内。

4.3 帧率不稳但单次耗时不高

单次操作不慢却依然掉帧，通常是触发太频繁。滚动、输入这类高频事件要做节流或合并，把一帧内的多次触发压成一次。

4.4 验证清单

检查：性能面板里这段时间标记为脚本执行还是布局计算
运行：对同一个操作连续测三次，取中位数作为基线
预期：脚本型改后主线程占用下降，布局型改后重排次数降到个位数
失败：数字没有明显变化，说明定位错了方向，回到第二步重新分类
修复：脚本型拆分或转工作线程，布局型读写分离、批量改动
验证：用改前的同一段计时代码重测，输出的数字必须低于基线

上面这些步骤做的是把"感觉卡"变成可对比的数字。预期结果（未在本机执行）是三次测量稳定且低于基线；如果数据波动很大，先排除网络与缓存干扰再测。

读写交替与读写分离两种写法的重排次数对比

总结

性能瓶颈不需要猜：先量化，再按脚本计算与布局重排二分，最后按类别选手段并复测。顺序错了就会做无用功。

三条要点带走：

没有数字的改动不算优化，先给卡顿操作加计时；
长任务来自脚本就拆或转移，来自重排就读写分离；
每次改完都要用同一段代码复测，数字下降才算完成。

下一步建议把计时函数放进项目的公共工具里，遇到卡顿随手就能测。渲染相关的属性细节可以对照 HTML 教程再确认一遍。

常见问题

Q：页面卡顿怎么快速知道是哪段代码的问题？

A：用性能面板录一段，看最长的那一条任务花在哪个阶段。标记为脚本执行就查计算，标记为布局或样式计算就查读写顺序。

Q：为什么我加了节流还是卡？

A：说明瓶颈不是触发频率，而是单次操作本身太重。节流只能减少次数，改不了单次耗时，这种情况要拆分或转移计算。

Q：重排和重绘有什么区别？

A：改几何属性会让浏览器重新计算元素位置，这是重排；只改颜色这类不影响布局的属性只触发重绘，代价小得多。

Q：把计算放进工作线程就一定能解决吗？

A：不一定。工作线程能解决主线程冻结，但数据传递本身有开销，且计算结果如果还要触发大量重排，卡顿依然存在。

Q：帧率多少算流畅？

A：以一帧预算十几毫秒推算，稳定在这个范围内才不会掉帧。单次操作超过这个数，肉眼就能感到停顿。

延伸学习

想把渲染性能这块做扎实，可以按这个顺序来：

想系统补一遍基础，HTML入门课程(含HTML5) 可以跟一遍；
读一篇相关笔记 CSS局限属性contain，看限制重排范围的思路；
想随手验证一段页面，用 HTML 在线运行跑一遍最快。