Performance Monitor打开 Chrome 控制台后,按组合键ctrl + p(mac 快捷键为command + p),输入> Show Performance Monitor,就可以打开 Performance Monitor 性能监视器 。主要的监控指标包括:
- CPU usage:CPU 占用率
- JS head size:JS 内存使用大小
- DOM Nodes:内存中挂载的 DOM 节点个数
- JS event listeners:事件监听数
- ...:其他等等
前端性能监控除了具体的性能分析和定位,我们也经常需要对业务进行性能监控 。前端性能监控包括两种方式:合成监控(Synthetic Monitoring,SYN)、真实用户监控(Real User Monitoring,RUM) 。
合成监控合成监控就是在一个模拟场景里,去提交一个需要做性能审计的页面,通过一系列的工具、规则去运行你的页面,提取一些性能指标,得出一个审计报告 。例如上面介绍的 Lighthouse 就是合成监控 。
合成监控的使用场景不多,一般可能出现在开发和测试的过程中,例如结合流水线跑性能报告、定位性能问题时本地跑的一些简单任务分析等 。该方式的优点显而易见:
- 可采集更丰富的数据指标,例如结合 Chrome Debugging Protocol 获取到的数据
- 较成熟的解决方案和工具,实现成本低
- 不影响真实用户的性能体验
我们提及前端监控的时候,大多数都包括了真实用户监控 。常见的一些性能监控包括加载耗时、DOM 渲染耗时、接口耗时统计等,而对于页面加载过程,可以看到它被定义成了很多个阶段:
文章插图
RUM 性能模型
而我们要做的,则是在力所能及的地方进行打点、计算、采集、上报,该过程常常需要借助 Performance Timeline API 。将需要的数据发送到服务端,然后再对这些数据进行处理,最终通过可视化等方式进行监控 。因此,真实用户监控往往需要结合业务本身的前后端架构设计来建设,其优点也比较容易理解:
- 完全还原真实场景,减去模拟成本
- 数据样本足够抹平个体的差异
- 采集数据可用于更多场景的分析和优化
但真实用户监控也有自身的优势,例如 TCP、DNS 连接耗时过高,在各种环境下的一些运行耗时问题,合成监控是很难发现的 。
性能分析自动化我们在开发过程中,也常常需要进行性能分析 。而前端的性能分析上手成本也不低,除了基本的页面加载耗时、网络耗时,更具体的定位往往需要结合前面介绍的 Performance 面板、FPS、CPU、火焰图等一点点来分析 。
如果这一块想要往自动化方向发展,我们可以怎么做呢?
使用 Lighthouse前面也有介绍 Lighthouse,它提供了脚本的方式使用 。因此,我们可以通过自动化任务跑脚本的方式,使用 Lighthouse 跑分析报告,通过对比以往的数据来进行功能变更、性能优化等场景的性能回归 。
使用 Lighthouse 的优势在于开发成本低,只需要按照官方提供的配置来调整、获取自己需要的一些数据,就可以快速接入较全面的 Lighthouse 拥有的性能分析能力 。
不过由于 Lighthouse 同样基于 CDP(Chrome DevTools Protocol),因此除了实现成本降低了,CDP 缺失的一些能力它也一样会缺失 。
Chrome DevTools ProtocolChrome DevTools Protocol 允许第三方对基于 Chrome 的 Web 应用程序进行检测、检查、调试、分析等 。有了这个协议,我们就可以自己开发工具获取 Chrome 的数据了 。
认识 Chrome DevTools 协议Chrome DevTools 协议基于 WebSocket,利用 WebSocket 建立连接 DevTools 和浏览器内核的快速数据通道 。
我们使用的 Chrome DevTools 其实也是一个 Web 应用 。我们使用 DevTools 的时候,浏览器内核 Chromium 本身会作为一个服务端,我们看到的浏览器调试工具界面,通过 Websocket 和 Chromium 进行通信 。建立过程如下:
推荐阅读
- 程序员必知的几种软件架构模式
- 为什么程序员如此热爱 TypeScript?
- 春季鼻塞头疼打喷嚏须警惕 切勿把鼻炎当成感冒对待
- 程序员的作恶能力超出你想象
- oracle常用运维命令整理
- 从头再学Vue的指令
- 全球最厉害的 14 位程序员,你认识几位?
- 13个程序员不可不知的VSCode插件,工作效率提升10倍
- 大学生|“理想男友”职业排名,程序员第三,“聪明绝顶”的医生成榜首
- 多核和多线程那些事