过去几年来，浏览器在渲染性能方面取得了长足进步，尤其是在移动设备上。以前，您无法让任何稍微复杂的游戏达到流畅的帧速率，但现在，只要您小心谨慎，至少可以实现这一点。
不过，对于大多数人来说，我们在自己的设备上能够合理测试的内容与用户的体验之间存在脱节。如果他们无法获得流畅的 60fps 体验，那么他们的体验会受到影响，最终会转而使用其他平台，而我们也会受到影响。幸运的是，W3C 正在讨论一个新 API，它可以帮助我们了解用户看到的内容：Frame Timing API。
我和 Jake Archibald 最近录制了一段有关该 API 的视频概览，如果您更喜欢观看视频，请点击以下链接观看：
Frame Timing API 的用途
毫无疑问，您可以使用 Frame Timing API 执行许多操作，而且最重要的是，您可以衡量对您和您的项目而言重要的方面。尽管如此，以下几点建议或许有助于您：
- 跟踪 JavaScript 和 CSS 动画的帧速率。
- 跟踪网页滚动的流畅度（或您那款出色的无限滚动列表）。
- 根据设备的当前负载自动缩减您的舞台效果。
- 对运行时性能指标进行回归测试。
电梯间推销
以下是该 API 目前在规范中的样子：借助该 API，您可以提取有关渲染程序线程时间的数据，其中运行着 JavaScript、样式和布局。（您可能听说过渲染程序线程也称为主线程；这只是另一种说法。）
var rendererEvents = window.performance.getEntriesByType("renderer");
您收到的每个渲染程序线程记录大致如下所示：
{
sourceFrameNumber: 120,
startTime: 1342.549374253
cpuTime: 6.454313323
}
每个记录本质上都是一个对象，其中包含一个唯一的帧编号、一个表示帧开始时间的高分辨率时间戳，以及一个表示帧使用的 CPU 时间的值。有了这样的数组，您就可以查看每个 startTime 值，并确定主线程是否以 60fps 的速率运行；本质上就是“每个帧的 startTime 是否以大约 16 毫秒的块增加？”
除此之外，您还会收到 cpuTime，以便了解自己是否轻松达到 16 毫秒的边界，还是在最后时刻才达到。如果 cpuTime 接近 16 毫秒边界，则没有足够的空间来启动垃圾回收等操作，并且由于 CPU 使用率较高，电池用量也会增加。
除了渲染程序线程之外，您还可以拉取有关绘制和合成发生的 compositor 线程时间的数据：
var compositeThreadEvents = window.performance.getEntriesByType("composite");
每个事件还会返回一个源帧编号，您可以使用该编号来关联到主线程的事件：
{
sourceFrameNumber: 120,
startTime: 1352.343235321
}
由于合成在浏览器中的运作方式，每个渲染程序线程记录中都可能包含多个此类记录，因此您可以使用 sourceFrameNumber 将这些记录重新关联起来。还有一些人讨论这些记录中是否应包含 CPU 时间，因此，如果您有强烈的意见，请在 GitHub 问题中提出。
更多信息
此 API 尚未发布，但希望很快就能发布。在此期间，您可以阅读和执行以下操作：
- 阅读代码库中的说明文档。关于如何以最有效的方式记录帧数据，有很多细微之处，该说明文档提供了一些指导。
- 查看规范的最新草稿。该草稿内容非常简洁，值得一读。
- 针对缺失的功能或可能遇到的问题提交问题。您知道自己想要衡量什么，因此如果您认为自己无法使用该 API 执行某项操作，请提供反馈。