乐趣区

关于前端:一文彻底搞懂前端监控

关注公众号“执鸢者”,回复“红宝书”获取“javaScript 高级程序第四版(pdf)”及大量前端学习材料。

一、前端监控现状

近年来,前端监控是越来越火,目前曾经有很多成熟的产品供咱们抉择应用,如下图所示

有这么多监控平台,那为什么还要学习搞前端监控?

  • 一方面人家是要钱的
  • 另一方面本人的我的项目须要定制化的性能。

二、前端监控的目标

  1. 晋升用户体验
  2. 更快的发现发现异常、定位异样、解决异样
  3. 理解业务数据,领导产品升级——数据驱动的思维

三、前端监控的流程

3.1 采集

前端监控的第一个步骤就是数据采集,采集的信息蕴含环境信息、性能信息、异样信息、业务信息。

3.1.1 环境信息

环境信息是每个监控零碎必备的内容,毕竟排查问题的时候须要晓得来自哪个页面、浏览器是谁、操作用户是谁……, 这样能力疾速定位问题,解决问题。个别这些常见的环境信息次要蕴含:

  1. url:正在监控的页面,该页面可能会呈现性能、异样问题。获取形式为:<br/>
    window.location.href<br/>
  2. ua: 拜访该页面时该用户的 userAgent 信息,蕴含操作系统和浏览器的类型、版本等。获取形式为:<br/>
    window.navigator.userAgent
  3. token:记录以后用户是谁。通过记录该用户是谁。<br/>
    一方面不便将该用户的所有监控信息建立联系,不便数据分析;<br/>
    另一方面通过该标识能够查看该用户的所有操作,不便复现问题。<br/>

3.1.2 性能信息

页面的性能间接影响了用户留存率,,Google DoubleClick 钻研表明:如果一个挪动端页面加载时长超过 3 秒,用户就会放弃而来到。BBC 发现网页加载时长每减少 1 秒,用户就会散失 10%。,Google DoubleClick 钻研表明:如果一个挪动端页面加载时长超过 3 秒,用户就会放弃而来到。BBC 发现网页加载时长每减少 1 秒,用户就会散失 10%。所以咱们的谋求就是进步页面的性能,为了进步性能须要监控哪些指标呢?

3.1.2.1 指标分类

指标有很多,我总结为以下两个方面:网络层面和页面展现层面。
一、网络层面
从网络层面来看波及的指标有:重定向耗时、DNS 解析耗时、TCP 连贯耗时、SSL 耗时、TTFB 网络申请耗时、数据传输耗时、资源加载耗时……, 各个指标的解释如下表所示:

指标 解释
重定向耗时 重定向所消耗的工夫
DNS 解析耗时 浏览器输出网址后首先会进行 DNS 解析,其能够对服务器是否工作作出反馈
TCP 连贯耗时 指建设连贯过程的耗时
SSL 连贯耗时 指数据安全性、完整性建设耗时
TTFB 网络申请耗时 示意浏览器接管第一个字节的工夫
数据传输耗时 浏览器接管内容所消耗的工夫
资源加载耗时 DOM 构建结束后到页面加载结束这段时间

二、页面展现层面

页面展现层面的指标是针对用户体验提出的几个指标,蕴含 FP、FCP、LCP、FMP、DCL、L 等,这几个指标其实就是 chrome 浏览器中 performance 模块的指标(如图所示)。

各个指标的解释如下表所示。

指标 解释
FP(First Paint) 首次绘制,标记浏览器渲染任何在视觉上不同于导航前屏幕内容之内容的工夫点.
FCP(First Contentful Paint) 首次内容绘制,标记浏览器渲染来自 DOM 第一位内容的工夫点,该内容可能是文本、图像、SVG 甚至 元素.
LCP(Largest Contentful Paint) 最大内容渲染,示意可视区“内容”最大的可见元素开始呈现在屏幕上的工夫点。
FMP(First Meaningful Paint) 首次无效绘制,示意页面的“次要内容”开始呈现在屏幕上的工夫点。它是咱们测量用户加载体验的次要指标。
DCL(DomContentLoaded) 当 HTML 文档被齐全加载和解析实现之后,DOMContentLoaded 事件被触发,无需期待样式表、图像和子框架的实现加载.
L(onLoad) 当依赖的资源全副加载结束之后才会触发
TTI(Time to Interactive) 可交互工夫,用于标记利用已进入视觉渲染并能牢靠响应用户输出的工夫点
FID(First Input Delay) 首次输出提早,用户首次和页面交互(单击链接、点击按钮等)到页面响应交互的工夫
3.1.2.2 指标求解

