常规的性能体系

• 衡量加载阶段的耗时
• 以用户 感知为中心

• 开始渲染 —— 渲染出主要内容 —— 页面可交互 —— 交互是否有延迟 —— 稳定的视觉体验

• 从宏观到微观

• 宏观： 性能最差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的时延较低
• 与客户端打通：串联端内页面与端上和服务端完整全链路

• 智能报警：自动跑数据，得出更合理的上下界，更精准的发现问题
• 研发流程：上线前，结合上线卡点工具；深入定位问题：源代码关联、异常追踪、劣势分析、防劣化
• 新增订阅：重新定义新增，确保每一个有通知意义的订阅都不被遗漏