建立核心性能监控体系需坚持“真实用户、可观测、可归因、可行动”四原则，分层设计并闭环落地：对齐业务定义健康水位（如电商首屏≤1.8s）、用sendbeacon上报并动态采样；时序数据库多维打标，告警基于7天同段p95动态基线；仪表盘支持下钻分析，简报自动关联pr与优化建议；同时监控sdk健康度指标。
要建立完整的核心性能监控体系，关键不是堆工具，而是围绕“真实用户、可观测、可归因、可行动”四个原则，分层设计、闭环落地。
明确核心指标与业务对齐
不能只盯 LCP、FID、CLS 这三个 Core Web Vitals，还要结合业务场景定义可衡量的健康水位： - 电商首屏加载（含商品卡片渲染）≤ 1.8s - 支付流程从点击到跳转完成 ≤ 800ms - 搜索结果页白屏时间 这些指标要写进发布准入卡点，比如 CI 流程中跑 Lighthouse 审计，FCP 超过 2s 自动阻断上线。分层采集：合成监控 + 真实用户监控（RUM）双轨并行
- 合成监控（实验室环境）：用 WebPageTest 私有化部署，固定设备、网络、浏览器版本，每天定时巡检核心路径。重点看 TTFB、资源加载瀑布图、第三方脚本阻塞情况。 - 真实用户监控（生产环境）：通过轻量 SDK（如 web-vitals 库）在页面中注入，按 5%~10% 抽样上报，捕获： - Navigation Timing（DNS 查询、TCP 建连、TTFB、DOM 解析等） - Resource Timing（关键 JS/CSS/图片加载耗时） - Long Tasks（主线程阻塞 > 50ms 的任务） - 自定义事件（如“加入购物车按钮点击→接口返回”端到端耗时）注意：上报必须用 navigator.sendBeacon，避免页面卸载丢失数据；采样率支持动态降级（如错误突增时自动升至 100%）。
数据处理与告警不靠经验，靠基线
- 存储推荐时序数据库（如 Prometheus + VictoriaMetrics 或 TimescaleDB），按 `page_url`、`device_type`、`network_type`（4G/WiFi）、`region` 多维打标。 - 告警不用固定阈值，改用动态基线：以过去 7 天同小时段 P95 值为基准，波动超 ±25% 且持续 3 个周期才触发。 - 异常必须带上下文：告警附带当时 Top 3 耗时资源、JS 错误栈、最近一次发版 commit ID、受影响用户地域分布热力图。可视化与闭环优化形成正循环
- 仪表盘不止展示数字，要能下钻： - 点击 LCP 偏高 → 查看该页面所有 LCP 候选元素（图片/标题/Hero 图）→ 对比各元素在不同机型上的渲染耗时 → 定位是否是某张未适配的 WebP 图导致 iOS 渲染卡顿 - 每周生成《性能健康简报》，自动关联： - 本周性能劣化 Top 3 页面 - 对应改动 PR 列表（Git 集成） - 优化建议（如：“首页 banner 组件新增了懒加载但未设 loading placeholder，导致 CLS 上升 0.12”）不复杂但容易忽略的是：监控本身要有健康度指标——SDK 注入成功率、上报成功率、数据延迟中位数，这些也要被监控。
