Note: SeeOptimize Website Speed to learn how make your pages load faster.

Runtime performance is how your page performs when it is running, as opposed to loading. Thistutorial teaches you how to use the Chrome DevTools Performance panel to analyze runtimeperformance. In terms of theRAIL model, the skills you learn in this tutorial are useful foranalyzing the Response, Animation, and Idle phases of your page.

Caution: This tutorial is based on Chrome 129. If you use another version of Chrome, the UI andfeatures of DevTools may be different. Checkchrome://help to see what version of Chrome you'rerunning.

Get started

In this tutorial, we will use thePerformance panel to find a performance bottleneck on a live page. To begin:

1. Open Google Chrome inIncognito Mode. Incognito Mode ensures that Chrome runs in a cleanstate. For example, if you have a lot of extensions installed, those extensions might createnoise in your performance measurements.

2. Load the following page in your Incognito window. This is the demo that you're going to profile.The page shows a bunch of little blue squares moving up and down.

   https://googlechrome.github.io/devtools-samples/jank/

3. PressCommand+Option+I (Mac) orControl+Shift+I (Windows, Linux) to open DevTools.

   

   Note: For the rest of the screenshots, DevTools isundocked to a separate window sothat you can see its contents better.

Simulate a mobile CPU

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

1. In DevTools, click thePerformance tab.
2. Make sure that theScreenshotscheck_box checkbox is enabled.
3. ClickCapture Settingssettings.DevTools reveals settings related to how it captures performance metrics.

4. ForCPU, select4x slowdown. DevTools throttles your CPU so that it's 4 times slowerthan usual.

   

   Note: When testing other pages, if you want to ensure that they work well on low-end mobiledevices, set CPU Throttling to20x slowdown. This demo doesn't work well with 20x slowdown,so it just uses 4x slowdown for instructional purposes.

Set up the demo

It's hard to create a runtime performance demo that works consistently for all readers of thiswebsite. This section lets you customize the demo to ensure that your experience is relativelyconsistent with the screenshots and descriptions you see in this tutorial, regardless of yourparticular setup.

1. Keep clickingAdd 10 until the blue squares move noticeably slower than before. On ahigh-end machine, it may take about 20 clicks.

2. ClickOptimize. The blue squares should move faster and more smoothly.

   Note: If you don't see a noticeable difference between the optimized and un-optimizedversions, try clickingSubtract 10 a few times and trying again. If you add too many bluesquares, you're just going to max out the CPU and you're not going to see a major difference inthe results for the two versions.

3. ClickUn-Optimize. The blue squares move slower and with more jank again.

Record runtime performance

When you ran the optimized version of the page, the blue squares move faster. Why is that? Bothversions are supposed to move each square the same amount of space in the same amount of time. Takea recording in thePerformance panel to learn how to detect the performance bottleneck in theun-optimized version.

1. In DevTools, clickRecordradio_button_checked. DevTools capturesperformance metrics as the page runs.

   

2. Wait a few seconds.

3. ClickStop. DevTools stops recording, processes the data, then displays the results in thePerformance panel.

   

Wow, that's an overwhelming amount of data. Don't worry, it'll make more sense shortly.

Analyze the results

Once you have a performance recording, you can analyze just how poor the page'sperformance is, and find the cause(s).

Analyze frames per second

The main metric for measuring the performance of any animation is frames per second (FPS). Users arehappy when animations run at 60 FPS.

1. Look at theFPS chart. Whenever you see a red bar aboveFPS, it means that the frameratedropped so low that it's probably harming the user experience.

   

2. Below theFPS chart you see theCPU chart. The colors in theCPU chart correspond tothe colors in theSummary tab, at the bottom of thePerformance panel. The fact that theCPU chart is full of color means that the CPU was maxed out during the recording. Wheneveryou see the CPU maxed out for long periods, it's a cue to find ways to do less work.

   

3. Hover your mouse over theFPS,CPU, orNET charts. DevTools shows a screenshot ofthe page at that point in time. Move your mouse left and right to replay the recording. This iscalled scrubbing, and it's useful for manually analyzing the progression of animations.

   

4. In theFrames section, hover your mouse over one of the green squares. DevTools shows youthe FPS for that particular frame. Each frame is probably well below the target of 60 FPS.

   

Of course, with this demo, it's pretty obvious that the page is not performing well. But in realscenarios, it may not be so clear, so having all of these tools to make measurements comes in handy.

