性能始终是前端领域非常重要的话题，它直接决定了产品体验的优劣，重要性无需赘言。我们在体验一个产品时，能够直观感受到其性能，可是如何量化衡量性能的好坏呢？

同时，我们无法保证程序永远不出问题，如何在程序出现问题时及时获得现场数据、还原现场，以做出准确地响应呢？

离开了实际场景谈这些话题都是「耍流氓」，性能数据的监控、错误信息的收集和上报应该都要基于线上真实环境。这对于我们随时掌控线上产品，优化应用体验具有重大意义。

本节课程，我们就聚焦在性能监控和错误收集与上报系统上。希望通过学习，每个人都心中有数，做到不仅能够分析性能数据、处理错误，还能建设一个成熟的配套系统。

本节课主要知识点：

接下来，我们通过 2 节内容来学习这个主题。

性能监控指标

既然是性能监控，那我们首先需要明确衡量指标。一般来说，业界认可的常用指标有：

• 首次绘制（FP）和首次有内容绘制（FCP）时间
• 首次有意义绘制（FMP）时间
• 首屏时间
• 用户可交互（TTI）时间
• 总下载时间
• 自定义指标

接下来分别看看每个指标的含义。

首次绘制（FP）时间：对于应用页面，用户在视觉上首次出现不同于跳转之前的内容时间点，或者说是页面发生第一次绘制的时间点。

首次有内容绘制（FCP）时间：指浏览器完成渲染 DOM 中第一个内容的时间点，可能是文本、图像或者其他任何元素，此时用户应该在视觉上有直观的感受。

首次有意义绘制（FMP）时间：指页面关键元素渲染时间。这个概念并没有标准化定义，因为关键元素可以由开发者自行定义——究竟什么是「有意义」的内容，只有开发者或者产品经理自己了解。

首屏时间：对于所有网页应用，这是一个非常重要的指标。用大白话来说，就是进入页面之后，应用渲染完整个手机屏幕（未滚动之前）内容的时间。需要注意的是，业界对于这个指标其实同样并没有确切的定论，比如这个时间是否包含手机屏幕内图片的渲染完成时间。

用户可交互时间：顾名思义，也就是用户可以与应用进行交互的时间。一般来讲，我们认为是 domready 的时间，因为我们通常会在这时候绑定事件操作。如果页面中涉及交互的脚本没有下载完成，那么当然没有到达所谓的用户可交互时间。那么如何定义 domready 时间呢？我推荐参考司徒正美的文章：何谓 domReady。

以上时间，我们可以通过下图对比认识：

这是我访问 Medium 移动网站分析得到的时序图，读者可根据网页加载的不同时段，体会各个时间节点的变化。更完整的信息由 Chrome DevTool 给出：

通过 Google Lighthouse 分析得到：

请注意 First Meaningful Paint 和 First Contentful Paint 以及 Time to Interactive（可交互时间）被收录其中。

这里我们先对这些时间节点以及数据有一个感性的认知，后面将会逐步学习如何统计这些时间，做出如上图一样的分析系统。接下来，我们继续学习一些概念。

总下载时间：页面所有资源加载完成所需要的时间。一般可以统计 window.onload 时间，这样可以统计出同步加载的资源全部加载完的耗时。如果页面中存在较多异步渲染，也可以将异步渲染全部完成的时间作为总下载时间。

自定义指标：由于应用特点不同，我们可以根据需求自定义时间。比如，一个类似 Instagram 的页面，页面由图片瀑布流组成，那么我们可能非常关心屏幕中第一排图片渲染完成的时间。

这里我们提一下，DOMContentLoaded 与 load 事件的区别。其实从这两个事件的命名我们就能体会，DOMContentLoaded 指的是文档中 DOM 内容加载完毕的时间，也就是说 HTML 结构已经完整。但是我们知道，很多页面包含图片、特殊字体、视频、音频等其他资源，这些资源由网络请求获取，DOM 内容加载完毕时，由于这些资源往往需要额外的网络请求，还没有请求或者渲染完成。而当页面上所有资源加载完成后，load 事件才会被触发。因此，在时间线上，load 事件往往会落后于 DOMContentLoaded 事件。

如图：

表示页面加载一共请求了 13 个资源，大小为 309 KB，DOMContentLoaded 时间为 2.82 s，load 时间为 2.95 s，页面完全稳定时间 5.38 s

FMP 的智能获取算法

另外结合自定义指标和首次有意义绘制（FMP）时间，稍做延伸：我们知道首次有意义绘制比较主观，开发者可以自行指定究竟哪些属于有意义的渲染元素。我们也可以通过 FMP 的智能获取算法来完成自定义 FMP 时间。该算法实现过程如下。

