应聚焦fps和inp两大用户可感知维度：fps需稳定50～60fps且长任务≤20ms、避开100ms响应窗口；inp须关注p75值（如≤150ms）及与用户动作对齐的因果链；performanceobserver需验证长任务数量↓、总占比↓、尖峰消除；最终以低端机真实操作实测最差路径。
评估长任务拆分是否真正带来性能收益，不能只看“任务变短了”，而要聚焦用户可感知的两个关键维度：视觉流畅度（FPS）和交互响应力（INP）。指标合格但人还卡，说明优化没落在刀刃上。
用 FPS meter 验证视觉连续性
开启 Chrome 的 Rendering 面板 FPS meter，实测典型操作下的帧率稳定性：
- 在滚动长列表或快速连点按钮时，观察是否稳定在 50～60fps；若仍频繁掉到 20fps 以下，说明仍有未拆分的同步逻辑、或存在强制同步布局（如循环中读取 offsetHeight）
- 对比优化前后同一路径的 Performance 面板火焰图：原本连续的 180ms 脚本块，应被切碎为多个 ≤20ms 的小段，且明显避开输入后 100ms 的黄金响应窗口
- 搭配简易 FPS 监测器（基于 requestAnimationFrame），在低端安卓机上录屏+秒表实测，确认“眼见为实”的流畅感提升
用 INP 抓住最差交互体验
INP 衡量的是单次交互中最长延迟（不是平均值），直击用户真实卡顿痛点：
- 在生产环境引入 web-vitals 库：import { getINP } from 'web-vitals'; getINP(sendToAnalytics);，重点关注 P75 值——例如从 280ms 降至 150ms 以内才算有效改善
- 避免只看全局 INP 平均值：一次表单校验卡住 800ms，会拉高整体值，但更关键的是定位它是否发生在用户点击“提交”之后
- 必须将 INP 触发时刻与用户动作对齐：在点击按钮时打标 console.time('submit-form')，再通过 PerformanceObserver 捕获 Long Task，回溯 ±200ms 内是否有匹配标记，建立“点→卡→滞”因果链
结合长任务原始数据交叉验证
PerformanceObserver 是最直接的底层证据源，需持续观测三类变化：
- Long Tasks 数量：拆分前每秒出现 4 个 >100ms 的任务，优化后应降至每秒 ≤1 个，且全部 ≤30ms
- 总耗时占比：在 Performance 面板中查看 Scripting 区域的红色长条总面积是否显著收窄，目标是降低主线程被 JS 占用的整体比例
- 分布形态：关注是否消除了“尖峰型”长任务（如某次校验突然飙升至 700ms），这类极端值对 INP 影响最大，仅靠平均值无法暴露
回归手动实测“最差路径”
自动化指标只是参考，最终要回到真实设备与真实操作：
- 用低端安卓机打开复杂表单，连续快速切换 5 个下拉框，测量从最后一次点击到校验提示出现的时间差
- 在弱网模拟下触发搜索并快速滚动结果页，观察是否仍出现白屏或按钮失响应
- 开启页面 visibilityState 监听，验证切到后台时长任务是否自动暂停或降级，避免后台耗电与卡顿
