前端性能监控、中断请求

559 阅读11分钟

1、前端性能监控有了解吗?错误监控?数据上报?

// 前端监控流程
数据采集 --> 数据上报 --> 服务端处理 --> 数据库存储 --> 数据监控可视化平台

1.1 为什么要监控页面性能?

一个页面性能差的话会大大影响用户体验。用户打开页面等待的太久,可能会直接关掉页面,甚至就不再使用了,这种情况在移动端更加明显,移动端用户对页面响应延迟容忍度很低。

1.2 了解性能指标

为了帮助开发者更好地衡量和改进前端页面性能,W3C性能小组引入了 Navigation Timing API ,实现了自动、精准的页面性能打点;开发者可以通过 window.performance 属性获取。

  • performance.timing 接口(定义了从 navigationStartloadEventEnd 的 21 个只读属性)
  • performance.navigation(定义了当前文档的导航信息,比如是重载还是向前向后等)

Navigation Timing Level 2 指标解读 指标解读表 采集页面性能的关键指标 关键指标

(1)确定统计起始点 (navigationStart vs fetchStart )

页面性能统计的起始点时间,应该是用户输入网址回车后开始等待的时间。一个是通过navigationStart获取,相当于在URL输入栏回车或者页面按F5刷新的时间点;另外一个是通过 fetchStart,相当于浏览器准备好使用 HTTP 请求获取文档的时间。

从开发者实际分析使用的场景,浏览器重定向、卸载页面的耗时对页面加载分析并无太大作用;通常建议使用 fetchStart 作为统计起始点。

(2)首字节

主文档返回第一个字节的时间,是页面加载性能比较重要的指标。对用户来说一般无感知,对于开发者来说,则代表访问网络后端的整体响应耗时。

(3)白屏时间

用户看到页面展示出现一个元素的时间。很多人认为白屏时间是页面返回的首字节时间,但这样其实并不精确,因为头部资源还没加载完毕,页面也是白屏。

相对来说具备「白屏时间」统计意义的指标,可以取 domLoading - fetchStart,此时页面开始解析DOM树,页面渲染的第一个元素也会很快出现。

W3C Navigation Timing Level 2 的方案设计,可以直接采用 **domInteractive - fetchStart **,此时页面资源加载完成,即将进入渲染环节。

(4)首屏时间

首屏时间是指页面第一屏所有资源完整展示的时间。这是一个对用户来说非常直接的体验指标,但是对于前端却是一个非常难以统计衡量的指标。

具备一定意义上的指标可以使用 domContentLoaedEventEnd - fetchStart ,甚至使用 LoadEventStart - fetchStart ,此时页面DOM树已经解析完成并且显示内容。

以下给出统计页面性能指标的方法。

let times = {};
let t = window.performance.timing;

// 优先使用 navigation v2  https://www.w3.org/TR/navigation-timing-2/
if (typeof win.PerformanceNavigationTiming === 'function') {
  try {
    var nt2Timing = performance.getEntriesByType('navigation')[0]
    if (nt2Timing) {
      t = nt2Timing
    }
  } catch (err) {
  }
}

//重定向时间
times.redirectTime = t.redirectEnd - t.redirectStart;

//dns查询耗时
times.dnsTime = t.domainLookupEnd - t.domainLookupStart;

//TTFB 读取页面第一个字节的时间
times.ttfbTime = t.responseStart - t.navigationStart;

//DNS 缓存时间
times.appcacheTime = t.domainLookupStart - t.fetchStart;

//卸载页面的时间
times.unloadTime = t.unloadEventEnd - t.unloadEventStart;

//tcp连接耗时
times.tcpTime = t.connectEnd - t.connectStart;

//request请求耗时
times.reqTime = t.responseEnd - t.responseStart;

//解析dom树耗时
times.analysisTime = t.domComplete - t.domInteractive;

//白屏时间 
times.blankTime = (t.domInteractive || t.domLoading) - t.fetchStart;

//domReadyTime
times.domReadyTime = t.domContentLoadedEventEnd - t.fetchStart;

1.3 SPA盛行之际

Navigation Timing API可以监控大部分前端页面的性能。但随着SPA模式的盛行,类似vue,reactjs等框架的普及,页面内容渲染的时机被改变了,W3C标准无法完全满足原来的监控意义。

注意点

通过window.performance.timing所获的的页面渲染所相关的数据,在SPA应用中改变了url但不刷新页面的情况下是不会更新的。因此仅仅通过该api是无法获得每一个子路由所对应的页面渲染的时间。如果需要上报切换路由情况下每一个子页面重新render的时间,需要自定义上报。

1.4 错误监控

捕获错误的脚本要放置在最前面,确保可以收集到错误信息,以免被错误脚本报错阻碍

一般来说,按照错误监控错误监控可以分为:脚本错误监控、请求错误监控以及资源错误监控。

1.4.1 脚本错误监控

在编写 JavaScript 时,我们为了防止出现错误阻塞程序,我们会通过 try catch 捕获错误,对于错误捕获,这是最简单也是最通用的方案。