上述这么多指标该怎么获取呢?浏览器给咱们留了相应的接口——神奇的 window.performance,通过该接口能够获取一些列与性能相干的参数,上面以 https://baidu.com 为例来看一下与这些指标相干的参数:

window.performance 中的 timing 属性中的内容不就是为了求解上述指标所须要的值吗?看着下面的属性值再对应上面的 performance 拜访流程图,整个过程是不是高深莫测。

有了下面的值咱们就一起求解上述的指标:
一、网络层面

指标 计算
重定向耗时 redirectEnd – redirectStart
DNS 解析耗时 domainLookupEnd – domainLookupStart
TCP 连贯耗时 connectEnd – connectStart
SSL 连贯耗时 connectEnd – secureConnectionStart
TTFB 网络申请耗时 responseStart – requestStart
数据传输耗时 responseEnd – responseStart
资源加载耗时 loadEventStart – domContentLoadedEventEnd

二、页面展现层面

Google 工程师始终在推动以用户为核心的性能指标,所以页面展现层面的变动较大,求解形式稍有不同:

  1. FP 和 FCP

通过 window.performance.getEntriesByType(‘paint’)的形式获取

const paint = window.performance.getEntriesByType('paint');
const FP = paint[0].startTime,
const FCP = paint[1].startTime,
  1. LCP
function getLCP() {
    // 减少一个性能条目标观察者
    new PerformanceObserver((entryList, observer) => {let entries = entryList.getEntries();
        const lastEntry = entries[entries.length - 1];
        observer.disconnect();
        console.log('LCP', lastEntry.renderTime || lastEntry.loadTime);
    }).observe({entryTypes: ['largest-contentful-paint']});
}
  1. FMP
function getFMP() {
    let FMP;
    new PerformanceObserver((entryList, observer) => {let entries = entryList.getEntries();
        observer.disconnect();
        console.log('FMP', entries);
    }).observe({entryTypes: ['element']});
}
  1. DCL
domContentLoadEventEnd – fetchStart
  1. L
loadEventStart – fetchStart
  1. TTI
domInteractive – fetchStart
  1. FID
function getFID() {new PerformanceObserver((entryList, observer) => {let firstInput = entryList.getEntries()[0];
        if (firstInput) {
            const FID = firstInput.processingStart - firstInput.startTime;
            console.log('FID', FID);
        }
        observer.disconnect();}).observe({type: 'first-input', buffered: true});
}

3.1.3 异样信息

对于网站来说,异样信息是最致命、最影响用户体验的问题,须要重点监控。对于异样信息能够分为两类:运行时谬误、接口谬误。上面就别离来唠一唠这两类谬误。

一、运行时谬误

当 JavaScript 运行时有可能会产生谬误,可归类为七种:语法错误、类型谬误、范畴谬误、援用谬误、eval 谬误、URL 谬误、资源加载谬误。为了捕捉代码谬误,须要思考两类场景:非 Promise 场景和 Promise 场景,因为两种场景捕捉谬误的策略不同。

1. 非 Promise 场景

非 Promise 场景可通过监听 error 事件来捕捉谬误。对于 error 事件捕捉的谬误分为两类:资源谬误和代码谬误。资源谬误指的就是 js、css、img 等未加载,该谬误只能在捕捉阶段获取到,且为资源谬误时 event.target.localName 存在值(用此辨别资源谬误与代码谬误);代码谬误指的就是语法错误、类型谬误等这一类谬误,能够获取代码谬误的信息、堆栈等,用于排查谬误。

