performance api 是浏览器内置的高性能采集工具，需按需适时触发：应在 load 事件后调用 getentries，用 performanceobserver 监听动态资源与长任务，通过 mark/measure 打点业务耗时，注意跨域资源需服务端配合 timing-allow-origin 响应头及前端设置缓冲区。
Performance API 是浏览器内置的高性能采集工具，能直接获取页面加载、资源请求、脚本执行、渲染帧和主线程占用等真实运行数据。关键不是“全量抓取”，而是按需、适时、合规地触发记录。
在正确时机调用 getEntries 系列方法
过早调用（如 script 同步执行中）会导致返回空数组——此时浏览器尚未完成导航或资源记录。必须等到页面基础生命周期就绪：
- 监听
window.addEventListener('load', ...)，确保 HTML 解析完成、所有初始资源（图片、CSS、JS）已触发加载逻辑 - 对首屏绘制类指标（如 first-paint），需提前注册监听：
performance.getEntriesByType('paint')要求页面支持且已在 paint 事件发生前启用 - 若需捕获动态插入的资源（如懒加载图片），推荐用
PerformanceObserver实时监听，而非轮询getEntriesByType
用 mark/measure 刻画业务逻辑耗时
对关键交互路径（如搜索响应、表单提交、组件挂载），应主动打点，避免依赖被动采集：
- 在函数入口调用
performance.mark('search-start')，出口处调用performance.mark('search-end') - 用
performance.measure('search-total', 'search-start', 'search-end')生成可上报的测量条目 - 后续通过
performance.getEntriesByType('measure')提取，字段duration即为精确毫秒值 - 长时间运行应用建议定期清理：
performance.clearMarks()和performance.clearMeasures()防止内存堆积
监听长任务与渲染指标保障交互流畅
卡顿往往来自主线程被长时间占用，仅靠 JS 执行时间不够，需结合浏览器底层反馈：
- 创建
PerformanceObserver监听longtask类型，捕获 ≥50ms 的任务，定位阻塞源 - 监听
paint类型获取first-paint和first-contentful-paint时间，判断用户感知的首屏速度 - 监听
largest-contentful-paint和layout-shift，覆盖 Core Web Vitals 中 LCP 与 CLS 指标 - 注意：部分类型（如
paint）需浏览器支持（Chrome 60+），调用前可用'paint' in performance判断
处理跨域资源与缓冲区限制
第三方脚本、CDN 图片等跨域资源默认不暴露细粒度时间，且浏览器对性能条目有容量限制：
- 服务端必须返回
Timing-Allow-Origin: *响应头，否则resource条目的duration、responseStart等字段为 0 - 前端需显式扩大缓冲区：
performance.setResourceTimingBufferSize(500)，防止早期资源记录被覆盖 - 监听
bufferfull事件，在缓冲区满时及时上报并清空，避免丢数 -
crossorigin="anonymous"属性必须加在资源标签上（如<img crossorigin>），否则仍受跨域脱敏影响
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
