前端性能监控及推荐几个开源的监控系统
web项目性能很重要,开发迭代过程中难免会有所忽视,性能会伴随产品的迭代而有所衰减。特别在移动端,网络一直是一个很大的瓶颈,而页面却越来越大,功能越来越复杂。并没有简单的几条黄金规则就可以搞定性能优化工作,我们需要一套性能监控系统持续监控、评估、预警页面性能状况、发现瓶颈,指导优化工作的进行。
1. 监控指标
前端性能指标主要有一下几种:
- 页面加载耗时:Page Load Time
- 首屏加载耗时:Above-the-Fold Time
- 重定向耗时:redirectEnd - redirectStart
- DNS查询耗时 :domainLookupEnd - domainLookupStart
- TCP链接耗时 :connectEnd - connectStart
- HTTP请求耗时 :responseEnd - responseStart
- 解析dom树耗时 : domComplete - domInteractive
- 白屏时间 :responseStart - navigationStart
- DOM ready耗时 :domContentLoadedEventEnd - navigationStart
- onload时间:loadEventEnd - navigationStart,也即是onload回调函数执行的时间。
除此之外还需要关注接口的成功调用率、接口响应时间、资源加载时间以及前端异常捕获等。
市场上有很多收费的监控系统,像阿里的ARMS等等,我们这里就不讨论了。如果我们从零开发一个完整的前端监控系统的话,还是需要一定的时间的,加上可能人手不足,大部分忙着业务的开发,所以大部分中小公司都选择一些第三方的付费监控系统。
我们有没有可能快速搭建一个上线可用的前端性能系统呢,答案是可以的,就是采用一些开源的前端性能监控系统,加上二次开发。这里我推荐几个给大家。
1. performanceKit
1.1 功能定义
前端基础性能监控
通用的性能监控只能是较简单的基础监控,很多更深入复杂的性能监控,需要针对特定的环境、场景配合页面设计、曝光等条件去定制化设计api,并在合适的地方调用。
例如采集Speed Index、Perceptual Speed Index、视觉完整时间(Visually Complete)、首次有效渲染时长(First Meaningful Paint)等指标。
1.2 npm安装
npm install performance-kits --save
1.3 需要在浏览器环境下
需要支持promise
需要支持performance,且支持performance timeline level2 规范
import performancekit from 'performance-kits';
const { onloadPerformance, switchPerformance, closePerformance } = performancekit;
其中,onloadPerformance用于检测页面onload后各项时间指标,所以要在项目入口文件就引入,不用担心会覆盖项目原有onload的回调,已做过兼容
switchPerformance用于路由切换时使用,需要开发者在监听路由变化的回调中使用。
closePerformance用于离开组件/关闭项目时使用,需要开发者在监听离开或关闭的回调中使用,需友情提示,如果是在关闭项目的回调中使用,那么通过接口上报数据的时候,通信方式请选择sendBeacon。
三个函数均只接受两个参数:
参数一:定时器间隔时间
参数二:总轮询时间
该轮询目的为找到paint类型的entry(需要浏览器兼容支持),进而进行关于渲染的性能监测
1.4 github地址
https://github.com/IndifferenceDoll/performanceKit
2. Webfunny
只需要简单几步就可以搭建一套属于自己的前端监控系统,实时了解线上应用的健康情况!
随时随地连接线上用户,无论何时何地,解决前端问题都易如反掌!
前端开发,后端接口,运营数据,产品分析
2.1 项目总览
监控系统支持多个项目,让所有项目的状态都一目了然。 通过对线上项目的实时分析,让我们可以对线上状况有个非常直观的了解。例如PV、UV数据变化趋势,线上报错、异常等
2.2 错误分析
精细化分析每一个报错问题,支持sourceMap源码定位。
通过探针监控和上报线上环境的报错,以及一些自定义异常。我们对这些日志进行精确的分析,可以准确定位到代码的问题所在。同时能够看到每一个报错的变化趋势,也能够分析出用户在哪一步操作中发生了问题。
2.3 用户细查
深入分析每一个用户,记录下每个用户的所有行为。
由于线上用户的操作行为十分复杂,有些问题可能隐藏在很多次操作之后,所以探针记录了用户的很多操作行为,一旦出现问题,复现BUG也将变得非常简单。 同时,可以使用多种检索条件进行搜索,提高查找效率。
2.4 性能分析
分析页面和接口性能,加载耗时,成功率。
探针对页面的加载性能进行分析,直观反映在报表之上。也对接口的性能进行了分析,如:耗时、成功率等。
3. zanePerfor
zanePerfor目前实现了哪些功能?
3.1 浏览器端(WEB)
- 页面级的性能上报(多页面 || 单页面应用程序通用)
- 页面AJAX性能上报
- 页面所有加载资源性能上报(图片,js,css)
- 页面所有错误信息上报(js,css,ajax)
3.2 微信小程序端
- path路径对应的AJAX性能上报
- 小程序错误信息上报(js,ajax,img)
- 用户设备信息及其网络信息上报
3.3 后端界面展示功能(web,小程序通用)
- 统计每分钟应用的PV,UV,IP信息,统计每天的PV,UV,IP,跳出率,用户访问平均深度
- 统计实时和每天的应用top最高访问排行,跳出率最高排行
- 统计实时和每天的全国省份流量热力图
- 统计每个用户每次访问的行为轨迹
相关文章
- 使用V8和node轻松profile分析nodejs应用程序
我们使用nodejs写好了程序之后,要是想对该程序进行性能分析的话,就需要用到profile工具了。
- 提升NginxTLS/SSL HTTPS 性能的7条优化建议
自2018年7月起,谷歌浏览器开始将“ HTTP”网站标记为“不安全”。在过去的几年中,互联网已经迅速过渡到HTTPS,Chrome浏览器的流量超过70%,并且Web排名前100位的网站中有80多个现在默认使用HTTPS 当前Nginx作为最常见的服务器,广泛用于负载均衡(LB)、网关、反向代理。考虑到这一点,让我们看一下Nginx调优技巧,改善Nginx + HTTPS的性能以获得更好的TTFB和更少的延迟。
- 只要五分钟,带你学会策略模式
大家好,今天给大家介绍一个新的设计模式——策略模式。
- 关于在移动端避免使用100vh的原因及解决方案
CSS中的Viewport单元听起来很棒。如果你想将一个元素设置成全屏高度,你可以设置高度:100vh,这样你就有了一个完美的全屏元素,它会随着视口的改变而改变大小!遗憾的是,事实并非如此。100vh在不同的浏览器的实现方式上也有一点微妙的变化,这使得它几乎毫无用处。最好避免100vh,而是依赖javascript来设置高度,以获得完整的视口体验。
- 前端性能监控及推荐几个开源的监控系统
web项目性能很重要,开发迭代过程中难免会有所忽视,性能会伴随产品的迭代而有所衰减。特别在移动端,网络一直是一个很大的瓶颈,而页面却越来越大,功能越来越复杂。并没有简单的几条黄金规则就可以搞定性能优化工作,我们需要一套性能监控系统持续监控、评估、预警页面性能状况、发现瓶颈,指导优化工作的进行。
随机推荐
- 使用V8和node轻松profile分析nodejs应用程序
我们使用nodejs写好了程序之后,要是想对该程序进行性能分析的话,就需要用到profile工具了。
- 提升NginxTLS/SSL HTTPS 性能的7条优化建议
自2018年7月起,谷歌浏览器开始将“ HTTP”网站标记为“不安全”。在过去的几年中,互联网已经迅速过渡到HTTPS,Chrome浏览器的流量超过70%,并且Web排名前100位的网站中有80多个现在默认使用HTTPS 当前Nginx作为最常见的服务器,广泛用于负载均衡(LB)、网关、反向代理。考虑到这一点,让我们看一下Nginx调优技巧,改善Nginx + HTTPS的性能以获得更好的TTFB和更少的延迟。
- 只要五分钟,带你学会策略模式
大家好,今天给大家介绍一个新的设计模式——策略模式。
- 关于在移动端避免使用100vh的原因及解决方案
CSS中的Viewport单元听起来很棒。如果你想将一个元素设置成全屏高度,你可以设置高度:100vh,这样你就有了一个完美的全屏元素,它会随着视口的改变而改变大小!遗憾的是,事实并非如此。100vh在不同的浏览器的实现方式上也有一点微妙的变化,这使得它几乎毫无用处。最好避免100vh,而是依赖javascript来设置高度,以获得完整的视口体验。
- 前端性能监控及推荐几个开源的监控系统
web项目性能很重要,开发迭代过程中难免会有所忽视,性能会伴随产品的迭代而有所衰减。特别在移动端,网络一直是一个很大的瓶颈,而页面却越来越大,功能越来越复杂。并没有简单的几条黄金规则就可以搞定性能优化工作,我们需要一套性能监控系统持续监控、评估、预警页面性能状况、发现瓶颈,指导优化工作的进行。