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.
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.
Open Microsoft Edge in InPrivate Mode. InPrivate Mode ensures that Microsoft Edge runs in a clean state. For example, if you have a lot of extensions installed, the extensions may create noise in your performance measurements.
Load the following "Sluggish Animation" demo page in your InPrivate window. You'll profile this page, which shows a variable number of icons moving up and down.
I(Windows, Linux) or
I(macOS) to open DevTools.
For the rest of the screenshots below, 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.
In DevTools, open the Performance tool.
Select the checkbox next to Screenshots.
Click Capture settings (). DevTools reveals settings related to how it captures performance metrics.
For CPU, select 4x slowdown. DevTools throttles your CPU so that it is 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.
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.
Click Optimize. The blue icons should move faster and more smoothly.
To better display a difference between the optimized and un-optimized versions, click the Subtract 10 button a few times and try again. If you add too many blue icons, you might max out the CPU, and then you might not observe a major difference in the results for the two versions.
Click Un-Optimize. The blue icons move slower and with more sluggishness again.
Record runtime performance
When you run the optimized version of the page, the blue icons move faster. Why is that? Take a recording in the Performance tool to learn how to detect the performance bottleneck in the un-optimized version.
In DevTools, click Record (). DevTools captures performance metrics as the page runs.
Wait a few seconds.
Click Stop. DevTools stops recording, processes the data, then displays the results in the Performance tool.
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.
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.
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.
In DevTools, press
P(Windows, Linux) or
P(macOS) to open the Command Menu.
Renderingin the Command Menu and click Show Rendering.
In the Rendering tool, turn on Frame Rendering Stats. A new overlay appears in the top-left of your webpage.
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?"
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.
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.
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:
Wto zoom in,
Sto zoom out.
Ato move selection left,
Dto move selection right.
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.
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.
Under the app.update event, there's a bunch of purple events, and they each have a red triangle.
Click one of the purple Layout events. DevTools provides more information about the event in the Summary panel. Indeed, there is a warning about forced reflows (another word for layout).
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 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.
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.
Even the optimized version isn't great, because it manipulates the
top property of every icon. A better approach is to stick to properties that only affect compositing.
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
I (Windows, Linux) or
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.
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.
Submit and view feedback for