如何监控网页卡顿和崩溃？

https://zhuanlan.zhihu.com/p/39292837

https://zhuanlan.zhihu.com/p/40273861

要监控网页的卡顿，我们必须从 FPS 说起。

FPS 是来自视频或者游戏里的概念，即是每秒的帧数，代表视频或者游戏的流畅度，俗话说，就是“不卡”。

那在前端开发领域，网页的 FPS 是什么呢？

什么是网页的 FPS？

网页内容在不断变化之中，网页的 FPS 是只浏览器在渲染这些变化时的帧率。帧率越高，用户感觉网页越流畅，反之则会感觉卡顿。

在 Chrome 中可以通过开发者工具查看网页的 FPS：

注意，网页不是随时都需要，该工具看到的是每次更新是 FPS 值。

最优的帧率是 60，即16.5ms 左右渲染一次。

通过 Chrome 或者 Firfox 等的性能工具也可以查看浏览器的帧率：

绿色的直方图即代表在页面重新绘制时的帧率，Frames 为每一帧渲染所花的时间。

另外一种给出网页 FPS 的方式

FPS extension 是 Chrome 的一个扩展，可以显示当前网页的 FPS 值，即页面是否卡顿。

这种工具获取页面 FPS 的方式与浏览器自身给出的方式不同，没有采用浏览器原生的 API（正在制定），这类工具独辟蹊径，通过浏览器的 requestAnimationFrame API （可以使用 setInterval polyfill）来实现。

代码类似：

var lastTime = performance.now();
var frame = 0;
var lastFameTime = performance.now();
var loop = function(time) {var now =  performance.now();var fs = (now - lastFameTime);lastFameTime = now;var fps = Math.round(1000/fs);frame++;if (now > 1000 + lastTime) {var fps = Math.round( ( frame * 1000 ) / ( now - lastTime ) );frame = 0;    lastTime = now;    };           window.requestAnimationFrame(loop);
}

代码摘自淘宝前端团队的《无线性能优化：FPS 测试》。

通俗地解释就是，通过 requestAnimationFrame API 来定时执行一些 JS 代码，如果浏览器卡顿，无法很好地保证渲染的频率，1s 中 frame 无法达到 60 帧，即可间接地反映浏览器的渲染帧率。关于 requestAnimationFrame API 的细节，可以参看 MDN 上的文档。

如何监控网页的卡顿？

首先为什么要监控？比如在全民直播，我们必须重视用户在观看视频的体验，任何网页或者播放器的卡顿都会让用户抓狂。所以必须监控起来，以此来指导优化。

最后，回到本文的主题，如何监控网页的卡顿呢？

以全民直播的方式为例，使用 FPS extension 类似的方式，每秒中计算一次网页的 FPS 值，获得一列数据：

...6,8,11,29,60,58,46,57,57,57,44,59,51,54,0,31,58,56,41,52,51,17,22, 34,51,48,26,26,49,59,59,59,59,52,52,0,45,58,60,59,60,21...

然后通过通用的日志通道上报到大数据平台进行分析即可。

那如何通过 FPS 确定网页存在卡顿呢？按照我们对卡顿的观察，连续出现3个低于20的 FPS 即可认为网页存在卡顿。

function isBlocking(fpsList, below=20, last=3) {var count = 0for(var i = 0; i < fpsList.length; i++) {if (fpsList[i] && fpsList[i] < below) {count++;} else {count = 0}if (count >= last) {return true}}return false
}

当然这只是一种经验，但可以作为相对的度量。

通过这种方式，我们得到了网页卡顿的统计数据：

接下来，就可以针对卡顿的问题，在有数据支持的情况下进行优化我们的网页了！

溃和卡顿有何差别？

卡顿也就是网页暂时响应比较慢，JS 可能无法及时执行，这也是上篇网页卡顿监控所依赖的技术点。

但崩溃就不一样了，网页都崩溃了，页面看不见了，JS 都不运行了，还有什么办法可以监控网页的崩溃，并将网页崩溃上报呢？

但，天无绝人之路，方法总是有的。

load 与 beforeunload 事件

搜遍互联网，几乎找不到方法，最终碰上了这篇文章。本文利用 window 对象的 load 和 beforeunload 事件实现了网页崩溃的监控。

http://jasonjl.me/blog/2015/06/21/taking-action-on-browser-crashes/jasonjl.me

  window.addEventListener('load', function () {sessionStorage.setItem('good_exit', 'pending');setInterval(function () {sessionStorage.setItem('time_before_crash', new Date().toString());}, 1000);});window.addEventListener('beforeunload', function () {sessionStorage.setItem('good_exit', 'true');});if(sessionStorage.getItem('good_exit') &&sessionStorage.getItem('good_exit') !== 'true') {/*insert crash logging code here*/alert('Hey, welcome back from your crash, looks like you crashed on: ' + sessionStorage.getItem('time_before_crash'));}

