常规的性能体系
- 衡量加载阶段的耗时
- 以用户 感知为中心
- 开始渲染 —— 渲染出主要内容 —— 页面可交互 —— 交互是否有延迟 —— 稳定的视觉体验
- 从宏观到微观
- 宏观： 性能最差Top页面 和 性能恶劣Top页面
- 单页面：开始渲染：FP/FCP
- 单词访问：还原现场，针对性地优化，侧重资源加载的优化
多场景下的探索与实践
运行时性能缺失
- 业务痛点：
1. 有的页面操作需要等待时间才有响应，影响体验，如何找到这些操作，做好定向优化。
2. 无法衡量运行时性能，页面交互不够丝滑，感觉有点卡顿，有什么工具可以采集统计。
- 有页面交互：能定位性能差的交互操作
- 无页面交互：能评估页面的流畅程度，定位异常页面
- 痛点1解决方式：
- 目的：定位性能差的交互操作
- 思路：关联用户交互时的相关数据，还原用户交互的现场
- 方案例子：1. 监听交互事件，生成actionId；2. 记录变更：DOM变更、请求、资源加载、Long task 等数据，上报时关联actionId；3. 无进行中的请求，无持续的变更则结算当前交互时间
- 请求耗时：花费在请求上的时间有多少
- Long task耗时：累计造成了多长耗时的Long task
- 总耗时：从监控到交互，到页面达到稳定态的总时间
- 前端耗时：总耗时 - 请求耗时
- 痛点2解决方式：
- 目的：评估页面的流程程度，定位异常页面
- 基本表现：卡顿 —— FPS监控 —— 计算频繁，性能损耗大
- 直接数据：Long task —— 监控 —— 已经采集了，不需要额外采集
- 异常页面：Long task的耗时往往较大，让用户明显感知到糟糕体验，
- 根据页面维度设计指标：
- 长耗时影响用户率：发生长耗时的用户数/总用户数
- 长耗时影响PV率：发生长耗时的浏览次数/总浏览次数
- 长耗时占比：大于等于长耗时的数量/Long task总数
- 相比于正常用户，发生Long task的概率更大，耗时更长，除此之外，还有其他维度：系统、系统版本、浏览器版本、地区
微前端场景主子应用性能区分
- 单独衡量子应用的性能、单独衡量主应用的性能
- 目的：单独衡量子应用的性能
- 差异点：指标起点是子应用开始加载的时间点
- 难点：
- 浏览器相关性能API不再适用，需要自研算法
- 模仿浏览器计算原指标的方式
- 数据隔离，主子应用数据区分
- 统一收集子应用资源池，绘制子应用的资源加载瀑布图
- 目的：单独衡量主应用的性能
如何更快发现和定位问题
- 多段打通，快速定位性能瓶颈
- 与服务端打通：前端球球的响应时延比较高，而后侧API的时延较低
- 与客户端打通：串联端内页面与端上和服务端完整全链路
- 智能报警：自动跑数据，得出更合理的上下界，更精准的发现问题
- 研发流程：上线前，结合上线卡点工具；深入定位问题：源代码关联、异常追踪、劣势分析、防劣化
- 新增订阅：重新定义新增，确保每一个有通知意义的订阅都不被遗漏
