Find the bottleneck

摘抄部分 Get Started With Analyzing Runtime Performance

Record runtime performance

When you ran the optimized version of the page, the blue squares move faster. Why is that? Both versions are supposed to move each square the same amount of space in the same amount of time. Take a recording in the Performance panel to learn how to detect the performance bottleneck in the un-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 on the Performance panel.

   
   

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

Analyze the results

Once you've got a recording of the page's performance, you can measure how poor the page's performance 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 are happy when animations run at 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 user experience. 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 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.

   
   image.png

3. 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.

   
   image.png

4. 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.

   
   image.png
   

   Of course, with this demo, it's pretty obvious that the page is not performing well. But in real scenarios, 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 the FPS meter, which provides real-time estimates for FPS as the page runs.

1. Press Command+Shift+P (Mac) or Control+Shift+P (Windows, Linux) to open the Command Menu.
2. Start typing Rendering in the Command Menu and select Show Rendering.
3. In the Rendering tab, enable FPS Meter. A new overlay appears in the top-right of your viewport.

4. Disable the FPS Meter and press Escape to close the Rendering tab. 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 question to answer is: why?

1. 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.

   
   
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 you see events stacked 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 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: Another way to zoom is to focus the Main section by clicking its background or selecting an event, and then press the W, A, S, and D keys.

4. 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.

Note: The Animation Frame Fired event occurs whenever a requestAnimationFrame()callback is executed.

5. 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:94 link. Clicking that jumps 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 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).
7. In the Summary tab, click the app.js:70 link under Layout Forced. DevTools takes you to the line of code that forced the layout.

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

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

Bonus: Analyze the optimized version

Using the workflows and tools that you just learned, click Optimize on the demo to enable the optimized code, take another performance recording, and then analyze the results. From the improved framerate to the reduction in events in the Main section's flame chart, you can see that the optimized 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. See Use transform and opacity changes for animationsfor more information.