performance api 提供精准页面性能监测：优先用 navigation 条目替代已废弃的 performance.timing，计算 ttfb、html 解析、dom 就绪等关键耗时；结合 resource 条目分析懒加载资源网络与执行开销；用 user timing 主动标记业务节点量化逻辑成本；通过 longtask 和 first-input 监控主线程阻塞与交互延迟。
Performance API 是浏览器原生提供的性能监测工具，能精准捕获页面加载各阶段的真实耗时。关键不是“有没有加载”，而是“每个环节花了多久、卡在哪一步”。用对方法，就能快速定位延迟根源。
优先读取 navigation 条目，获取首屏关键阶段
别再依赖已废弃的 performance.timing——它在 Safari 和多数 WebView 中不可靠，字段常为 0 或 NaN。直接用：
-
performance.getEntriesByType('navigation')取出首个条目（即当前页面导航） - 计算核心延迟：TTFB（
responseStart - requestStart）、HTML 解析耗时（domInteractive - domLoading）、DOM 就绪时间（domContentLoadedEventEnd - startTime） - 注意：若
type === 'back_forward'，responseStart可能为 0，此时跳过 TTFB 计算
追踪懒加载资源的实际网络与执行开销
动态 import() 或图片懒加载后，不能只看“是否完成”，要看全过程：
- 用
performance.getEntriesByType('resource')过滤目标资源（如chunk-123.js或某张lazy.jpg） - 关注字段：
startTime（发起请求）、responseStart（首字节到达）、responseEnd（响应结束）、duration（总耗时） - 若
responseEnd - responseStart高 → 网络或服务端慢；若duration大但responseEnd小 → JS 解析/执行拖慢了
打点标记业务关键节点，量化逻辑成本
资源加载完 ≠ 组件可用。JS 下载后还要解析、实例化、挂载 DOM。这时要用 User Timing 主动标记：
- 触发懒加载前：
performance.mark('load-start') - 组件真正可交互后（如
connectedCallback执行完或状态更新完成）：performance.mark('load-ready') - 再调用
performance.measure('init-time', 'load-start', 'load-ready')，得到从触发到可用的完整耗时 - 后续可通过
performance.getEntriesByName('init-time')提取并上报
结合长任务与用户交互，判断是否影响体验
延迟不仅来自加载，还可能源于主线程阻塞：
- 用
PerformanceObserver监听longtask类型，识别 >50ms 的同步执行（比如渲染大量列表、同步数据处理） - 监听
first-input获取首次交互延迟（FID），超过 100ms 即说明用户已感知卡顿 - 对比懒加载组件插入前后
first-contentful-paint和largest-contentful-paint时间差，确认它是否拖慢了核心内容呈现
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
