生产环境JS性能监控需埋点与运行时分析双轨并行：用Performance API采集FCP/LCP/TTI等指标，结合帧率、长任务、内存探测主动发现卡顿，联动错误日志归因，并通过sendBeacon可靠上报。
生产环境的 JavaScript 性能监控，不能只靠开发阶段的调试工具，必须依赖轻量、稳定、可回溯的埋点 + 运行时分析双轨机制。核心目标是：在不影响用户操作的前提下，真实捕获关键性能瓶颈，并快速定位到代码层级。
一、用 Performance API 埋点采集关键指标
浏览器原生 window.performance 是最可靠的数据源，无需额外依赖，且时间精度高。重点采集以下几类指标：
-
首屏体验类：用
performance.getEntriesByType('paint')获取first-contentful-paint（FCP）和largest-contentful-paint（LCP），直接反映用户“看到内容”的速度； -
可交互类：通过
performance.timing.domInteractive或结合PerformanceObserver监听longtask类型，推算 TTI（Time to Interactive）； -
资源加载类：遍历
performance.getEntriesByType('resource')，筛选 JS/CSS/图片，统计加载耗时、失败率、是否跨域阻塞； -
自定义标记类：在关键逻辑前后调用
performance.mark()和performance.measure()，比如“表单提交校验开始→结束”，便于归因业务代码耗时。
二、运行时卡顿与内存异常主动探测
单纯看页面级指标不够——用户感知的“卡”，往往来自帧率骤降或内存持续增长。需在运行时植入轻量探测逻辑：
-
帧率监控：用
requestAnimationFrame计算每帧耗时，连续 3 帧 > 16ms 触发告警，记录当时调用栈快照； -
长任务捕获：监听
PerformanceObserver的longtask类型，获取执行时长、起始时间、关联的 iframe 或 worker 上下文； -
内存趋势观察：定期采样
window.performance.memory（若支持），关注usedJSHeapSize增长斜率，配合页面停留时长做归一化对比； - 避免轮询开销：所有探测逻辑应设为低频（如每 5 秒一次）、异步执行，且默认关闭，仅对灰度用户或问题会话开启。
三、错误与性能问题联动分析
单独看性能数据容易误判。要把 JS 错误、Promise 拒绝、资源加载失败和性能指标放在同一时间轴上交叉比对：
立即学习“Java免费学习笔记（深入）”；
- 当某次 FCP > 3s 时，检查同一毫秒级时间窗口内是否有未捕获错误或
unhandledrejection； - 若某页面 LCP 异常偏高，同时该页面
resource列表中某个 JS 加载耗时突增，优先排查该资源是否被动态插入或存在竞态； - 上报时携带统一 traceId，让前端日志、后端接口日志、CDN 日志可在服务端关联，形成完整链路。
四、上报策略必须保障可靠性与低干扰
埋点再准，报不上等于白做。生产环境必须规避常见陷阱：
- 优先用
navigator.sendBeacon()上报，尤其对卸载前（如跳转、关闭）的关键指标； - 对非关键数据（如帧率样本）做采样，例如只上报 10% 的用户或每 30 秒一条；
- 设置本地缓存队列（如最多 20 条），网络失败时暂存，下次页面加载时补发；
- 禁止在主线程同步发起 fetch/XHR，所有上报走微任务或
setTimeout(..., 0)脱离当前执行流。
不复杂但容易忽略：真正的线上性能监控，不是堆指标，而是建立“指标 → 异常信号 → 可定位代码段”的闭环。从 performance.mark 开始，到 sendBeacon 结束，中间每一步都要考虑稳定性与归因能力。