export function listenerError() {window.addEventListener('error', (event) => {if (event.target.localName) {console.log('这是资源谬误', event);
        }
        else {console.log('这是代码谬误', event);
        }
    }, true)
}

2.Promise 场景

Promise 场景的解决形式有所不同,当 Promise 被 reject 且没有 reject 处理器的时候,会触发 unhandlerejection 事件,所以通过监听 unhandlerejection 的事件来捕捉谬误。

export function listenerPromiseError() {window.addEventListener('unhandledrejection', (event) => {console.log('这是 Promise 场景中谬误', event);
    })
}

二、接口谬误

对于浏览器来说,所有的接口均是基于 XHR 和 Fetch 实现的,为了捕捉接口中的谬误,能够通过重写该办法,而后通过接口返回的信息来判断以后接口的情况,上面以 XHR 为例来展现封装过程。

function newXHR() {
    const XMLHttpRequest = window.XMLHttpRequest;
    const oldXHROpen = XMLHttpRequest.prototype.open;
    XMLHttpRequest.prototype.open = (method, url, async) => {
        // 做一些本人的数据上报操作
        return oldXHROpen.apply(this, arguments);
    }

    const oldXHRSend = XMLHttpRequest.prototype.send;
    XMLHttpRequest.prototype.send = (body) => {
        // 做一些本人的数据上报操作
        return oldXHRSend.apply(this, arguments);
    }
}

3.1.4 业务信息

每个产品都会有本人的业务信息,例如用户在线时长、pv、uv、用户散布等,通过获取这些业务信息能力更加分明的理解目前产品的情况,以便产品经理更好的去布局产品的将来方向。因为每个产品业务信息多种多样,小伙伴本能够依照本人的需要进行撰写代码,此处我就不再赘述。

3.2 上报

对于上报的形式无外乎两种:一种是 Ajax 的形式上报;另一种是通过 Image 的模式进行上报。目前很多大厂采纳的上报形式均是通过一个 1 * 1 像素的的 gif 图片进行上报,既然人家都采纳该种策略,那咱们就来唠一唠上面两个问题。

  • 为什么采纳 Image 的形式上报?<br/>

    1. 没有跨域问题。因为数据服务器和后端服务器大概率是不同的域名,若采纳 Ajax 的形式进行解决还要解决跨域问题,否则数据会被浏览器拦挡。<br/>
    2. 不会阻塞页面加载,只需 new Image 对象即可。
  • 图片类型很多,为什么采纳 gif 这种格局进行上报?<br/>
    其实归结为一个字——小。对于 1 *1px 的图片,BMP 构造的文件须要 74 字节,PNG 构造的文件须要 67 字节,GIF 构造的文件只须要 43 字节。同样的响应,GIF 能够比 BMP 节约 41% 的流量,比 PNG 节约 35% 的流量,所以抉择 gif 进行上报。

3.3 剖析

日志上报之后须要进行荡涤,获取本人所须要内容,并将剖析内容进行存储。依据数据量的大小可分为两种形式:单机和集群。

一、单机<br/>

访问量小、日志少的网站能够采纳单机的形式对数据进行剖析,例如用 node 读取日志文件,而后通过日志文件中获取所须要的信息,最终将解决的信息存储到数据库中。<br/>

二、集群<br/>

很多产品的访问量很大,日志很多,此时就须要利用 Hadoop 进行分布式解决,获取最终处理结果,其解决流程图如下所示:

依据本人的日志量级决定本人的剖析形式,适合的就是最好的,不必一味谋求最优的、最先进的解决形式。

3.4 报警

当异样类型超多肯定阈值之后须要进行报警告诉,让对应的工作人员去解决问题,及时止损。依据报警的级别不同,能够抉择不同的报警形式。

  1. 邮件——一般报警
  2. 短信——重大报警,已影响局部业务
  3. 电话——特地重大,例如零碎已宕机

1. 如果感觉这篇文章还不错,来个分享、点赞、吧,让更多的人也看到

2. 关注公众号执鸢者,支付学习材料,定期为你推送原创深度好文

参考

http://www.alloyteam.com/2020…
https://www.colabug.com/2019/…

退出移动版