Performance是一个做前端性能监控离不开的API，最好在页面完全加载完成之后再使用，因为很多值必须在页面完全加载之后才能得到。最简单的办法是在window.onload事件中读取各种数据。

# 一、回顾页面加载过程

要学习这套API的使用，先简单介绍下前端的基础知识

# 1.1 页面加载

一个页面的请求到响应再到显示出来，需要经过下面一些重要过程，当我们在浏览器输入一个URL或者说点击一个URL开始，会出现如下流程

页面准备
重定向：在header定义了重定向才会有这个过程，如果没有重定向，不会产生这个过程。
app cache：会先检查这个域名是否有缓存，如果有缓存就不需要DNS解析域名。这里的app是值应用程序application，不指手机app。
DNS解析：把域名解析成IP，如果直接用ip地址访问，不产生这个过程。
TCP连接：http协议是经过TCP来传输的，所以产生一个http请求就会有TCP connect，但是依赖于长连接，不会产生这个过程。
request header：请求头信息。
request body：请求体信息，比如get请求是没有请求体信息的，所以没有这个过程，这就是为什么把头跟体分开写的原因。
response header：响应头信息。
response body：响应体信息。
解析HTML结构
加载外部脚本和样式表文件：正常来说JS、css都是外部加载的，当然有不正常的人啊，比如我。
解析并执行脚本代码
构建与解析HTML DOM树：这个过程可以去了解下DOM树是怎样的就明白啦。
加载外部图片
页面加载完成，显示出来啦

# 1.2 重定向分析

app cach
DNS解析
TCP连接
request header
重定向
app cach
DNS解析
TCP连接
request header

# 二、performance

# 2.1 performance.timing

这个API能帮我们得到整个页面请求的时间，如下图，在Chrome的Console是可以直接运行的

先解释下这些时间都是代表什么

timing 对象里边的数据比较多，梳理如下几个关键性的节点

fetchStart：发起获取当前文档的时间点，我的理解是浏览器收到发起页面请求的时间点；
domainLookupStart：返回浏览器开始DNS查询的时间，如果此请求没有DNS查询过程，如长连接、资源cache、甚至是本地资源等，那么就返回fetchStart的值；
domainLookupEnd：返回浏览器结束DNS查询的时间，如果没有DNS查询过程，同上；
connectStart：浏览器向服务器请求文档，开始建立连接的时间，如果此连接是一个长连接，或者无需与服务器连接（命中缓存），则返回domainLookupEnd的值；
connectEnd：浏览器向服务器请求文档，建立连接成功的时间；
requestStart：开始请求文档的时间（注意没有requestEnd）;
responseStart：浏览器开始接收第一个字节数据的时间，数据可能来自于服务器、缓存、或本地资源；
unloadEventStart：卸载上一个文档开始的时间；
unloadEventEnd：卸载上一个文档结束的时间；
domLoading：浏览器把document.readyState设置为“loading”的时间点，开始构建dom树的时间点；
responseEnd：浏览器接收最后一个字节数据的时间，或连接被关闭的时间；
domInteractive：浏览器把document.readyState设置为“interactive”的时间点，DOM树创建结束；
domContentLoadedEventStart：文档发生DOMContentLoaded事件的时间；
domContentLoadedEventEnd：文档的DOMContentLoaded事件结束的时间；
domComplete：浏览器把document.readyState设置为“complete”的时间点；
loadEventStart：文档触发load事件的时间；
loadEventEnd：文档出发load事件结束后的时间

再来一张图，表示各阶段的开始与结束对应的时间

从以上的分析，我们就可以得到一些时间的计算

准备新页面耗时：fetchStart - navigationStart
重定向时间：redirectEnd - redirectStart
App Cache时间：domainLookupStart - fetchStart
DNS解析时间：domainLookupEnd -domainLookupStart
TCP连接时间：connectEnd - connectStart
request时间：responseEnd - requestStart这个计算是代表请求响应加起来的时间
请求完毕到DOM树加载：domInteractive -responseEnd
构建与解析DOM树，加载资源时间：domCompleter -domInteractive
load时间：loadEventEnd - loadEventStart
整个页面加载时间：loadEventEnd -navigationStart
白屏时间：responseStart-navigationStart

# 2.2 performance.getEntries()

这个API能帮我们获得资源的请求时间，包括JS、CSS、图片等

如上图可以看到这个API请求返回的是一个数组，这个数组包括整个页面所有的资源加载，上图打开了一个其中一个资源，可以看到如下信息

entryType：类型为resource
name：资源的url
initiatorType：资源是link
资源时间：duration的值，是responseEnd - startTime得到的

# 2.3 performance.memory

这个API主要是得到浏览器内存情况

jsHeapSizeLimit：内存大小限制
totalJSHeapSize：可使用的内容
userdJSHeapSize：已使用的内容

