Performance API 通过 INP 评估真实交互延迟，捕获 startTime、processingStart、processingEnd 拆解排队与执行瓶颈，结合 longtask 验证，用滑动窗口动态基线判定波动，并过滤无效交互、上报带上下文的环境数据。

直接用 Performance API 评估交互延迟，关键不是看单次点击花了多久，而是捕获浏览器真实调度和处理过程——它不依赖手动打点，而是靠原生事件条目反映主线程是否被阻塞。

宝塔Linux面板11.3.0

宝塔面板11.3.0是一款针对Linux服务器设计的可视化管理工具，通过重构核心模块实现资源占用显著降低，尤其适合低配置服务器环境。它将复杂的命令行操作转化为直观的图形界面，帮助开发者快速完成网站部署、环境配置及日常运维工作，无需专业技术背景即可高效管理服务器。

下载

捕获真实交互延迟（INP 而非 FID）
Chrome 113+ 已用 INP（Interaction to Next Paint）替代 FID，覆盖整个页面生命周期中最差的一次交互体验。监听 event 类型条目即可获取：

• 每个 PerformanceEventTiming 对象自带 startTime、processingStart、processingEnd
• 真实处理耗时 = processingEnd - processingStart，排除排队等待时间
• 只保留 duration > 200ms 的条目作为有效卡顿信号，避免毛刺干扰

区分“排队”与“执行”瓶颈
单纯看总延迟不够，要拆解原因：

• 若 processingStart - startTime > 100ms，说明事件被排队，主线程长期繁忙
• 若 processingEnd - processingStart > 150ms，说明 JS 执行或渲染逻辑本身过重
• 结合 longtask 条目交叉验证：同一时段出现 ≥50ms 长任务，基本可确认是代码执行拖慢

建立动态基线而非固定阈值
固定 100ms 或 300ms 容易误判，推荐滑动窗口策略：

• 维护最近 10 次有效交互的延迟数组
• 实时计算 p90 值和标准差 σ
• 当某次延迟 > p90 × 1.5 或 > p90 + 2×σ，且连续两次触发，才判定为性能波动

过滤无效交互，聚焦真实用户场景
避免把误点、滚动中点击、页面不可见时的操作计入：

• 通过 document.visibilityState === 'visible' 排除非活跃页
• 忽略 event.cancelable === false 或 event.target === document.body 的空白点击
• 跳过 initiatorType === 'scroll' 或 initiatorType === 'resize' 的非用户主动交互

上报需带上下文，不能只传毫秒数
一次延迟数据的价值取决于它附带的环境信息：

• 设备内存等级（navigator.deviceMemory）
• 网络类型（navigator.connection.effectiveType）
• 页面加载状态（document.readyState）
• 是否刚完成 LCP（对比 largest-contentful-paint 时间戳）
• 当前帧率（window.performance.getEntriesByType('paint') 中最近 paint 时间差）

不复杂但容易忽略。