Web inspector profiling with "Frames": finding the cause of performance problems when nothing appears in the timeline

Question

I just watched the Google I/O session Jank Busters: Building Performant Web Apps where the speakers explained how to use the new "Frames" view in the Chrome web inspector Timeline.

Here's an example recording that I got when scrolling on a page I'm developing:

As you can see, there are huge delays in some of the frames but without any apparent cause in the timeline (there are large gaps in between the yellow "Timer Fired" events). How can I troubleshoot the performance problems in order to increase the frame rate consistently?

Answer 1

Your example actually doesn't look too bad. Your code runs fast, and the browser will only render at 60fps, so it spends a bit of time (up to 16ms) waiting around for the next render cycle.

Here's a particularly worrying snapshot from the Frames view of the Chrome Dev Tools Timeline panel.

According to the documentation:

• Grey areas indicate activity that was not instrumented by DevTools, and the Chrome team work to keep this area as small as possible
• Clear areas indicate idle time between display refresh cycles, which usually isn't a problem, especially if the area brings reaches up to the 60fps line, as this is just Chrome waiting to deliver a frame on the vsync of the monitor

The vanishingly small yellow and green regions at the bottom of the bars indicate that the event handling, painting and compositing all ran quite quickly -- fast enough to fall under the horizontal line indicating the 30fps threshold, and probably faster than the 60fps threshold most of the time (line not shown.)

To learn more, open the dev tools options and check:

With this enabled, you will see grey regions in the 'RECORDS' bar:

Each grey region shows a periods during which the renderer thread was occupied. If you see many gaps, then the browser was likely GPU-bound.

Nat Duca, an engineer on Chrome, provides more information in 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.

In my case (shown in the topmost picture) I'm still trying to find out what's causing the grey bars. The code hasn't changed, and performance used to be great. It may be that a newer build of Chrome (today I'm running 31.0.1650.57 m) doesn't perform as well with this code for some reason. Again, the grey areas indicate that the rendering thread was busy with uninstrumented code, so it's hard to tell what was going on.