Chrome DevTools如何测量交互响应时间？

Question

我正在尝试测量Chrome中交互的用户感知延迟。这是从按键到屏幕更新的时间。在此示例中，我们使用新内容重新渲染了屏幕的大部分区域。没有涉及网络延迟，我们只是更新HTML。

在下面的屏幕截图中，您可以看到Chrome DevTools按键事件，它运行了许多JavaScript，然后有一堆绘画、合成等等，然后按键事件的“响应”跨度结束。

假设水平灰线是垂直同步（是否有人知道这些线在哪里有记录？）Chrome将新渲染写入GPU并因此在屏幕上显示，那么Devtools为按键事件提供的“响应”跨度似乎是我要测量的很好的近似值，因为它测量了从按键按下到我们完成DOM突变后的第一条灰线之后的时间。

我已经尝试了各种方法来近似javascript中的时间，包括requestAnimationFrame、requestIdleCallback、带有消息传递的setImmediate polyfill以及上述几种组合。似乎它们都比纯JavaScript时间长，但它们大多低估或高估实际更新屏幕的时间。

有没有更好的方法来衡量生产中的时间？Chrome DevTools指标是如何工作的？我应该完全测量其他内容吗？

- Conrad Irwin

---

据我所知，这是不可能的。请参见https://crbug.com/694075。 - wOxxOm

谢谢提供链接！我仍然有兴趣看看是否可以解决这个问题，偏移量为+/- 16毫秒（即使现在可以忽略此问题）。 - Conrad Irwin

Answer 1

这些Input Latency事件的仪器非常复杂和酷炫。这些是很好的问题。

输入延迟事件在VSYNC左右结束，假设它们触发的工作导致了一个无效化，需要屏幕更新。这就是为什么在您的截图中，KeyDown比KeyUp延伸得多。（即使有keyup侦听器，它们也没有使样式/布局无效）

当然，可能存在更早的绘制和VSYNC，这些事件在那里终止，并不是响应于输入时屏幕更新的时间...但这取决于你自己的判断。

灰色虚线、垂直同步、交换缓冲区。

灰色虚线是帧边界，但这里开始变得棘手。在Chrome（以及我所知道的其他浏览器）中，有主线程帧和合成器线程帧。DevTools试图显示一条帧时间线以保持简单，因此它不能完美地显示。对于您的目的，我建议查看该Frames轨道截图的右侧边缘。右侧边缘是屏幕更新这些内容的位置。在Chrome上，我们称这个时间为swapBuffers。（VSYNC技术上是监视器说“我准备好了一个新帧”，这略有不同） 在JavaScript中测量这个 不幸的是，您没有完美的工具来完成这项工作。旧技术是双rAF，有时减去一些时间。此时，您肯定知道已经有一个新帧。应用this knowledge的一些知识，您可能会非常聪明。但它不会完美。例如，长图像解码将延迟合成器发送帧，但是主线程现在处于空闲状态，VSYNC将导致它开始全新的帧（从而再次调用rAF）。

长时间任务 API 可以帮助我们描述主线程中正在进行的耗时工作类型。但我认为它没有我们回答这些问题所需的精度。Frame Timing 可以，但由于隐私原因而消失了。 TDLR: 使用 输入事件的时间戳，因为它是在合成器接收到输入时获取的。然后使用单个 rAF、双个 rAF 机制，减去一定的时间，来近似确定帧被传输的时间。当你有满意的结果时，请告诉我；我很感兴趣。

- Paul Irish

---

谢谢Paul！我们最终测量了单个rAF和双重rAF，但还没有想好如何将两者结合起来。会让你知道的。顺便说一下，VSYNC的事情很有趣，因为我有一个外部显示器，只能以30Hz运行，结果是外部显示器上的所有内容都变慢了约16ms！ - Conrad Irwin