但是,try catch 捕获错误是侵入式的,需要在开发代码时即提前进行处理,而作为一个监控系统,无法做到在所有可能产生错误的代码片段中都嵌入 try catch。所以,我们需要全局捕获脚本错误。

1.4.2 常规脚本JS错误

/**
 * @description window.onerror 全局捕获错误
 * @param event 错误信息,如果是
 * @param source 错误源文件URL
 * @param lineno 行号
 * @param colno 列号
 * @param error Error对象
 */
window.onerror = function (event, source, lineno, colno, error) {
  // 上报错误
  // 如果不想在控制台抛出错误,只需返回 true 即可
};

window.onerror 有两个缺点:

只能绑定一个回调函数,如果想在不同文件中想绑定不同的回调函数,window.onerror 显然无法完成;同时,不同回调函数直接容易造成互相覆盖。 回调函数的参数过于离散,使用不方便 所以,一般情况下,我们使用 addEventListener 来代替。

/**
 * @param event 事件名
 * @param function 回调函数
 * @param useCapture 回调函数是否在捕获阶段执行,默认是false,在冒泡阶段执行
 */
window.addEventListener('error', (event) => {
  // addEventListener 回调函数的离散参数全部聚合在 error 对象中
  // 上报错误
}, true)

1.4.3 Promise 错误

和常规脚本错误的捕获一样,我们只需捕获 Promise 对应的错误事件即可。而 Promise 错误事件有两种,unhandledrejection 以及 rejectionhandled。

当 ==Promise 被 reject 且没有 reject 处理器==的时候,==会触发 unhandledrejection 事件==。

当 ==Promise 被 reject 且有 reject 处理器==的时候,==会触发 rejectionhandled 事件==。

// unhandledrejection 推荐处理方案
window.addEventListener('unhandledrejection', (event) => {
  console.log(event)
}, true);

// unhandledrejection 备选处理方案
window.onunhandledrejection = function (error) {
  console.log(error)
}

// rejectionhandled 推荐处理方案
window.addEventListener('rejectionhandled', (event) => {
  console.log(event)
}, true);

// rejectionhandled 备选处理方案
window.onrejectionhandled = function (error) {
  console.log(error)
}

1.4.4 请求错误监控

一般来说,前端请求有两种方案,使用 ajax 或者 fetch ,所以只需重写两种方法,进行代理,即可实现请求错误监控。

代理的核心在于使用 apply 重新执行原有方法,并且在执行原有方法之前进行监听操作。在请求错误监控中,我们关心三种错误事件:abort,error 以及 timeout,所以,只需在代理中对这三种事件进行统一处理即可

tips:如果能够统一使用一种请求工具,如 axios 等,那么不需要重写 ajax 或者 fetch 只需在请求拦截器以及响应拦截器进行处理上报即可

1.4.5 资源错误监控

资源错误监控本质上和常规脚本错误监控一样,都是监控错误事件实现错误捕获。

通过 instanceof 区分,脚本错误参数对象 instanceof ErrorEvent,而资源错误的参数对象 instanceof Event。

由于 ErrorEvent 继承于 Event ,所以不管是脚本错误还是资源错误的参数对象,它们都 instanceof Event,所以,需要先判断脚本错误

此外,两个参数对象之间有一些细微的不同,比如,脚本错误的参数对象中包含 message ,而资源错误没有,这些都可以作为判断资源错误或者脚本错误的依据。

/**
 * @param event 事件名
 * @param function 回调函数
 * @param useCapture 回调函数是否在捕获阶段执行,默认是false,在冒泡阶段执行
 */
window.addEventListener('error', (event) => {
  if (event instanceof ErrorEvent) {
    console.log('脚本错误')
  } else if (event instanceof Event) {
    console.log('资源错误')
  }
}, true);

==使用 addEventListener 捕获资源错误时,一定要将 useCapture 即第三个选项设为 true,因为资源错误没有冒泡,所以只能在捕获阶段捕获。同理,由于 window.onerror 是通过在冒泡阶段捕获错误,所以无法捕获资源错误。==

1.4.6 Scirpt error

跨域脚本的问题了,基于安全协议跨域脚本的报错无法接收到具体信息。因为线上的版本,经常做静态资源 CDN 化,这就会导致我们常访问的页面跟脚本文件来自不同的域名,这时候如果没有进行额外的配置,就会容易产生 Script error,解决办法如下:

  • 一:静态资源请求需要加多一个Access-Control-Allow-Origin头部。
  • 二:标签加上crossorigin属性

4. 数据上报方式

4.1 性能数据上报

性能数据可以在页面加载完之后上报,尽量不要对页面性能造成影响。

测量好时间后,就需要将数据发送给服务端。页面性能统计数据对丢失率要求比较低,且性能统计应该在尽量不影响主流程的逻辑和页面性能的前提下进行。

