Chrome DevTools如何衡量互动的响应？

Question

我正在尝试衡量Chrome中用户感知的互动延迟。这是从按键到更新屏幕的时间。在这个例子中，我们用新内容重新渲染大部分屏幕。不涉及网络延迟，我们只是更新HTML。

在下面的屏幕截图中，您可以看到Chrome DevTools keydown事件，它运行了大量的javascript，然后是一堆绘画，合成等，然后keydown事件“响应”范围结束。

假设水平灰线是vsyncs（有人知道这些线是否记录在哪里？）Chrome在GPU上写了一个新渲染，从而显示屏幕，看起来像Devtools为keydown提供的“响应”范围事件是我正在尝试衡量的一个很好的近似值，因为它测量了从keydown到我们完成DOM变异后第一个灰线之后的时间。

我已经尝试了各种方法在javascript中使用requestAnimationFrame，requestIdleCallback，带消息传递的setImmediate polyfill以及上面的一些组合来近似这个时间。看起来所有这些都比纯Javascript时间长，但大多数时候他们低估或高估了实际更新屏幕的时间。

有谁知道在生产中测量这段时间的更好方法？ Chrome DevTools指标如何运作？我应该完全测量其他东西吗？

Answer 1

这些输入延迟事件的工具非常复杂和酷。这些都是很好的问题。

输入延迟事件结束时间

输入延迟事件在VSYNC周围结束，假设它们触发的工作导致需要屏幕更新的失效。这就是为什么在你的截图中，Key Down比Key Up延伸得更远。 （即使有keyup个侦听器，它们也没有使样式/布局无效）

肯定有一种早期的油漆和油漆。这些事件终止于的VSYNC，当屏幕因输入响应而更新时并非如此......但您必须自己进行该调用。

灰色虚线，vsync，交换缓冲区

灰色虚线是框架边界，但在这里开始变得棘手。在Chrome（和AFAIK，其他浏览器）中，还有主线程框架和合成器线程框架。 DevTools试图显示帧的单个时间轴以保持简单，因此它不是完美的。出于您的目的，我会查看Frames曲目中屏幕截图的右边缘。右边缘是屏幕使用这些内容更新的位置。在Chrome上，我们这次称呼swapBuffers。 （VSYNC在技术上是在显示器上写着“我准备好换一个新的画面”，这有点不同）

在JavaScript中测量

不幸的是，你没有完美的工具来解决这个问题。旧技术是双rAF，有时会减去一些时间。在这一点上，你肯定知道有一个新的框架。应用this knowledge中的一些，你可能会非常聪明。但它不会是完美的。例如，长图像解码会延迟合成器传送帧，但主线程现在处于空闲状态，VSYNC将使其开始一个全新的帧（从而再次调用rAF）。

Long Task API可以提供帮助，因为它描述了主线程上需要花费一些时间的工作。但我认为它不具备回答这些问题所需的那种精确度。 Frame Timing会有，但由于隐私原因而死亡。

<强> TDLR：

使用timestamp from the input event，就像在合成器收到输入时一样。然后使用一些单rAF，双rAF机制，减去一些时间，以估计框架何时发货。当你拥有自己喜欢的东西时，就大声欢呼;我很感兴趣。