Using the Chrome web developer tools, Part 4: The Timeline Tab
Figure 2 shows a captured recording. Reproducing this is a bit tricky, because the timeline recorder runs until you turn it off; click the record button, immediately reload the page (use a keyboard shortcut like CTRL+R), and click it off quickly. As you can see, there's a lot of data produced in that subsecond response.
To reduce clutter, focus on the interesting part, and acquaint yourself a bit more with the
timeline interface, first uncheck the "Memory" checkbox along the top; I'll
come back to that view later on. Then, drag your mouse over the timeline
summary along the top, highlighting just the area with most of the colored
boxes, as shown in figure 3. This action focuses the detail view at the
bottom. Notice that I've omitted the two events to the far left. These
are the "Send Request" event that you see at the top of figure 2.
the browser sends the first
GET request and doesn't get a
response for about 150ms — not enough time to matter when you're loading
at a page, but quite a bit of blank space when you're looking at the events
that happened in 3/4 of a second.
If you click the "record" button again and move your mouse around in the window, you'll see (after turning the recording off) a sequence of scripting events like the display shown in figure 4. Since Chrome did work firing off the events — even though your page didn't intercept them — they're listed in the timeline view.
For efficiencies' sake, Chrome tries to go ahead and batch up events. Notice along the top of the detail view, there are a series of light-grey bars; each of these represents a batch of activities. If you hover over one, you can see how much time the batch took and how many events were processed within it as shown in figure 5.
This is a pretty boring page, though. Take a look at the (marginally) more interesting page in Example 2. Here the page includes a blue box that you can click and drag around with your mouse. If you run the timeline recorder and move the box around a little bit, you'll see a more interesting display like the one shown in figure 6, below.
Here I've zoomed in on the "action"; whenever the browser triggers a
mousemove (after the mouse has been captured via a mousedown),
left properties of the moveable
div, Chrome goes through a recalculate/update/paint loop to
change the display. Interestingly, if you click one of the
events, a new tab appears as shown in figure 7: Paint Profiler. If you're
familiar with the HTML5 canvas, this code should look somewhat familiar —
Chrome has an internal canvas-like interface that it uses to render objects
on screen; you can see all of the details of what it did to render the blue
square. If you hover over each line of the paint profiler, it will highlight
what, on the page, it painted using that line.
Depending on your computer, though, capturing this much detail may a) not be
needed and b) slow down the capturing process, so Chrome allows you to disable
the capture of the individual paint events and the invalidation causes using
paint checkboxes next to the
If you click on the
Recalculate Style event as shown in figure 8,
Chrome will additionally tell you exactly where in your source code the HTML
was "invalidated" (meaning that it needed to be redrawn); if you see a lot of
paint events that you can't seem to track down, this will take you right to
Another handy view on pages like this one that do a lot of dynamic "animation" is the frames view illustrated in figure 9. If you want your users to perceive a smooth animation, you should shoot for 60 frames per second — anything less than that will appear "jerky" to the user. This view breaks down your update/repaint events to illustrate how long each took.
Earlier, I unchecked the
memory checkbox to avoid cluttering up
the display. I've re-checked it in figure 10. Note that unchecking the
checkbox doesn't cause the memory events not to be kept track of, it just
removes them from the display. Unchecking the
on the other hand, causes the profiler to not capture them at all —
if you want to see the individual paint events, you'll have to recheck the
checkbox and run another recording.
The memory view keeps track of four individual sorts of memory allocations: Listeners, Nodes, Documents and "Used JS Heap". The first three are pretty self-explanatory — here, there's only one document (which won't necessarily be the case when you're dealing with multiple windows and iFrames), one to three listeners (one mousedown listener active at all times and the mousemove/mouseup handler active during a drag operation), and
Thus far, I've been suppressing the
memory tab to declutter the
display. However, realistically, you probably want to keep track of your
memory usage as well. If you load Example 3, you'll
see a contrived memory leak — every time you input two numbers and click
add, the sum is stored in a globally scoped array.
In figure 10, I've re-enabled the memory view and added a couple of numbers using example 3. Notice that the "used JS Heap" is growing. Now, all I can tell from the view is that it's growing — I can see on the timeline when it happened, but there are so many events in the events view that it's hard to see what the cause was. Chrome's timeline view has a robust filtering mechanism that allows you to zero in on what was causing the problem.
Here I can see that my JS heap size increases roughly every time line 17 is
invoked — which I can click through and see is my
Although the timeline view was sufficient to track down the source of this
very simple memory leak, most realistic page leaks are much more complex —
too complex for the timeline view to help you with. Normally you use the
timeline view to confirm that you have a memory leak, but you use the
profiler to actually track it down. I'll cover the profiler in
the next installment of this series, so stay tuned!