题干与适用场景
用户反馈点击筛选按钮后页面卡顿。请说明如何定位主线程 Long Task，如何判断它对 Interaction to Next Paint（INP）的影响，并给出修复与验证方案。
回答应区分输入延迟、事件处理耗时和下一次绘制延迟；不能只说“做防抖”或“上 Web Worker”。需要覆盖真实用户数据、实验室诊断、回归指标和降级边界。
面试官考察点
性能模型
强回答能把一次交互拆成输入等待、事件处理、渲染与绘制，并解释主线程被长任务占用时浏览器无法及时响应。
证据定位
候选人应结合 PerformanceObserver、浏览器 Performance 面板和交互上下文定位脚本、组件和数据规模，而不是凭感觉猜测。
修复取舍
要说明拆分任务、减少同步工作、虚拟化、延迟非关键更新和 Worker 的适用条件，同时考虑序列化成本与状态一致性。
真实验证
回答应同时看 p75 INP、长任务数量、交互分位数和业务转化，区分实验室样本与真实设备、网络和低端 CPU。
回答前需要澄清的问题
- 卡顿发生在所有交互还是特定筛选条件？
- 目标设备、浏览器和数据量是什么？
- 问题是首次加载、交互处理，还是绘制后的布局？
- 是否有真实用户 INP、事件时长和长任务数据？
- 筛选结果需要同步更新，还是可以先响应再渐进计算？
- 业务是否允许改变排序、分页或结果精度？
30 秒回答框架
“我先用真实用户 INP 和交互事件定位受影响页面，再在同一设备和数据量下录制 Performance trace。PerformanceObserver 监测 50ms 以上的 longtask，面板用于定位脚本调用栈和绘制阶段。若事件处理同步计算过重，我会先拆分工作、减少重复渲染和虚拟化列表；可并行的纯计算再评估 Worker，但会计入序列化和调度成本。修复后用 p75 INP、交互长任务和转化率做前后对照。”
分步骤深入解答
第一步：建立基线
按页面、交互类型、设备和版本记录 p75 INP、事件处理时长、下一次绘制延迟、长任务数和错误率。不要用单次本地快机器结果代表全体用户。
第二步：复现与定位
使用浏览器 Performance 面板录制真实筛选操作，查看主线程火焰图、Long Tasks、布局和绘制。PerformanceObserver 可在运行时收集 longtask 记录，再把页面、交互和版本信息关联到样本。
第三步：区分瓶颈
若输入等待长，检查前一个同步任务；若事件处理长，检查解析、过滤和状态更新；若绘制长，检查布局、样式和大 DOM。INP 关注一次交互从输入到下一次绘制的完整响应，不等同于单个函数耗时。
第四步：降低同步工作
先减少计算量和重复渲染，使用分页、虚拟化、增量过滤和缓存。把非关键日志、预取和分析移出关键交互路径；必要时用 requestIdleCallback 或分片调度，但要处理空闲时间不足。
第五步：评估 Worker
纯 CPU 计算且数据可复制时可用 Worker；大对象复制、频繁消息和 DOM 访问会抵消收益。保持 UI 状态与结果版本一致，取消过时任务，避免旧结果覆盖新筛选。
第六步：验证与防回归
在代表性低端设备和数据集重复录制，并做灰度发布。比较 p75/p95 INP、longtask 数、交互成功率、取消率和转化；建立预算，超阈值时阻断回归或触发告警。
高质量示范回答
“我先从真实用户数据确认问题集中在哪个交互、设备和版本，再用同样的数据量录制筛选操作。火焰图显示事件处理同时做了大数组过滤、状态更新和列表布局，因此我会先缓存过滤结果、虚拟化列表，并把非关键更新延后。
我用 PerformanceObserver 记录 50ms 以上 longtask，并把样本关联到页面和交互；如果过滤仍是纯 CPU 瓶颈，再把它移到 Worker，同时限制消息大小和丢弃过时结果。修复在低端设备灰度，比较 p75 INP、长任务数、取消率和筛选完成率，确认真实用户改善后再扩大范围。”
常见错误
- 只看平均响应时间 → 尾部用户被掩盖 → 看 p75/p95 INP 和设备分层。
- 把 Long Task 等同于 INP → 忽略输入和绘制阶段 → 追踪一次交互的完整时间线。
- 看到卡顿就加防抖 → 可能延迟必要反馈 → 先定位计算、渲染或网络瓶颈。
- 所有计算都丢给 Worker → 复制和消息成本增加 → 只迁移纯 CPU 且收益明确的工作。
- 只在开发机验证 → 低端设备仍卡顿 → 用代表性设备、数据和灰度样本复测。
- 分片调度不设取消 → 过时结果覆盖新状态 → 为任务加版本、取消和提交检查。
- 只做实验室 Lighthouse → 无法反映真实交互 → 接入真实用户 INP 与长任务采样。
- 修复后没有性能预算 → 回归无法被发现 → 为关键交互设阈值和持续监控。
追问及应对
追问一：Long Task 只有 60ms，为什么 INP 仍很差？
检查交互前的输入等待、事件处理后的布局与绘制，以及多个相邻任务；INP 是完整响应路径，单个 60ms 不是全部解释。
追问二：Worker 让结果更慢怎么办？
测量序列化、传输和调度成本；对小数据保留主线程快路径，对大数据批量发送或使用可转移对象，并取消过时请求。
追问三：如何观测 longtask 的来源？
在 PerformanceObserver 记录 startTime、duration、页面和版本，并结合 Performance trace 的调用栈；不要把用户数据中的敏感输入写入日志。
追问四：筛选结果必须实时怎么办？
先同步确认输入和显示加载状态，再增量计算结果；保持结果版本与筛选条件一致，必要时显示暂态结果和完成状态。
追问五：如何证明修复没有伤害转化？
灰度比较 p75 INP、交互完成率、取消率、错误率和核心转化，按设备和网络分层，并设定停止条件。
来源一：MDN Performance data
MDN 说明 longtask 记录代表持续 50ms 或更久的任务，可用作主线程阻塞的运行时证据。
来源二：PerformanceObserver
MDN 的 PerformanceObserver 文档说明如何观察性能条目，为采集 longtask 和关联页面版本提供 API 依据。
来源三：web.dev Long Tasks 与 INP
web.dev 解释长任务会阻塞主线程、延迟用户反馈，并建议拆分任务、减少同步工作和评估 Worker；INP 反映交互到下一次绘制的响应。