performance api 是观测工具而非优化手段，需通过精准打标（如 script-inject-start、wasm-fetch-start、raf采样）定位真实瓶颈，结合资源类型归因、避免无效采集，并用分位数（p75/p95/标准差）验证优化效果。
Performance API 本身不“减少”开销，它是观测工具；真正减少开销靠的是用它精准定位瓶颈后，针对性干预。关键不是测得快，而是测得准、归因清、改得对。
聚焦可干预的性能阶段，打标要落在真实瓶颈点
很多团队只打 mark('start') 和 mark('end')，结果 measure 出来一个总耗时，却不知道卡在哪。必须拆解为浏览器实际执行的原子阶段：
- 动态脚本注入：在
document.createElement('script')前打script-inject-start，插入 DOM 后立即打script-inserted，加载完成打script-loaded，执行首行打script-exec-start，末尾打script-exec-end - WASM 初始化：fetch 开始前打
wasm-fetch-start，WebAssembly.compile()回调里打wasm-compile-end，instantiate()成功后打wasm-instantiate-end - 动画帧：每次
requestAnimationFrame开头采样performance.now()，样式更新完成后再次采样，差值即该帧真实耗时
用资源类型和上下文做归因，避免泛泛优化
同一段逻辑，在不同条件下开销差异巨大，Performance API 提供字段帮你判断主导因素：
- 外链脚本耗时高？查
performance.getEntriesByType('resource')中对应 entry 的duration、connectStart、responseEnd—— 若connectStart到responseEnd占比大，说明网络或服务端问题，不该去压缩 JS - 内联脚本执行慢？看
script-exec-start到script-exec-end段是否拉长，结合是否含大量正则、闭包或eval，优先考虑语法简化或延迟执行 - ESM 动态导入卡顿？对比
script-loaded到script-exec-start时间，若 >30ms，大概率是模块解析开销，可考虑预编译或合并小模块 - 页面白屏久？对比
navigationentry 中domContentLoadedEventEnd和first-contentful-paint差值，若远大于资源加载总时长，说明 HTML 结构冗余或解析压力大，该删 wrapper、扁平 DOM
避开无效采集，让监控本身不成为新负担
Performance API 调用本身极轻量，但滥用会反噬性能：
- 不要高频调用
getEntriesByType()遍历全部 resource —— 先用initiatorType或name过滤目标资源 -
PerformanceObserver监听longtask时，开启buffered: true并设合理阈值（如 50ms），避免监听所有微任务 - 自定义
mark/measure控制总量，核心链路每阶段 1–2 个标记足够，非关键路径无需打点 - 上报性能数据用
setTimeout(..., 0)或requestIdleCallback异步发送，绝不阻塞主线程
验证优化是否生效，靠分布而非均值
改完代码后，不能只看平均帧率或平均加载时间：
- 动画场景：统计连续 100 帧的耗时标准差，>3ms 说明节奏抖动，即使均值是 12ms 也不够稳
- 脚本加载：对比优化前后
load-to-exec段的 P95 值，下降 20ms 以上才算有效 - 首屏渲染：关注
first-contentful-paint的 P75，而非平均值，因为用户感知取决于多数人遇到的情况
不复杂但容易忽略
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
