Performance API 通过分类采集长任务、FID/INP、FCP/LCP/CLS及资源条目，聚焦识别拖慢页面的具体因子：主线程阻塞、用户感知卡顿、渲染延迟和资源瓶颈，并需交叉验证与阈值判定。
Performance API 能直接暴露浏览器内部关键性能信号，监测时需聚焦“谁拖慢了页面”——不是只看总耗时，而是识别具体影响因子：主线程阻塞、渲染延迟、资源加载瓶颈和用户感知卡顿。核心在于分类采集、交叉验证、设定阈值。
捕获主线程压力：长任务（Long Tasks）
长任务是造成交互卡顿的主因，指在主线程上连续执行超过 50ms 的 JavaScript 任务。Performance API 提供 longtask 类型条目，可实时发现阻塞源：
- 用
PerformanceObserver监听longtask，获取startTime、duration和attribution（调用栈来源，部分浏览器支持） - 重点关注持续时间 ≥100ms 的任务，它们大概率导致掉帧或输入延迟
- 结合
taskAttribution（如启用）定位具体脚本或第三方库，例如：analytics.js: handleEvent
量化用户感知卡顿：FID 与 INP
首次输入延迟（FID）反映初始响应性，而交互响应性能（INP）更能代表整个会话体验。二者都依赖 first-input 和 event 类型条目：
-
FID：监听first-input条目，计算processingStart − startTime；超过 100ms 即属不佳 -
INP：需持续监听event类型（如click、keydown），取会话中延迟最高的一次（duration或processingEnd − startTime），阈值为 200ms - 避免仅依赖单次 FID——它无法反映后续交互质量，INP 才是更稳健的指标
定位渲染瓶颈：FCP、LCP 与布局偏移（CLS）
这些指标共同构成视觉加载体验，需通过 paint、largest-contentful-paint 和 layout-shift 类型协同分析：
-
FCP（首次内容绘制）：监听paint类型，筛选name === 'first-contentful-paint'，反映内容开始可见的时间 -
LCP（最大内容绘制）：监听largest-contentful-paint，关注其startTime和是否被延迟（如图片未懒加载、字体未预加载） -
CLS（累积布局偏移）：监听layout-shift，累加所有非预期位移分数；特别注意hadRecentInput为false的偏移（即用户未操作时发生的跳动）
识别资源级拖累：慢请求与高开销资源
并非所有资源都平等——某些请求可能显著拉低整体性能。使用 resource 类型条目做精细化归因：
- 调用
performance.getEntriesByType('resource')获取全部资源，按duration或transferSize排序 - 重点关注
initiatorType为script、img或fetch的资源，尤其是耗时 >1s 或体积 >500KB 的项 - 检查
nextHopProtocol是否为http/1.1（可能缺少 HTTP/2 多路复用），或workerStart与responseStart间隔过大（后端响应慢）
