要搭建可用的前端性能监控体系，需闭环采集、处理、上报：前置注册performanceobserver（head内无defer脚本），分类型监听fcp/lcp，navigation数据需readystate=complete后获取，跨域资源加crossorigin="anonymous"，用mark/measure刻画业务耗时，上报优先用sendbeacon并采样降压。
要真正用 Performance API 搭建起一套可用的前端性能监控体系，关键不是堆砌接口，而是把采集、处理、上报三个环节串成闭环，并确保核心指标不丢、数据可归因、问题能定位。
必须前置注册 PerformanceObserver
FCP、LCP 这类首屏指标是“一过性”的——渲染完成即生成，稍晚注册 observer 就永远错过。这不是代码写错，是浏览器根本没机会把它们塞进队列。
- 把
new PerformanceObserver()的初始化代码直接写在内的<script></script>标签里，不加defer，不包函数，不等任何钩子 - 监听
paint类型获取 FCP；单独监听largest-contentful-paint获取 LCP（不能混用同一 observer） - LCP 要取
list.getEntries().pop()，因为最大内容块可能被后续更大元素覆盖，最终值才是稳定指标
导航与资源数据要等时机再取
performance.getEntriesByType('navigation') 返回空数组？大概率是调用太早或上下文不对。
- 必须等
document.readyState === 'complete'或监听window.addEventListener('load', ...)后再执行 - SPA 路由跳转不会触发新 navigation 条目，它只记录页面首次加载；想监控路由级性能，得靠
mark/measure手动打点 - 跨域资源（如 CDN 上的 JS/CSS/图片）默认屏蔽
duration字段，需显式加crossorigin="anonymous"属性，动态创建的资源也要手动设crossOrigin = 'anonymous'
用 mark/measure 刻画业务逻辑耗时
白屏、首屏这些通用指标不够细，真实瓶颈常藏在业务流程里：搜索响应慢？列表渲染卡顿？表单提交延迟？
- 在关键节点打标记：
performance.mark('search-start')、performance.mark('search-end') - 用
performance.measure('search-duration', 'search-start', 'search-end')生成可上报的测量条目 - 结合
performance.getEntriesByType('measure')提取结果，按模块、场景、用户分群聚合分析
数据上报要可靠且低干扰
采集完不等于监控落地，上报失败或影响主线程，等于白做。
- 优先用
navigator.sendBeacon()发送，它在页面卸载前异步发送，不阻塞 unload 流程 - 避免在
beforeunload中同步发请求，容易被浏览器中断或丢弃 - 对高频率指标（如资源加载）做采样，比如只上报最慢的 5% 或超阈值（如 >1s）的资源，降低服务端压力
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
