Get started analyzing runtime performance

Runtime performance is how your page performs when it's running, as opposed to loading. The following tutorial teaches you how to use the DevTools Performance tool to analyze runtime performance.

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.

See also Optimize website speed using Lighthouse.

Get started

In the following tutorial, you open DevTools on a "Sluggish Animation" demo page and use the Performance tool to find a performance bottleneck on the page.

1. Open the Sluggish Animation demo page in your InPrivate tab or window. To do that, right-click the link and then select Open link in InPrivate window. You'll profile this page, which shows a variable number of icons moving up and down. For more information about InPrivate, see Browse InPrivate in Microsoft Edge

   Note: The source for this demo is at MicrosoftEdge / Demos > devtools-performance-get-started.

2. Press Ctrl+Shift+I (Windows, Linux) or Command+Option+I (macOS) to open DevTools.

   

For the rest of the following screenshots, DevTools is undocked to a separate window, to better focus on the contents.

Simulate a mobile CPU

Mobile devices have much less CPU power than desktops and laptops. Whenever you profile a page, use CPU Throttling to simulate how your page performs on mobile devices.

1. In DevTools, open the Performance tool.

2. Select the Screenshots checkbox.

3. Click Capture settings (). DevTools reveals settings related to how it captures performance metrics.

4. For CPU, select 4x slowdown. DevTools throttles your CPU so that it's 4 times slower than usual.

   

   If you want to ensure that pages work well on low-end mobile devices, set CPU to 6x slowdown. The demo doesn't work well with 6x slowdown, so it just uses 4x slowdown for instructional purposes.

Set up the demo

The following section lets you customize the demo to make sure that your experience is relatively consistent with the screenshots and descriptions.

1. Click the Add 10 button until the blue icons move noticeably slower than before. On a high-end machine, you can click it about 20 times.

2. Click Optimize. The blue icons should move faster and more smoothly.

3. To better display a difference between the optimized and non-optimized versions, click the Subtract 10 button a few times and try again. If you add too many blue icons, you could max out the CPU, and then you might not observe a major difference in the results for the two versions.

4. Click Un-Optimize. The blue icons move slower and with more sluggishness again.

Record runtime performance

When you ran the optimized version of the page, the blue icons move faster. Why is that? Both versions are supposed to move the icons the same amount of space in the same amount of time. Take a recording in the Performance tool to learn how to detect the performance bottleneck in the non-optimized version.

1. In DevTools, click Record (). DevTools captures performance metrics as the page runs.

   

2. Wait a few seconds.

3. Click Stop. DevTools stops recording, processes the data, then displays the results in the Performance tool.

   

These performance results show an overwhelming amount of data, but it will all make more sense shortly.

Analyze the results

Once you have a recording of the page's performance, you can assess the page's performance and find the cause of any performance issues.

1. The CPU chart is displayed along the top. The colors in the CPU chart correspond to the colors in the Summary panel, at the bottom of the Performance tool. The CPU chart shows that these regions make up a large area, meaning that the CPU was maxed out during the recording. Whenever the CPU is maxed out for long periods, that's an indicator that the page is not performing well.

   

2. Hover over the 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. The action is called scrubbing, and it's useful for manually analyzing the progression of the performance recording.

   

Bonus: Open the Frame Rendering Stats overlay

Another handy tool is the Frame Rendering Stats overlay, which provides real-time estimates for FPS as the page runs. The Frame Rendering Stats overlay is not required for this tutorial but may provide helpful insight.

1. In DevTools, press Ctrl+Shift+P (Windows, Linux) or Command+Shift+P (macOS) to open the Command Menu.

2. Start typing Rendering in the Command Menu and click Show Rendering.

3. In the Rendering tool, turn on Frame Rendering Stats. A new overlay appears in the top-left of your webpage.

   

4. When you are done reviewing the FPS data, clear the Frame Rendering Stats checkbox to hide the overlay.

Find the bottleneck

After you verified that the animation isn't performing well, the next step is to answer the question "why?"

1. When no events are selected, the Summary panel shows you a breakdown of activity. The page spent most of the time rendering. Since performance is the art of doing less work, your 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 event took longer. The y-axis represents the call stack. When events are stacked on top of each other, it means the upper events caused the lower events.

   

3. There is a lot of data in the recording. To zoom into a portion of the recording, click and drag in the Overview area toward the top of the Performance tool. The Overview area includes the CPU and NET charts (indicated on the right). The Main section and Summary panel only display information for the selected portion of the recording.

   

   Another way to change the selected area is to put focus on the Main section, click the background or an event, and then press:

   • W to zoom in, S to zoom out.
   • A to move selection left, D to move selection right.

4. Select an Animation Frame Fired event. When a red triangle is displayed at the top right of an event, it's a warning that there might be an issue related to the event.

   The Animation Frame Fired event occurs whenever a requestAnimationFrame() callback is run.

5. Click the Animation Frame Fired event. The Summary panel now shows you information about that event. Note the Reveal link. After you click it, DevTools highlights the event that initiated the Animation Frame Fired event. Also, focus on the app.js:96 link. After you click it, the relevant line in the source code is displayed.

   

   After clicking an event, use the arrow keys to select the events next to it.

6. Under the app.update event, there's a bunch of purple events, and they each have a red triangle.

7. Click one of the purple Layout events. DevTools provides more information about the event in the Summary panel. There is a warning about forced reflows (another word for layout).

8. In the Summary panel, click the app.js:72 link under Layout Forced. DevTools takes you to the line of code that forced the layout.

   

   The problem with the non-optimized code is that, in each animation frame, it changes the style for each icon, and then queries the position of each icon on the page. Because the styles changed, the browser doesn't know if each icon position changed, so it has to re-layout the icon in order to compute the new position.

This article gives you a lot to learn. But now you have a solid foundation in the basic workflow for analyzing runtime performance. Good job.

Analyze the optimized version

Using the workflows and tools that you just learned, click Optimize on the demo to turn on the optimized code, take another performance recording, and then analyze the results. From the improved framerate to the reduction in events in the flame chart in the Main section, the optimized version of the app does much less work, resulting in better performance.

The optimized code uses a different sequence of actions to do less work. Note that this code could be made even faster by only using properties that only affect compositing, instead of manipulating the top property of every icon.

Next steps

To get more comfortable with the Performance tool, practice makes perfect. Try profiling your pages and analyzing the results. If you have any questions about your results, use the Send Feedback icon, press Alt+Shift+I (Windows, Linux) or Option+Shift+I (macOS), or file an issue on the MicrosoftEdge / DevTools repo. Include screenshots or links to reproducible pages, if possible.

Last, there are many ways to improve runtime performance. This article focused on one particular animation bottleneck to give you a focused tour of the Performance tool, but it's only one of many bottlenecks you may encounter.

Note

Portions of this page are modifications based on work created and shared by Google and used according to terms described in the Creative Commons Attribution 4.0 International License. The original page is found here and is authored by Kayce Basques (Technical Writer, Chrome DevTools & Lighthouse).

This work is licensed under a Creative Commons Attribution 4.0 International License.