Performance API 通过分析资源加载、导航、交互和渲染等时间条目精准定位抖动：TTFB 突增、响应离散、FCP 跳变、FID 延迟及布局偏移等均指向瞬态异常，需结合上下文归因。
Performance API 本身不直接“标注抖动”，但它能精准暴露抖动在时间线上的具体表现——比如某次资源加载 TTFB 突增、多个资源响应时间离散、FCP 在同一批页面中剧烈跳变，或交互延迟（FID）与长任务集中爆发。关键在于把零散的性能条目串成可归因的行为链，而不是只看平均值。
抓取真实抖动时刻的完整链路
平均耗时正常，不代表用户没卡。抖动是瞬态异常，必须捕获单次异常请求的完整生命周期：
- 用
performance.getEntriesByType('resource')筛出慢资源：如duration > 1000且initiatorType === 'script'的 JS 请求 - 对每个慢资源，拆解耗时构成：
—responseStart - requestStart→ TTFB（卡在连接/首字节）
—duration - (responseStart - fetchStart)→ 下载耗时（卡在传输） - TTFB 占比超 70%？大概率是 CDN 节点响应慢或回源抖动；下载耗时突增 + 用户网络信号弱（可用
navigator.connection.effectiveType辅助判断）？倾向边缘到客户端链路不稳定
交叉验证导航与资源时间线
单个资源慢可能是偶然，但若多个资源在同一次页面加载中集体“错位”，就指向更底层问题：
- 调用
performance.getEntriesByType('navigation')[0]，检查domainLookupStart/domainLookupEnd是否拉长 → DNS 解析异常会拖慢所有后续请求 - 对比
connectStart/connectEnd和secureConnectionStart→ 若 TLS 握手或 TCP 连接阶段明显延长，说明入口节点或中间链路存在抖动 - 观察多个资源的
requestStart高度集中，但responseStart时间离散发散 → 表明 CDN 边缘节点处理能力不均，或缓存未命中率突增
监听用户交互与渲染稳定性
抖动不仅发生在加载期，也体现在运行时。需同步关注用户真实感知：
- 用
PerformanceObserver监听first-input和longtask：
— FID > 100ms 或连续多次交互延迟 > 150ms，说明主线程被阻塞
— 出现 ≥100ms 的长任务，大概率伴随布局重排、样式计算或 JS 执行卡顿 - 监听
layout-shift条目：
— 提取entry.sources[0]?.node定位抖动元素（如图片加载后撑开容器）
— 累加entry.value得 CLS，单次偏移 > 0.01 且hadRecentInput === false，即为非用户触发的“意外抖动”
关联上下文做归因分析
抖动常具地域性、时段性或设备特异性，脱离上下文无法定位根因：
- 采集时同步记录 CDN 调度标识：检查响应头
X-Cache或X-CDN-Node，写入自定义 entry 属性便于分组统计 - 将
startTime转为小时粒度，按 CDN 节点聚合 P95 TTFB → 出现尖峰的时间段即为抖动窗口 - 结合
navigator.userAgent、navigator.connection.effectiveType和页面路由，区分是低端机型渲染慢、2G 网络传输抖、还是特定路径下组件逻辑引发的循环重排
