H5性能监控需交叉分析加载时长、慢加载占比、JS错误数、白屏率四指标：加载时长与慢加载占比组合区分普遍变慢与偶发卡顿；JS错误数与白屏率联动定位崩溃链路；所有分析须基于单位PV比率，并结合小时粒度、多维下钻识别真实根因。
直接看波动背后的真实原因，而不是只盯峰值或平均值。H5 性能监控的价值，在于把页面加载时长、慢加载占比、JS 错误数、白屏率这四个指标放在一起交叉比对，才能识别出趋势性问题。
加载时长 + 慢加载占比：区分“普遍变慢”和“偶发卡顿”
如果页面加载时长小幅上升（比如从 1200ms 到 1350ms），但慢加载占比同步明显升高（比如从 8% 跳到 22%），说明不是整体变慢，而是部分用户遭遇了明显劣化——大概率是网络条件差、低端机型或特定资源加载失败导致的。这时候要重点查 CDN 缓存命中率、首屏关键资源（如 JS/CSS/字体）的加载状态，以及是否新增了未做懒加载的第三方脚本。
- 加载时长升、慢加载占比也升 → 关注首屏资源体积与加载顺序
- 加载时长稳定、慢加载占比突然飙升 → 检查异常网络环境（如弱网模拟）、地域性 CDN 故障或某类设备兼容问题
- 加载时长降、慢加载占比却升 → 可能是优化引入了新问题，比如代码分割后某个 chunk 加载失败回退到全量包，或 service worker 缓存策略出错
JS 错误数 + 白屏率：定位前端崩溃链路
JS 错误数激增，往往伴随白屏率同步抬升，说明错误已影响到页面主逻辑或渲染流程。尤其要注意：白屏率跳升但 JS 错误数变化不大，可能意味着错误发生在更底层（如模板编译失败、hydration 失败、或框架初始化前的语法错误），这类错误未必被捕获为标准 error 事件，需结合 performance.getEntriesByType('navigation') 中的 domComplete 和 loadEventStart 时间差辅助判断。
- JS 错误数 ↑ + 白屏率 ↑ → 优先排查新上线 JS 逻辑、第三方 SDK 更新、或全局 polyfill 缺失
- JS 错误数平稳 + 白屏率 ↑ → 查 indexedDB 打开失败、localStorage 满、或 CSSOM 阻塞导致 render tree 无法构建
- JS 错误数 ↓ + 白屏率 ↑ → 可能是服务端返回空 HTML 或 SSR 渲染异常，需对比 TTFB 与 responseEnd 时间
PV 与各指标的归一化对比：避免被流量干扰误判
大促期间 PV 暴涨，若只看绝对错误数或白屏次数，容易误以为性能恶化。正确做法是用“每千次 PV 的 JS 错误数”“每万次打开的白屏次数”等比率指标来衡量。例如：某页面 PV 从 50 万升至 200 万，JS 错误从 1200 次升到 3800 次，表面看翻了 3 倍，但按千次 PV 计算，错误率从 2.4‰ 降到 1.9‰，实际是改善的。
立即学习“前端免费学习笔记（深入）”；
- 所有趋势分析必须基于单位 PV 的比率，而非原始计数
- 对比周期建议取最近 7 天滚动均值，避开节假日、版本发布日等干扰点
- 对新版本灰度流量，需单独切片分析，避免与老版本数据混叠
时间维度下钻：从“哪天变差”到“哪个时段变差”
单看日粒度数据，可能掩盖真实问题。比如某天整体慢加载占比升高 5%，但如果拆到小时粒度，会发现只在凌晨 2–4 点集中爆发——这往往指向定时任务（如日志聚合、缓存预热）抢占资源，或夜间 CDN 节点调度异常。同样，工作日上午 10 点白屏率突增，可能对应某类办公网代理策略变更。
- 默认查看小时级趋势，尤其关注业务低峰期的异常尖峰
- 将性能数据与后端接口成功率、CDN 响应时间、甚至服务器 CPU 使用率做时间对齐比对
- 移动端 H5 要叠加设备型号、OS 版本、网络类型（4G/WiFi）做多维下钻