Bonus: Open the FPS meter

Another handy tool is theFPS meter, which provides real-time estimates for FPS as the page runs.

1. PressCommand+Shift+P (Mac) orControl+Shift+P (Windows, Linux) to open the Command Menu.
2. Start typingRendering in the Command Menu and selectShow Rendering.

3. In theRendering panel, enableShow Rendering stats. A new overlay appears in the top-right of yourviewport.

   

4. Disable theFPS Meter and pressEscape to close theRendering panel. You won't be using it in this tutorial.

Find the bottleneck

Now that you've measured and verified that the animation is not performing well, the next questionto answer is: why?

1. Note theSummary 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, yourgoal is to reduce the amount of time spent doing rendering work.

   

2. Expand theMain 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 widerbar means that event took longer. The y-axis represents the call stack. When you see eventsstacked on top of each other, it means the upper events caused the lower events.

   

3. There's a lot of data in the recording. Zoom in on a singleAnimation Frame Fired event byclicking, holding, and dragging your mouse over theOverview, which is the section thatincludes theFPS,CPU, andNET charts. TheMain section andSummary tab onlydisplay information for the selected portion of the recording.

   

   Tip: You can also useWASD to navigate the recording. Focus theMain section by clicking its background orselecting an event, then pressW to zoom in,S to zoom out,A to scroll left, orD to scroll right.

4. Note the red triangle in the top-right of theTask and layout events. Whenever you seea red triangle, it's a warning that there may be an issue related to this event. A red triangle on aTask means that it was along task.

5. Click theAnimation Frame Fired event. TheSummary tab now shows you information aboutthat event. Clicking the link next toInitiated by causes DevTools to highlight the event thatinitiated theAnimation Frame Fired event. Also note theapp.update @ link. Clicking thatjumps you to the relevant line in the source code.

   

   Note: After selecting an event, use the arrow keys to select the events next to it.

6. Under theapp.update event, there's a bunch of purple events. If they were wider, it looksas though each one might have a red triangle on it. Click one of the purpleLayout eventsnow. DevTools provides more information about the event in theSummary tab. Indeed, there'sa warning about forced reflows (another word for layout).

7. In theSummary tab, click the link next toapp.update @ underAnimation Frame Requested. DevTools takes youto the line of code that forced the layout.

   

   Note: The problem with this code is that, in each animation frame, it changes the style foreach square, and then queries the position of each square on the page. Because the styleschanged, the browser doesn't know if each square's position changed, so it has to re-layout thesquare in order to compute its position. SeeAvoid forced synchronous layouts to learnmore.

Phew! That was a lot to take in, but you now have a solid foundation in the basic workflow foranalyzing runtime performance. Good job.

Bonus: Analyze the optimized version

Using the workflows and tools that you just learned, clickOptimize on the demo to enable theoptimized code, take another performance recording, and then analyze the results. From the improvedframerate to the reduction in events in theMain section's flame chart, you can see that theoptimized version of the app does much less work, resulting in better performance.

Note: Even this optimized version isn't that great, because it still manipulates thetopproperty of each square. A better approach is to stick to properties that only affect compositing.SeeUse transform and opacity changes for animations for more information.

Next steps

The foundation for understanding performance is the RAIL model. This model teaches you theperformance metrics that are most important to your users. SeeMeasure Performance With The RAILModel to learn more.

To get more comfortable with the Performance panel, practice makes perfect. Try profiling your ownpages and analyzing the results. If you have any questions about your results,open a StackOverflow question tagged withgoogle-chrome-devtools. Include screenshots or links toreproducible pages, if possible.

To become an expert in 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 theRendering PerformanceOverview.The Anatomy Of A Frame dives into even more detail.

Last, there are many ways to improve runtime performance. This tutorial focused on one particularanimation bottleneck to give you a focused tour through the Performance panel, but it's only one ofmany bottlenecks you may encounter. The rest of the Rendering Performance series has a lot of goodtips for improving various aspects of runtime performance, such as:

• Optimizing JS Execution
• Reduce The Scope And Complexity Of Style Calculations
• Avoid Large, Complex Layouts And Layout Thrashing
• Simplify Paint Complexity And Reduce Paint Areas
• Stick To Compositor-Only Properties And Manage Layer Count
• Debounce Your Input Handlers