我们知道，动画其实是由一帧一帧的图像构成的。有 Web 动画那么就会存在该动画在播放运行时的帧率。而帧率在不同设备不同情况下又是不一样的。

有的时候，一些复杂或者重要动画，我们需要实时监控它们的帧率，或者说是需要知道它们在不同设备的运行状况，从而更好的优化它们，本文就是介绍 Web 动画帧率（FPS）计算方法。

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

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

当然，经常玩 FPS 游戏的朋友肯定知道，吃鸡/CSGO 等 FPS 游戏推荐使用 144HZ 刷新率的显示器，144Hz 显示器特指每秒的刷新率达到 144Hz 的显示器。相较于普通显示器每秒60的刷新速度，画面显示更加流畅。因此144Hz显示器比较适用于视角时常保持高速运动的第一人称射击游戏。
不过，这个只是显示器提供的高刷新率特性，对于我们 Web 动画而言，是否支持还要看浏览器，而大多数浏览器刷新率为 60 次/秒。

直观感受，不同帧率的体验：

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

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

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

但是这个方法缺点太多了，

因此，我们需要更加智能的方法。

在介绍下面这种方法前，继续做一些基础知识的科普。

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

其中，主线程主要负责：

合成线程则主要负责：

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

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

Frame Timing API 是 Web Performance Timing API 标准中的其中一位成员。

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

它包含许多子类 API，完成不同的功能，大致如下（摘自使用性能API快速分析web前端性能，当然你也可以看英文原版介绍：Web Performance Timing API ）：

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

在调试台 console 中打印 window.performance ，查看其中的 timing 属性：

这对象内一连串的变量表示什么呢，它表示我们页面整个加载过程中每一个重要的时间点，可以详细看看这张图：

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

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

获取 Render 主线程和合成线程的记录，每条记录包含的信息基本如下，代码示意，（参考至Developer feedback needed: Frame Timing API）：

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

或者是：