首先，获取有意义的渲染元素，一般认为：

• 体积占比比较大
• 屏幕内可见占比大
• 属于资源加载元素（img、svg、video、object、embed、canvas）
• 主要元素是多个组成的

具备这几个条件的元素，更像是有意义的元素。根据元素对页面视觉的贡献，我们对元素特点的权重进行划分：

const weightMap = {
   SVG: 2,
   IMG: 2,
   CANVAS: 3,
   OBJECT: 3,
   EMBED: 3,
   VIDEO: 3,
   OTHER: 1
}

接着，我们对整个页面进行深度优先遍历搜索，之后对每一个元素进行分数计算，具体通过 element.getBoundingClientRect 获取元素的位置和大小，然后通过计算「width height weight * 元素在 viewport 的面积占比」的乘积，确定元素的最终得分。接着将该元素的子元素得分之和与其得分进行比较，取较大值，记录得分元素集。这个集合是「可视区域内得分最高的元素的集合」，我们会对这个集合的得分取均值，然后过滤出在平均分之上的元素集合，进行时间计算。这就得到了一个智能的 FMP 时间。

最终，代码由 qbright 实现：fmp-timing，感兴趣的读者可以自行了解细节。

性能数据获取

了解了上述性能指标，我们来分析一下这些性能指标数据究竟该如何计算获取。

window.performance：强大但有缺点

目前最为流行和靠谱的方案是采用 Performance API，它非常强大：不仅包含了页面性能的相关数据，还带有页面资源加载和异步请求的相关数据。

调用 window.performance.timing 会返回一个对象，这个对象包含各种页面加载和渲染的时间节点。如图：

具体解析：

const window.performance = {
   memory: {
       usedJSHeapSize,
       totalJSHeapSize,
       jsHeapSizeLimit
   },

   navigation: {
       // 页面重定向跳转到当前页面的次数
       redirectCount,
       // 以哪种方式进入页面
       // 0 正常跳转进入
       // 1 window.location.reload() 重新刷新
       // 2 通过浏览器历史记录，以及前进后退进入
       // 255 其他方式进入
       type,         
   },

   timing: {
       // 等于前一个页面 unload 时间，如果没有前一个页面，则等于 fetchStart 时间
       navigationStart
       // 前一个页面 unload 时间，如果没有前一个页面或者前一个页面与当前页面不同域，则值为 0
       unloadEventStart,
       // 前一个页面 unload 事件绑定的回调函数执行完毕的时间
       unloadEventEnd,
       redirectStart,
       redirectEnd,
       // 检查缓存前，准备请求第一个资源的时间
       fetchStart,
       // 域名查询开始的时间
       domainLookupStart,
       // 域名查询结束的时间
       domainLookupEnd,
       // HTTP（TCP） 开始建立连接的时间            connectStart,
       // HTTP（TCP）建立连接结束的时间
       connectEnd,
       secureConnectionStart,
       // 连接建立完成后，请求文档开始的时间
       requestStart,
       // 连接建立完成后，文档开始返回并收到内容的时间
       responseStart,
       // 最后一个字节返回并收到内容的时间
       responseEnd,
       // Document.readyState 值为 loading 的时间
       domLoading,
       // Document.readyState 值为 interactive
       domInteractive,
       // DOMContentLoaded 事件开始时间
       domContentLoadedEventStart,
       // DOMContentLoaded 事件结束时间
       domContentLoadedEventEnd,
       // Document.readyState 值为 complete 的时间            domComplete,
       // load 事件开始的时间
       loadEventStart,
       // load 事件结束的时间
       loadEventEnd
   }
}

根据这些时间节点，我们选择相应的时间两两做差，便可以计算出一些典型指标：

const calcTime = () => {
   let times = {}
   let t = window.performance.timing

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

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

   // TCP 建立连接完成握手的时间
   connect = t.connectEnd - t.connectStart

   // 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.domLoading - t.fetchStart

   // domReadyTime 即用户可交互时间
   times.domReadyTime = t.domContentLoadedEventEnd - t.fetchStart

   // 用户等待页面完全可用的时间
   times.loadPage = t.loadEventEnd - t.navigationStart

   return times
}

这个 API 非常强大，但是并不适用所有场景。比如：使用 window.performance.timing 所获的数据，在单页应用中改变 URL 但不刷新页面的情况下（单页应用典型路由方案），是不会更新的，还需要开发者重新设计统计方案。同时，可能无法满足一些自定义的数据。下面我们来分析一下部分无法直接获取的性能指标的计算方法。

自定义时间计算

首屏时间的计算实现方式不尽相同，开发者可以根据自己的需求来确定首屏时间的计算方式。我列举几个典型的方案。

