performance - 使用 "Frames": finding the cause of performance problems when nothing appears in the timeline 进行 Web 检查器分析

Question

我刚刚看了 Google I/O session Jank Busters: Building Performant Web Apps演讲者解释了如何在 Chrome 网络检查器时间轴中使用新的“框架” View 。

这是我在我正在开发的页面上滚动时获得的示例记录:



如您所见，某些帧存在巨大延迟，但时间线中没有任何明显原因(黄色“定时器触发”事件之间存在很大差距)。如何解决性能问题以持续提高帧率？

Answer 1

你的例子实际上看起来还不错。您的代码运行速度很快，并且浏览器只会以 60fps 的速度渲染，因此它会花费一些时间(最多 16 毫秒)等待下一个渲染周期。

这是来自 Chrome Dev Tools Timeline 面板的 Frames View 的一个特别令人担忧的快照。



根据documentation :

灰色区域表示 DevTools 未检测到的事件，Chrome 团队努力使该区域尽可能小

清晰区域表示显示刷新周期之间的空闲时间，这通常不是问题，特别是当该区域达到 60fps 线时，因为这只是 Chrome 等待在监视器的 vsync 上传送帧

条形底部的黄色和绿色小区域表明事件处理、绘制和合成都运行得非常快——快到足以落在指示 30fps 阈值的水平线下，并且可能比大多数情况下的 60fps 阈值快时间(线未显示。)

要了解更多信息，请打开开发工具选项并检查:



启用此功能后，您将在“记录”栏中看到灰色区域:



每个灰色区域显示渲染器线程被占用的时间段。如果您看到很多差距，那么浏览器很可能是 GPU 限制的。

Chrome 工程师 Nat Duca 在 this post 中提供了更多信息:

GPU boundedness typically comes from two things:

1. having -webkit-filter, preserves3D properties on elements. Those eat away at the gpu like... um, something hungry.
2. having too many big layers.

Layers? "Show composited layer borders" to see them. The place most folks get in trouble is not layer count really, but rather the area of the layers.

Rule of thumb: most computers are designed so that they can touch every pixel on its main screen about 4 times. As a really simple example, a 2-year-old MacBook Air is provisioned for its LCD's size. When you plug in a 30" monitor that has more than one layer, it starts getting GPU bound.

Why does this matter? [Handwaving,] a layer touches a pixel once when we draw the screen. If a layer is the size of your window, e.g. you've got a width=100% height=100% div with -webkit-transform: translateZ(0), then you're touching every pixel of the screen once. So, count up the the area of your layers and if you exceed 4 times the area of your monitor, you may not be able to go to space [because you're GPU bound].

A good test for gpu boundedness is to shrink the window size by 1/2 in each dimension. If things stay slow, then something else is happening... if things get faster, you were probably hitting the GPU.

就我而言(如最上面的图片所示)，我仍在尝试找出导致灰色条的原因。代码没有改变，性能曾经很棒。可能是由于某种原因，较新版本的 Chrome(今天我运行的是 31.0.1650.57 m)与此代码的性能不佳。同样，灰色区域表明渲染线程正忙于处理未检测的代码，因此很难判断发生了什么。