In the development of large-scale web applications or complex interactive websites, it is inevitable to encounter some page performance bottlenecks. This article describes how to use Chrome’s performance panel to analyze website performance bottlenecks, which should be helpful.
Note that in order to reduce the noise caused by some chrome plug-ins in performance evaluation, it is better to open the stealth mode access page for testing.
Switch chrome to stealth mode, and then open the page to test: https://googlechrome.github.io/devtools-samples/jank/
Analog mobile device
Compared with desktop computers and laptops, the CPU configuration of mobile devices is not so good, so we usually simulate mobile devices for testing
NetworkButton to switch the network to
Fast 3GAt this time, the network speed is normal 3G
CPU throttlingButton to set the CPU to
2x slowdownAt this time, the CPU runs 2 times slower than usual
Click “add 10” and the movement of the blue square will gradually slow down (on a high-end computer, it may take about 20 clicks)
Click “optimize” to trigger optimization, and the blue squares will move faster, and the page will obviously become smooth
Note: if you don’t see a significant difference between optimized and non optimized versions, try clicking “subtract10” a few times, and then try again. If you add too many blue squares, you’ll only make the CPU consume a lot of memory, and you won’t see a significant difference between the results of the two versions.
- Click “UN optimize” to cancel the optimization. The movement speed of the blue square will immediately slow down, and the page will obviously become stuck
Record runtime performance
When the page activates optimize, the blue squares move faster. Why is this? In fact, both versions should move each square in the same space at the same time. We can record in the performance panel to learn how to detect performance bottlenecks in an un optimized version.
- In devtools, clickrecordButton. As the page runs, devtools begins to capture performance metrics
- Wait more than ten seconds
- clickstop itButton, devtools stops logging, processes data, and displays the results on the performance panel
After recording the performance of the page, we can measure the performance of the page. We can analyze it
Frames per second
The main measure of any animation performance is frames per second (FPS). When the animation runs at 60 FPS, the page is at its most fluent state
- View the FPS chart. Whenever you see a red bar above the FPS, the frame rate drops so low that it may affect the user experience. Generally, the higher the green bar, the higher the FPS.
- Below the FPS chart is the corresponding color CPU chart in the CPU chart, and at the bottom of the performance board is the corresponding color summary tab. The fact that the CPU chart is full of colors means that the CPU is full during recording. Whenever you see the CPU working for a long time, you can find ways to reduce the workload.
- Hover over the FPS, CPU, or net diagram. Devtools will display a screenshot of the page at that point in time. Move the mouse left and right to replay the recording. This is called scrubbing and is useful for manually analyzing the progress of an animation.
- In the frames section, hover over the green square. Devtools will display the FPS for that particular frame, which may be well below the target of 60 FPS per frame.
Of course, through this demonstration, it is obvious that this page is not working well. However, it may not be clear which part has performance problems, so it is necessary to use the tool for accurate analysis and measurement.
Open the FPS dashboard
This paper introduces a FPS measuring instrument tool, which can provide real-time estimation of FPS when the page is running
Command+ Shift+ POpen command menu
- In the rendering tab, check the “FPS meter” button to call up the FPS panel on the page
Looking for performance bottlenecks
Knowing that the page performance is poor and getting the performance analysis chart, we need to further sequence the performance bottleneck:
- Pay attention to the followingSummaryTab. If no event is selected, this tab displays the score chart of the activity. From the picture, it is obvious that a lot of time has been spent on rendering. Since performance is the art of reducing workload, we have to find ways to reduce rendering time.
- Expand the * * main * * section to display the activity chart of the main thread over time
- The x-axis represents records over a period of time, and each bar represents an event. A wider bar indicates that the event took longer.
- The y-axis represents the call stack. If you see events superimposed on each other, it means that higher events lead to lower events
- The screenshots track records the data of each frame. Drag the mouse over the overview to zoom in on a single trigger animation event, which is part of the FPS, CPU, and net diagram. The main section and the summary tab display information only for the selected part of the record
Note: another debugging method is to use a key (select track sitting), D key (selecting track moving right), W key (narrowing selection area) and s key (increasing selection area) on keyboard
- Please note thatAnimation Frame FiredThe red triangle in the upper right corner of the event. Whenever you see a red triangle, you are warned that performance issues may be related to this event
Note: the trigger animation frame event occurs whenever a callback is executed
- single clickAnimation Frame Firedevent. The summary tab now shows you information about the event. Notice the link. Clicking this button causes devtools to highlight the event that started the animation frame fired event. And pay attention
app.js:94Source code link. Click to jump to the relevant line in the source code:
Note: after selecting an event, use the arrow keys to select the event next to it
app.updateUnder the incident, there is a bunch of purple events. If they are wider, it looks like there might be a red triangle on each object. Click the purple one
LayoutOne of the events, devtools provides more information about the event in the summary tab. Indeed, there is a warning about forced backflow (in other words, layout)
In the summary tab, click under forced layout
app.js:70Source link, devtools takes you to the mandatory layout of the code line
Note: the problem with this code is that it changes the style of each square in each animation frame and then queries the location of each square on the page. Because the style has changed, the browser does not know if the position of each square has changed, so you must rearrange the square to calculate its position. See avoid forced synchronous layouts
Analysis optimization version
Using the workflow and tools described above, we next click the optimize button on the page to switch to the optimized version. At this time, we call the disposable performance panel, and then analyze the results. We can see that the optimized version of the application does much less work, thus improving the performance of the page.
Note: even this “optimized” version is not so good because it can still manipulate the properties of each square in top. A better way is to stick to properties that only affect composition. For more information, see use transform and opacity changes for animations.
- Get Started With Analyzing Runtime Performance by Kayce Basques
This article is published by openwrite, a blog multi post platform!