Analyze runtime performance

Runtime performance is how your page performs when it is running, as opposed to loading. In terms of the RAIL model, the skills you learn in this tutorial are useful for analyzing the Response, Animation, and Idle phases of your page.

Tutorial with example

1. Open a new tab in incognito mode
2. Open https://googlechrome.github.io/devtools-samples/jank/
3. Open devtools

Simulate a mobile CPU

Whenever you profile a page, use CPU Throttling to simulate how your page performs on mobile devices.

1. Open the Performance tab
2. The screenshots checkbox is enabled
3. Click Capture Settings. devTools reveals settings related to how it captures performance metrics.
4. For CPU, select 2x slowdown

Set up the demo

It’s hard to create a runtime performance demo that works for all readers of this website. This section lets you customize the demo to ensure that your experience is relatively consistent with the screenshots and descriptions

1. Keep clicking Add 10 until the blue squares move noticeably slower than before.
2. Click Optimize. The blue squares should move faster and more smoothly
3. Click Un-Optimize. The blue squares move slower and with more jank again.

Record runtime performance

When you run the optimized version of the page, the blue squares move faster. Both versions are supposed to move each square to the same amount of space in the same amount of time.

1. In DevTools, click Record. Devtools captures performance metrics as the page runs
2. Wait for a few seconds
3. Click Stop. Devtools stops recording, processes the data, and then displays the results on the Performance panel.

Analyze the results

Analyze frames per second

The main metric for measuring the performance of any animation is frames per second (FPS). The preferred value is 60 FPS.

1. Look at the FPS chart. Whenever you see a red bar above FPS, it means that the framerate dropped so low that it’s probably harming the UX. In general, the higher the green bar, the higher the FPS
2. Below the FPS chart, you see the CPU chart. The colors in the CPU chart correspond to the colors in the Summary tab, at the bottom of the Performance panel. The fact that the CPU chart is full of colour means that the CPU was maxed out during the recording. Whenever the CPU maxes out for long periods, it’s a cue to find ways to do less work.
3. Hover the mouse over the FPS, CPU or NET charts. Devtools shows a screenshot of the page at the point in time. Move your mouse left and right to replay the recording. This is called scrubbing, and it’s useful for manually analyzing the progression of animations.
4. In the Frames section, hover the mouse over one of the green squares. Devtools shows you the FPS for that particular frame. Each frame is probably well below the target of 60FPS

FPS meter one of the another handy tool for analyzing

Code to check on optimized and unoptimized for a better understanding of why we are able to see vast differences between optimized and unoptimized screen and performance data.
DevTool-Samples

Find the bottleneck

Now that we have measured and verified that the animation is not performing well, the next question to answer is: why?

1. In the summary tab. When no events are selected, this shows you a breakdown of the activity. The page spent most of its rendering. Since performance is the art of doing less work, our goal is to reduce the amount of time spent doing rendering work.
2. Expand the Main section. DevTools shows you a flame chart of activity on the main thread, over time. The x-axis represents the recording, over time. Each bar represents an event. A wider bar means that the event took longer. The y-axis represents the call stack. When you see the events stacked on top of each other, it means the upper events caused the lower events.
3. Zoom in on a single Animation Frame Fired event by clicking, holding, and dragging the mouse over the overview, which is the section that includes the FPS, CPU and NET charts. The Main and Summary tabs only display information for the selected portion of the recording
4. Note the red triangle in the top-right of the Animated Fram Fired event. Whenever you see a red triangle, it’s a warning that there may be an issue related to this event.
5. Click the Animation Frame Fired event. The summary tab now shows you information about that event. Note the reveal link. Clicking that jumps you to the relevant line in the source code.
6. Under the app.update event, there are a bunch of purple events. If they were wider, it looks as though each one might have a red triangle on it.
7. In the summary tab, click the app.js link under Layout Forced.

References:

Performance devtool documentation

Performance feature Reference

Timeline event reference

CODE for example website