How to Analyze Runtime Performance: Google DevTools
RAIL performance monitoring continued.
Runtime performance is how your page performs when it is running, as opposed to loading. Chrome DevTools are ideal for analyzing your site for the Response, Animation, and Idle times of your RAIL model performance. If you do not know what RAIL is, I recommend checkout my previous article before moving forward.
Now that you understand what RAIL is, let’s dive in!
First things first is learning how to use you DevTools’ Performance panel. We will use this panel to identify performance bottlenecks on any webpage.
Google docs provide us with an handy demo webpage for using the performance feature in DevTools. Let’s open that up in Chrome in Incognito Mode. This will allows us to have a clean slate with things like cookies that might slow our site down, but not be the main performance issue. Now let’s open up DevTools (Mac: Command+Option+I or Windows/Linux: Control+Shift+I )You should see something like the following:
This is the site that we will be profiling with DevTools Performance panel.
What is profiling?
Profiling tools are used on running code to identify which processes are taking the most time. Profiling tools are usually only used once a a performance problem has been identified in the system — if the server is taking a long time to respond, and you can’t identify any resource problem (e.g. lack of memory or poorly configured garbage connection), profiling might be your next choice of strategy.
Back to the demo
As discussed in my previous article on RAIL, different devices have differing CPU power which effects a website’s performance on that device. Because of the lower CPU power of a mobile device, we have to simulate the page we are profiling at a lower CPU with something called CPU Throttling.
What is CPU Throttling?
Essentially, CPU Throttling is slowing down the processing speed of your computer. Also known as, dynamic frequency scaling, it adjusts the clock speed of the CPU. It is commonly used to automatically slow down the computer when possible to use less energy and conserve battery, especially in laptops. CPU throttling can also be adjusted manually to make the system quieter, because the fan can then run slower.
So, let’s throttle our demo. In DevTools:
- Click the Performance tab.
- Make sure that the Screenshots checkbox is enabled.
- Click Capture Settings (the settings icon to the right under the exit button). DevTools will reveal settings related to how it captures performance metrics.
- For CPU, select 4x slowdown. DevTools throttles your CPU so that it’s 2 times slower than usual.
Now that our demo is throttled, we can see the performance degradation as we add blue squares to the page. When we optimize the page, the blue blocks run smoothly, but when un-optimize it, you can the blocks start moving slower and jankier. We can now start monitoring the demo’s performance to identify the performance bottleneck slowing everything down.
Recording Runtime Performance
In the upper left hand corner of the Performance tab of DevTools, click the “Record” circle to begin tracking the demo’s performance metrics.
Wait a few seconds for the tracker to capture some data. Next, click stop. DevTools will stop recording, process the data, then it will display the results on the Performance panel. Let’s take a look at the results.
Analyzing the Data
Now that we have all the data, we can pinpoint the causes of the performance slowdown on our demo.
Analyze frames per second
The main metric for measuring the performance of any animation is frames per second (FPS). As I covered in my previous article on RAIL, users are happy when animations run at 60 FPS.
- Look at the FPS chart. Whenever you see a red bar above FPS, it means that the frame-rate dropped so low that it’s probably harming the user experience. In general, the higher the green bar, the higher the FPS.
- 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 color means that the CPU was maxed out during the recording. Whenever you see the CPU maxed out for long periods, it’s a cue to find ways to do less work.
- Hover your mouse over the FPS, CPU, or NET charts. DevTools shows a screenshot of the page at that 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.
What is scrubbing?
Scrubbing refers to manually scrolling through an animation, forward and backward, previewing your animation in order to check, correct or add frames to your animation.
- In the Frames section, hover your 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 60 FPS.
Open the FPS meter
Another handy tool is the FPS meter, which provides real-time estimates for FPS as the page runs.
- Press Command+Shift+P (Mac) or Control+Shift+P (Windows, Linux) to open the Command Menu.
- Start typing
Renderingin the Command Menu and select Show Rendering.
- In the Rendering tab, enable FPS Meter. A new overlay appears in the top-right of your viewport.
Finding the bottleneck
Now that you’ve measured and verified that the animation is not performing well, the next question to answer is: why?
- Note the summary tab. When no events are selected, this tab shows you a breakdown of activity. The page spent most of its time rendering. Since performance is the art of doing less work, your goal is to reduce the amount of time spent doing rendering work.
- 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 event took longer. The y-axis represents the call stack. When you see events stacked on top of each other, it means the upper events caused the lower events.
- There’s a lot of data in the recording. Zoom in on a single Animation Frame Fired event by clicking, holding, and dragging your mouse over the Overview, which is the section that includes the FPS, CPU, and NET charts. The Main section and Summary tab only display information for the selected portion of the recording.
- Note the red triangle in the top-right of the Animation Frame Fired event. Whenever you see a red triangle, it’s a warning that there may be an issue related to this event.
- Click the Animation Frame Fired event. The Summary tab now shows you information about that event. Note the reveal link. Clicking that causes DevTools to highlight the event that initiated the Animation Frame Fired event. Also note the app.js:95 link. Clicking that jumps you to the relevant line in the source code.
- Under the app.update event, there’s a bunch of purple events. If they were wider, it looks as though each one might have a red triangle on it. Click one of the purple Layout events now. DevTools provides more information about the event in the Summary tab. Indeed, there’s a warning about forced reflows (another word for layout).
- In the Summary tab, click the app.js:71 link under Layout Forced. DevTools takes you to the line of code that forced the layout.
The foundation for understanding performance is the RAIL model. This model teaches you the performance metrics that are most important to your users. See Measure Performance With The RAIL Model to learn more.
As with anything, to get more comfortable with the Performance panel, practice makes perfect. Try profiling your own pages and analyzing the results. If you have any questions about your results, utilize the knowledge of the internet and open a Stack Overflow question tagged with
google-chrome-devtools. Include screenshots or links to reproducible pages, if possible.
To really master runtime performance, you’ve got to learn how the browser translates HTML, CSS, and JS into pixels on a screen. The best place to start is the Rendering Performance Overview. The Anatomy Of A Frame dives into even more detail.
Last, there are many ways to improve runtime performance. This tutorial focused on one particular animation bottleneck to give you a focused tour through the Performance panel, but it’s only one of many bottlenecks you may encounter. There are several other aspects of runtime performance. Check out the following links to get good tips on improving runtime performance on every level: