performance api 仅采集性能数据，持久化需主动存至本地或服务端；推荐用 getentriesbytype 获取导航、资源、标记和长任务数据，结合 localstorage、sessionstorage 或 indexeddb 存储，并通过 sendbeacon 上报。
Performance API 本身不负责持久化，它只采集和提供性能数据；真正实现“持久化”，需要你把采集到的数据主动存到本地或服务端。关键在于：先用 Performance API 拿到数据，再选择合适的存储方式保存下来。
获取关键性能指标
优先使用现代、推荐的接口，避免依赖已废弃的 performance.timing：
- 导航阶段：用
performance.getEntriesByType('navigation')获取页面加载各阶段耗时（如 DNS 查询、TCP 连接、首字节、FCP、LCP 等） - 资源加载：用
performance.getEntriesByType('resource')提取图片、脚本、CSS 等资源的duration、size和发起者 - 自定义标记：用
performance.mark()和performance.measure()记录业务逻辑耗时（如“搜索开始”到“结果渲染完成”） - 长任务：用
performance.getEntriesByType('long-task')捕获阻塞主线程超过 50ms 的任务
本地存储方案选型与写法
根据数据量、生命周期和用途选择合适的方式：
-
小量、用户级指标（如 FCP、CLS、单次操作耗时）：用
localStorage，简单可靠
例如：localStorage.setItem('lastFCP', JSON.stringify({value: 1240, timestamp: Date.now()})) -
会话内临时聚合（如页面内多次交互的平均响应时间）：用
sessionStorage，关闭标签页即清空 -
结构化、批量、需查询的性能日志（如每秒帧率、内存快照、长任务堆栈）：用
IndexedDB，配合 Dexie.js 封装更易用
上报与服务端协同
仅存本地不够，多数场景需上报分析平台：
- 在页面卸载前（
beforeunload或visibilitychange到 hidden 时）收集并发送一次汇总数据 - 对关键指标（如 LCP > 4s、CLS > 0.25）触发即时上报，便于快速告警
- 避免阻塞主线程：用
sendBeacon()发送，确保即使页面跳转也能发出请求
例如：navigator.sendBeacon('/log/perf', JSON.stringify(data)) - 服务端需支持按设备、路径、版本等维度聚合，才能支撑后续优化决策
注意事项与避坑点
实际落地时容易忽略但影响效果的细节：
- Performance API 数据是高精度浮点数（如
1234.567890123），存 localStorage 前建议四舍五入到毫秒级，减少体积 - 不要在每次
mark后立刻存，而是按页面生命周期分组（如进入页、交互后、离开前）统一处理，降低 I/O 频次 - IndexedDB 写入是异步的，需监听
onsuccess或用 Promise 封装，避免丢失数据 - 隐私合规：若涉及用户行为路径或设备指纹字段，需明确告知并获得授权，尤其在 GDPR 或国内个保法框架下
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