对于网页高度小于屏幕的网站来说，统计首屏时间非常简单，只要在页面底部加上脚本，完成当前时间的打印即可，这个时间再通过与 window.performance.timing.navigationStart 时间做差，即得到首屏渲染耗时。

但网页高度小于屏幕的站点毕竟是少数：对于网页高度大于一屏的页面来说，只要在估算接近于一屏幕的最后一个元素的位置后，插入计算脚本即可：

var time = +new Date() - window.performance.timing.navigationStart

显然上述方案是比较理想化的，我们很难通过自动化工具或者一段集中管理的代码进行统计。开发者直接在页面 DOM 中插入时间统计，不仅代码侵入性太强，而且成本很高。同时，这样的计算方式其实并没有考虑首屏图片加载的情况，也就是说首屏图片未加载完的情况下，我们也认为加载已经完成。如果要考虑首屏图片的加载，建议使用集中化脚本统计首屏时间的方法：使用定时器不断检测 img 节点，判断图片是否在首屏且加载完成，找到首屏加载最慢的图片加载完成的时间，从而计算出首屏时间。如果首屏有没有图片，就用 domready 时间：

const win = window
const firstScreenHeight = win.screen.height
let firstScreenImgs = []
let isFindLastImg = false
let allImgLoaded = false
let collect = []

const t = setInterval(() => {
   let i, img
   if (isFindLastImg) {
       if (firstScreenImgs.length) {
           for (i = 0; i < firstScreenImgs.length; i++) {
               img = firstScreenImgs[i]
               if (!img.complete) {
                   allImgLoaded = false
                   break
               } else {
                   allImgLoaded = true
               }
           }
       } else {
           allImgLoaded = true
       }
       if (allImgLoaded) {
           collect.push({
               firstScreenLoaded: startTime - Date.now()
           })
           clearInterval(t)
       }
   } else {
       var imgs = body.querySelector('img')
       for (i = 0; i < imgs.length; i++) {
           img = imgs[i]
           let imgOffsetTop = getOffsetTop(img)
           if (imgOffsetTop > firstScreenHeight) {
               isFindLastImg = true
               break
           } else if (imgOffsetTop <= firstScreenHeight
           && !img.hasPushed) {
               img.hasPushed = 1
               firstScreenImgs.push(img)
           }
       }
   }
}, 0)

const doc = document
doc.addEventListener('DOMContentLoaded', () => {
   const imgs = body.querySelector('img')
   if (!imgs.length) {
       isFindLastImg = true
   }
})

win.addEventListener('load', () => {
   allImgLoaded = true
   isFindLastImg = true
   if (t) {
       clearInterval(t)
   }
})

另外一种方式是不使用定时器，且默认影响首屏时间的主要因素是图片的加载，如果没有图片，纯粹渲染文字是很快的，因此，可以通过统计首屏内图片的加载时间获取首屏渲染完成的时间。

(function logFirstScreen() {
   let images = document.getElementsByTagName('img')
   let iLen = images.length
   let curMax = 0
   let inScreenLen = 0

   // 图片的加载回调
   function imageBack() {
       this.removeEventListener
       && this.removeEventListener('load', imageBack, !1)
       if (++curMax === inScreenLen) {
           // 所有在首屏的图片均已加载完成的话，发送日志
           log()
       }   
   }
   // 对于所有的位于指定区域的图片，绑定回调事件
   for (var s = 0; s < iLen; s++) {
       var img = images[s]
       var offset = {
           top: 0
       }
       var curImg = img
       while (curImg.offsetParent) {
           offset.top += curImg.offsetTop
           curImg = curImg.offsetParent
       }
       // 判断图片在不在首屏
       if (document.documentElement.clientHeight < offset.top) {
           continue
       }
       // 图片还没有加载完成的话
       if (!img.complete) {
           inScreenLen++
           img.addEventListener('load', imageBack, !1)
       }
   }
   // 如果首屏没有图片的话，直接发送日志
   if (inScreenLen === 0) {
       log()
   }
   // 发送日志进行统计
   function log () {
       window.logInfo.firstScreen = +new Date() - window.performance.timing.navigationStart
       console.log('首屏时间：', +new Date() - window.performance.timing.navigationStart)
   }
})()

可见，除了使用教科书般强大的 Performance API 外，我们也完全拥有自主权来统计各种页面性能数据。这就需要开发者根据具体场景和业务需求，结合社区已有方案，找到完全适合自己的统计采集方式。

这节课我们介绍了性能核心指标以及获取方式，关键在于合理利用强大的 API。与此同时，对于「开放性」数据，我们需要结合实际，灵活进行开发。