performance api 定位性能瓶颈需聚焦加载慢、主线程卡、渲染抖三类问题，通过拆解导航阶段、揪出慢资源、监听长任务、验证动画帧四步实现：用 navigation 条目分析 ttfb、dom 解析、资源拖尾；resource 条目排查第三方/字体/https 慢资源；performanceobserver 捕获＞50ms 长任务；requestanimationframe 测帧耗时并优化布局读取。
直接用 Performance API 定位并减少性能瓶颈，关键不是“全量采集”，而是聚焦三类真实影响用户体验的问题：加载慢、主线程卡、渲染抖。核心动作就四步——拆解导航阶段、揪出慢资源、监听长任务、验证动画帧。
拆解 navigation 阶段，看清加载卡在哪
别再依赖已废弃的 performance.timing。用 performance.getEntriesByType('navigation')[0] 获取首屏完整路径耗时：
- TTFB（responseStart − navigationStart）＞800ms：优先查后端响应或 CDN 缓存策略，不是前端能优化的
- DOM 解析+同步脚本（domContentLoadedEventEnd − responseEnd）＞300ms：检查是否内联了未拆分的大 JS，或存在阻塞解析的 script 标签
- 整体完成延迟（loadEventEnd − domContentLoadedEventEnd）明显偏高：说明图片、iframe 等异步资源拖尾严重，需结合 resource 条目交叉定位
扫 resource 条目，揪出拖慢首屏的“慢资源”
执行 performance.getEntriesByType('resource')，按 duration 倒序排列，重点关注：
- 域名属于 CDN 或第三方（如 analytics、ads、fonts）的条目
- 字体文件（.woff2/.ttf）耗时 ＞400ms → 加
font-display: swap或预加载 - connectStart 与 secureConnectionStart 差值 ＞150ms → TLS 握手慢，考虑启用 HTTP/2 或
rel="preconnect"
用 PerformanceObserver 捕获主线程阻塞
用户感觉“卡”，往往不是加载慢，而是某段 JS 锁死主线程超过 50ms。必须用 Observer，不能轮询：
- 注册时指定
{ entryTypes: ['longtask', 'largest-contentful-paint', 'first-input'] } - duration ＞50ms 的 longtask 就算风险项；连续多个 ＞100ms，大概率是未节流的 resize 监听、React 渲染深度过大或复杂计算
- 配合
requestIdleCallback把非关键逻辑延后执行，避免抢占渲染时机
测动画帧耗时，避开静默渲染瓶颈
动画卡顿常因强制同步布局（layout thrashing）或重绘开销大，而非 JS 执行慢：
- 在
requestAnimationFrame开头和动画逻辑结束后各调一次performance.now()，差值即真实帧耗时 - ＞16.7ms 标记为潜在卡顿帧；单帧 ＞100ms 或连续 3 帧 ＞50ms，需上报并排查
- 禁用
offsetTop、getBoundingClientRect()等读布局 API；只用transform和opacity动画属性
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
