把后台筛选的 INP 从四百二十毫秒压到一百八十

今年 10 月我们给一个安全审计 SaaS 的后台做交互优化，P75 的 INP 从 420 毫秒降到 180 毫秒。这个产品每天有客户在里面点几百次筛选，卡不卡直接关系到他们愿不愿意续费。

问题集中在一个页面：客户列表。1200 条记录，七个筛选条件，每次改动都重新拉数据、重新渲染整张表。用户点一下复选框，页面要停半秒。销售在演示时也遇到过，鼠标点下去没反应，场面很难看。

先复现，再动手

我们没有直接改代码，先按真实操作录了 20 次 Performance。结论很清楚：一次筛选交互里，主线程上有三个 300 毫秒以上的长任务，分别是数据深拷贝、全量重渲染、以及一个第三方埋点的同步上报。

顺带说个细节，客户自己一直说"不卡"，因为开发机是 M 系列芯片，而他们的客户用的是四年前的办公本。测 INP 必须用降速环境，或者直接看真实用户数据。

改动一：列表虚拟化

1200 行只渲染视口内的 40 行，滚动时动态替换。这一项把重渲染时间从 380 毫秒压到 60 毫秒。虚拟化的代价是导出、全选、跨行拖拽这些功能要单独适配，我们花了三天补。

改动二：把计算挪出事件处理器

原来的筛选逻辑在 onchange 里同步过滤数组、做深拷贝、算统计。改成先更新 UI 状态，计算放到 requestIdleCallback 里分批做，中间留一帧渲染。用户先看到勾选生效，结果稍后到。这个体验上的处理比纯性能数字更重要。

改动三：埋点改成异步批量

那个第三方埋点在每次筛选时同步上报，一次 80 毫秒。改成 1 秒合并上报，用户交互路径上不再有它。

结果和一条教训

三处改完，P75 从 420 到 180 毫秒，P95 从 1100 到 340 毫秒。客户那边的反馈从"卡"变成"还行"。

落地时的协作问题

这类改动最大的阻力不是技术，是排期。虚拟化要改列表组件，筛选要改状态管理，埋点要跟第三方沟通，三件事分属三个人的活。我们的做法是先做一行能立刻验证的改动——把埋点延后，半天就上线，第二天客户能自己看到数据变化。有了这个信任，后面两周的排期才好谈。

另一个坑是回归测试。虚拟化之后导出 CSV、全选、行内编辑全都要重新走一遍。我们让客户的产品经理列了 14 个操作场景，逐个手点，漏一个就是线上事故。

一条教训

不要用开发机测 INP。我们坚持用 CPU 4 倍降速加 4G 网络复现，第一次测出来的数据比客户描述的还差。真实环境总是更差的那个，不会更好。另外 INP 改完不是立刻见效的，我们等了两周真实数据才稳定下来，因为长尾交互要攒够样本。