userdJSHeapSize表示所有被使用的JS堆栈内存，totalJSHeapSize可使用的JS堆栈内存，如果userdJSHeapSize的值大于totalJSHeapSize，就可能出现内存泄漏

# 三、动画帧率FPS

# 3.1 流畅动画的标准

FPS 表示的是每秒钟画面更新次数。我们平时所看到的连续画面都是由一幅幅静止画面组成的，每幅画面称为一帧，FPS 是描述“帧”变化速度的物理量

理论上说，FPS 越高，动画会越流畅，目前大多数设备的屏幕刷新率为 60 次/秒，所以通常来讲 FPS 为 60 frame/s 时动画效果最好，也就是每帧的消耗时间为 16.67ms

不同帧率的体验

帧率能够达到 50 ～ 60 FPS 的动画将会相当流畅，让人倍感舒适；
帧率在 30 ～ 50 FPS 之间的动画，因各人敏感程度不同，舒适度因人而异；
帧率在 30 FPS 以下的动画，让人感觉到明显的卡顿和不适感；
帧率波动很大的动画，亦会使人感觉到卡顿

# 3.2 获取我们页面动画当前的 FPS 值

那么我们该如何准确的获取我们页面动画当前的 FPS 值呢？

# 3.2.1 方法一借助 Chrome 开发者工具

Chrome 提供给开发者的功能十分强大，在开发者工具中，我们进行如下选择调出 FPS meter 选项：

通过这个按钮，可以开启页面实时 Frame Rate (帧率) 观测及页面 GPU 使用率

但是这个方法缺点太多了

这个只能一次观测一到几个页面，而且需要人工实时观测
数据只能是主观感受，并没有一个十分精确的数据不断上报或者被收集
因此，我们需要更加智能的方法。

# 3.2.2 方法二借助 Frame Timing API

Blink 内核早期架构

以 Chrome 浏览器内核 Blink 渲染页面为例。对早期的 Chrome 浏览器而言，每个页面 Tab 对应一个独立的 renderer 进程，Renderer进程中包含了主线程和合成线程。早期 Chrome 内核架构

其中，主线程主要负责：

Javascript 的计算与执行
CSS 样式计算
Layout 计算
将页面元素绘制成位图（paint），也就是光栅化（Raster）
将位图给合成线程

合成线程则主要负责：

将位图(GraphicsLayer 层)以纹理(texture)的形式上传给 GPU
计算页面的可见部分和即将可见部分（滚动）
CSS 动画处理
通知 GPU 绘制位图到屏幕上

其实知道了这两个线程之后，下一个概念是厘清 CSS 动画与 JS 动画的细微区别（当然它们都是 Web 动画）

JS 动画与 CSS 动画的细微区别

对于 JS动画而言，它们运行时的帧率即是主线程和合成线程加起来消耗的时间。对于流畅动画而言，我们希望它们每一帧的耗时保持在 16.67ms 之内;
而对于 CSS 动画而言，由于其流程不受主线程的影响，所以希望能得到合成线程的消耗的时间，而合成线程的绘制频率也反映了滚动和 CSS 动画的流程性。

上面主要想得出的一个结论是。如果我们能够知道主线程和合成线程每一帧消耗的时间，那么我们就能大致得出对应的 Web 动画的帧率。那么上面说到的 Frame Timing API 是否可以帮助我们拿到这个时间点呢

什么是 Frame Timing API ？

Frame Timing API 是 Web Performance Timing API 标准中的其中一位成员。Web Performance Timing API 是 W3C 推出的一套性能 API 标准，用于帮助开发者对网站各方面的性能进行精确的分析与控制，提升 Web 网站性能

它包含许多子类 API，完成不同的功能，大致如下

怎么使用呢？以 Navigation Timing, Performance Timeline, Resource Timing 为例子，对于兼容它的浏览器，它以只读属性的形式对外暴露挂载在 window.performance 上。

我们再来回顾这张图

通过这张图以及上面的 window.performance.timing，我们就可以轻松的统计出页面每个重要节点的耗时，这就是 Web Performance Timing API 的强大之处，感兴趣的可以详细去研究研究，使用在页面统计上

Frame Timing API 示意

终于可以回归正题，借助 Web Performance Timing API 中的Frame Timing API，可以轻松的拿到每一帧中，主线程以及合成线程的时间。或者更加容易，直接拿到每一帧的耗时

获取 Render 主线程和合成线程的记录，每条记录包含的信息基本如下

var rendererEvents = window.performance.getEntriesByType("renderer");
var compositeThreadEvents = window.performance.getEntriesByType("composite");

@前端进阶之旅: 代码已经复制到剪贴板

或者是：

ar observer = new PerformanceObserver(function(list) {
    var perfEntries = list.getEntries();
    for (var i = 0; i < perfEntries.length; i++) {
        console.log("frame: ", perfEntries[i]);
    }
});
 
// subscribe to Frame Timing
observer.observe({entryTypes: ['frame']});

前端性能之Performance|原理篇

前端性能之Performance|原理篇