一图胜千言：

使用 load 和 beforeunload 事件实现崩溃监控

这个方案巧妙的利用了页面崩溃无法触发 beforeunload 事件来实现的。

在页面加载时（load 事件）在 sessionStorage 记录 good_exit 状态为 pending，如果用户正常退出（beforeunload 事件）状态改为 true，如果 crash 了，状态依然为 pending，在用户第2次访问网页的时候（第2个load事件），查看 good_exit 的状态，如果仍然是 pending 就是可以断定上次访问网页崩溃了！

但这个方案有问题：

采用 sessionStorage 存储状态，但通常网页崩溃/卡死后，用户会强制关闭网页或者索性重新打开浏览器，sessionStorage 存储但状态将不复存在；
如果将状态存储在 localStorage 甚至 Cookie 中，如果用户先后打开多个网页，但不关闭，good_exit 存储的一直都是 pending，完了，每有一次网页打开，就会有一个 crash 上报。

全民直播一开始采用的就是这个方案，发现就算页面做了优化，crash 不下降，与 PV 保持比例，才意识到这个方案的问题之处。

基于 Service Worker 的崩溃统计方案

随着 PWA 概念的流行，大家对 Service Worker 也逐渐熟悉起来。基于以下原因，我们可以使用 Service Worker 来实现网页崩溃的监控：

Service Worker 有自己独立的工作线程，与网页区分开，网页崩溃了，Service Worker 一般情况下不会崩溃；
Service Worker 生命周期一般要比网页还要长，可以用来监控网页的状态；
网页可以通过 navigator.serviceWorker.controller.postMessage API 向掌管自己的 SW 发送消息。

基于以上几点，我们可以实现一种基于心跳检测的监控方案：

p1：网页加载后，通过 postMessage API 每 5s 给 sw 发送一个心跳，表示自己的在线，sw 将在线的网页登记下来，更新登记时间；
p2：网页在 beforeunload 时，通过 postMessage API 告知自己已经正常关闭，sw 将登记的网页清除；
p3：如果网页在运行的过程中 crash 了，sw 中的 running 状态将不会被清除，更新时间停留在奔溃前的最后一次心跳；
sw：Service Worker 每 10s 查看一遍登记中的网页，发现登记时间已经超出了一定时间（比如 15s）即可判定该网页 crash 了。

一些简化后的检测代码，给大家作为参考：

// 页面 JavaScript 代码
if (navigator.serviceWorker.controller !== null) {let HEARTBEAT_INTERVAL = 5 * 1000; // 每五秒发一次心跳let sessionId = uuid();let heartbeat = function () {navigator.serviceWorker.controller.postMessage({type: 'heartbeat',id: sessionId,data: {} // 附加信息，如果页面 crash，上报的附加数据});}window.addEventListener("beforeunload", function() {navigator.serviceWorker.controller.postMessage({type: 'unload',id: sessionId});});setInterval(heartbeat, HEARTBEAT_INTERVAL);heartbeat();
}

sessionId 本次页面会话的唯一 id；
postMessage 附带一些信息，用于上报 crash 需要的数据，比如当前页面的地址等等。

const CHECK_CRASH_INTERVAL = 10 * 1000; // 每 10s 检查一次
const CRASH_THRESHOLD = 15 * 1000; // 15s 超过15s没有心跳则认为已经 crash
const pages = {}
let timer
function checkCrash() {const now = Date.now()for (var id in pages) {let page = pages[id]if ((now - page.t) > CRASH_THRESHOLD) {// 上报 crashdelete pages[id]}}if (Object.keys(pages).length == 0) {clearInterval(timer)timer = null}
}worker.addEventListener('message', (e) => {const data = e.data;if (data.type === 'heartbeat') {pages[data.id] = {t: Date.now()}if (!timer) {timer = setInterval(function () {checkCrash()}, CHECK_CRASH_INTERVAL)}} else if (data.type === 'unload') {delete pages[data.id]}
})

都挺简单的代码，不细说了。

方案的可行性

兼容性：

Service Worker 的普及率已经相当高了，鉴于国内各种浏览器都是 Chrome 内核，而且版本已经在 Chrome 45 以上，已经覆盖了相当一部分用户。作为监控，数据覆盖大部分就好。

Service Worker 兼容性

可靠性：

这应该是我目前已知可以相对准确判断出网页崩溃的方式了。不过我们的方案还在测试环境，上线一段时间后再给大家共享数据。

对浏览器厂商的建议

题图的 Crash 列表，可以在 Chrome 中访问 chrome://crashes/ 看到，如果厂商可以提供一个 API，在页面打开时，可以获知用户上一次崩溃的信息就很棒了！