优化方法论

前端性能又分为加载性能和运行时性能

加载性能度量

加载性能就是用户从进入到页面到页面真正可用的这个过程的耗时。我们可以用一道经典的面试题入手：用户从键入url按下回车之后到看到页面这其中发生了什么？

DNS解析：把域名解析成ip地址
TCP连接建立
发送http请求
服务器解析http请求并返回结果
浏览器解析返回结果

而我们要做的就是记录这些过程的耗时：现代浏览器提供了 performance 对像供我们方便地提取这些数据。而且兼容性在这。其中 timing 对象详细记录每个节点的时间戳。

将相关时间节点相减就能得到相应过程的耗时。作为开发，我们通常更关注从服务器读取的时间，所以取 fetchStart 为起点。下面是一些常用的时间计算：

const { fetchStart, domainLookupStart, domainLookupEnd, domInteractive, domContentLoadedEventStart } = performance.timing

// DNS查找时间
domainLookupEnd - domainLookupStart

// 白屏时间
domInteractive - fetchStart

// 首屏时间
domContentLoadedEventStart - fetchStart
复制代码

以上计算时间更多用于SSR渲染，而如今前端现状还有相当部分是SPA结构，由JS渲染在客户端。为了更好地满足监控指标与用户体验的契合。Google 提出 FP / FCP / FMP / TTI 等指标帮助我们统计相关数据，我们常用下面两条

FCP(First Contentful Paint) 首次绘制任何文本，图像，非空白canvas或SVG的时间点。就是用户第一次看到有意义的内容的时间。通常可以当作这个时间为白屏时长。获取API

window.performance.getEntriesByType('paint')

TTI(Time To Intercative) 可交互(可用时间), 用于标记应用已进行视觉渲染并能可靠响应用户输入的时间点。我们通常用这个值作为页面的首屏时间。浏览器并没有直接提供api去获取。但是google提供 github.com/GoogleChrom… 去获取。

运行时性能度量

大部分业务并不需要运行时的监控。但是一些重业务场景，比如说文本编辑器、线上课堂、画板。顿卡对用户体验的伤害巨大，也是用户更无法接受的。对于这类业务，我们开发测试场景可以用 chrome 的 perfermance 工具去测试、检测、定位性能顿卡。但是我们仍然需要用户测的监控来掌握业务线上实际运行情况。 requestAnimationFrame 通常用来实现动画。但是这里我们也可以用来作为帧率的监控。大概简单思路如下：

const everyFrameCostTime = []
let timestamp = Date.now()
function detect() {
  const now = Date.now()
  const cost = now - timestamp
  timestamp = now
	everyFrameCostTime.push(cost)
  requestAnimationFrame(detect)
}

当cost 连续几次高于一个特地阈值，就可以视为页面顿卡了。这里可以视具体业务场景而定。

这种也有局限性，由于幸存者偏差，当页面卡死不动，监控代码本身也不起作用的。