window.onload = () => {
    // 在浏览器空闲时间获取性能及资源信息
    // https://developer.mozilla.org/zh-CN/docs/Web/API/Window/requestIdleCallback
    if (window.requestIdleCallback) {
        window.requestIdleCallback(() => {
            monitor.performance = getPerformance()
            monitor.resources = getResources()
        })
    } else {
        setTimeout(() => {
            monitor.performance = getPerformance()
            monitor.resources = getResources()
        }, 0)
    }
}

当然,你也可以设一个定时器,循环上报。不过每次上报最好做一下对比去重再上报,避免同样的数据重复上报。

错误数据上报

我在DEMO里提供的代码,是用一个 errors 数组收集所有的错误,再在某一阶段统一上报(延时上报)。

其实,也可以改成在错误发生时上报(即时上报)。这样可以避免在收集完错误延时上报还没触发,用户却已经关掉网页导致错误数据丢失的问题。

// 监听 js 错误
window.onerror = function(msg, url, row, col, error) {
    const data = {
        type: 'javascript',
        row: row,
        col: col,
        msg: error && error.stack? error.stack : msg,
        url: url,
        // 错误发生的时间
        time: new Date().getTime(),
    }
    
    // 即时上报
    axios.post({ url: 'xxx', data, })
}

使用的img标签get请求

  • 不存在AJAX跨域问题,可做跨源的请求
  • 很古老的标签,没有浏览器兼容性问题
var i = new Image();
i.onload = i.onerror = i.onabort = function () {
  i = i.onload = i.onerror = i.onabort = null;
}
i.src = url;

navigator.sendBeacon

大部分现代浏览器都支持 navigator.sendBeacon方法。这个方法可以用来发送一些统计和诊断的小量数据,特别适合上报统计的场景。

  • 数据可靠,浏览器关闭请求也照样能发
  • 异步执行,不会影响下一页面的加载
  • API使用简单
window.addEventListener('unload', logData, false);

function logData() {
    navigator.sendBeacon("/log", analyticsData);
}
最终方案

当浏览器支持sendBeacon方法,优先使用该方法,使用img方式降级上报。

2、如何中断已发出去的请求?

AbortController

==AbortController[3]== 接口表示一个控制器对象,可以根据需要终止一个或多个Web请求。

AbortController():AbortController()构造函数创建一个新的 AbortController 对象实例

signal:signal 属性返回一个 AbortSignal 对象实例,它可以用来 with/about 一个Web(网络)请求

abort():终止一个尚未完成的Web(网络)请求,它能够终止 fetch 请求,任何响应Body的消费者和流

2.1 Fetch 中断请求

Fetch 是 Web 提供的一个用于获取资源的接口,如果要终止 fetch 请求,则可以使用 Web 提供的 AbortController 接口

首先我们使用 AbortController() 构造函数创建一个控制器,然后使用 AbortController.signal 属性获取其关联 AbortSignal 对象的引用。当一个 fetch request 初始化时,我们把 AbortSignal 作为一个选项传递到请求对象 (如下:{signal}) 。这将信号和控制器与获取请求相关联,然后允许我们通过调用 AbortController.abort() 中止请求。

const controller = new AbortController();
let signal = controller.signal;
//AbortSignal{aborted: false,onabort:null}
 console.log('signal 的初始状态: ', signal);
 
const downloadBtn = document.querySelector('.download');
const abortBtn = document.querySelector('.abort');
 
downloadBtn.addEventListener('click', fetchVideo);
 
abortBtn.addEventListener('click', function() {
  controller.abort();
  //AbortSignal{aborted: true,onabort:null}
 console.log('signal 的中止状态: ', signal);
});
 
function fetchVideo() {
  //...
  fetch(url, {signal}).then(function(response) {
    //...
  }).catch(function(e) {
    reports.textContent = 'Download error: ' + e.message;
  })
}

2.2 axios 中断请求

axions 中断请求有两种方式:

方式一

使用 CancelToken.souce 工厂方法创建一个 cancel token,代码如下:

axios 为我们提供了一个 isCancel() 方法,用于判断请求的中止状态。isCancel() 方法的参数,就是我们在中止请求时自定义的信息。

const CancelToken = axios.CancelToken;
const source = CancelToken.source();
 
axios.get('https://mdn.github.io/dom-examples/abort-api/sintel.mp4', {
  cancelToken: source.token
}).catch(function (thrown) {
  // 判断请求是否已中止
  if (axios.isCancel(thrown)) {
    // 参数 thrown 是自定义的信息
    console.log('Request canceled', thrown.message);
  } else {
    // 处理错误
  }
});
 
// 取消请求(message 参数是可选的)

source.cancel('Operation canceled by the user.');

方式二

通过传递一个 executor 函数到 CancelToken 的构造函数来创建一个 cancel token:

const CancelToken = axios.CancelToken;
let cancel;
 
axios.get('/user/12345', {
  cancelToken: new CancelToken(function executor(c) {
    // executor 函数接收一个 cancel 函数作为参数
    cancel = c;
  })
});
 
// 取消请求
cancel('Operation canceled by the user.');
复制代码

下面是参考和学习的链接:

前端的错误监控

前端性能监控

数据上报

如何中断一发出去的请求