Front-end performance monitoring, Runtime Performance Debug skills

Author: Mo Liquan, Kyle Mo
Translator: Front-end Xiaozhi Source: medium

When it comes to web front-end performance optimization, there are many techniques that focus on how to reduce the "Loading Time" of the page, such as Code Splitting to speed up the loading performance by reducing the Bundle Size that needs to be loaded. There are also some techniques for optimization and tuning of the execution time (Runtime), such as Virtualized List by controlling the number of rendered DOM elements to maintain the fluency of the page, or the time spent in rendering processes such as Repaint, Reflow, and Composite of the page. , but how to debug these runtime indicators? What kind of situation also represents some bottlenecks in the performance of the page? Animation occupies a very important part in today's web pages, so how to observe the performance of animation?

Today, I would like to share with you how to use the Performance Tab of Chrome Devtool to detect various performance indicators of web pages during execution, so that the Runtime Performance of web pages will no longer be a bottleneck when you debug!

Basic introduction to Chrome Devtool Performance Tab

Readers who have used the Chrome Devtool Performance Tab may have been as intimidated by the rich charts and complex information as I have been, and have no idea where to start. It is true that Chrome's Performance Tab provides quite a wealth of information. It is almost an impossible task to organize it thoroughly in one article, so today I will only introduce the most basic information and charts, but I think it is enough to face the ordinary Debug requirements. So without further ado, let's get started!

Start Debug

First open an incognito window and visit this website . The reason for using an incognito window is to ensure that chrome is running under “clean state” , otherwise the performance measurement results may be affected by other running applications such as extensions , resulting in an inaccurate situation.

Then type Command+Option+I (Mac) or Control+Shift+I (Windows, Linux) on the keyboard to open Devtool and click Performance Tab.

There will be two buttons (red frame blocks) in the upper left corner. Click the first one to start recording. At this time, you can start to operate the webpage. Devtool will record the usage of CPU, memory, Frame Rate, etc. when operating the webpage. Indicators, this method is suitable for monitoring some specific behaviors and functions on the page.

The second button "Start profiling and reload page" will start profiling and reload the page, and automatically stop profiling when the browser thinks the page interaction is over.

Because I want to detect page animations that are manually triggered by the user, the first method is more suitable. In addition, if your website also needs a mobile version, generally speaking, the performance of some Mobile Devices will be relatively poor. In order to check whether the Mobile Devices applied in the low-level can also operate smoothly, you can select the CPU option (the orange area in the figure). block) and adjust the performance of the CPU, here I choose 6x slower to simulate the operation on a lower performance device. After clicking start detection, operate the function you want to detect, click stop profiling, and Devtool will display the profiling results after a period of time.

Analyze the results of Profiling!

Let's break it down step by step, first take a look at the chart area that records FPS, CPU, NET.

FPS

When it comes to measuring the performance of web animations, the most intuitive way is to observe FPS (Frame Per Second), which is often heard of Frame Rate. When performing animation, it is hoped that the Frame Rate can reach about 60 FPS, so that the animation that the user sees is not easy to cause stuttering. (Sometimes a low FPS is not necessarily bad, it may also be that the page really has no movement)

In the FPS column of the above picture, you can see the bar composed of pink and red, which means that the page may have dropped frames, which will cause the page animation to be uneven or even freeze, which will seriously affect the user experience. To be avoided as much as possible.

CPU

As you can see from the above graph, the CPU graph is periodic, with some sections appearing to be very active, and the first sections appearing to be almost inactive. The mouse hovers on FPS, CPU, and NET to see the complete Screenshot of the profiling process. This technique is also called scrubbing , which allows us to track page animations in a progressive manner.

From the above Screenshot, it can be seen that the time between the user's click to rearrange the trigger animation and the completion of the animation will increase the CPU usage.

The CPU chart has many different colors, which represent different kinds of work. If you want to understand more easily and unify the chart of the specified time period, you can see the unified chart under the Performance Tab. The correspondence is the same as the CPU section above.

• Gray (System) - work inside the browser (see this stackoverflow question for which tasks are categorized here)
• White (Idle)—Idle Time
• Yellow (Scripting) — execute JavaScript and event handling
• Green (Painting) - image processing, screen drawing
• Purple (Rendering) - the style calculation of the page
• Blue (Loading) - loading and processing HTML (since I start profiling after the page is loaded, this stage is not shown)

If you find that the CPU of your web page is kept maxed out for a long time (it looks like a lot of work to be done in the graph), you should pay attention to whether there is a chance to use Code Refactor or remove unnecessary functions. Lighten the workload of the CPU.

Of course, it doesn't mean that the CPU is running for a long time. For example, asana's official website has some animations that will reincarnate indefinitely.

In this way, the CPU is bound to have to deal with some work all the time. If the demand is like this, it is not necessarily bad.

However, it can be seen that the situation of dropped frames is quite serious, and the execution of JavaScript occupies most of the time of the CPU. At this time, we can take a step forward and think about how to improve the problem of dropped frames, or whether the animation can be achieved with CSS as much as possible. The same effect (because CSS architecture animations are usually handled by a separate thread from the browser's "main thread", see this article for details).

Next see the More Details section in the middle section of the Performance Tab. Because my demo site shows too little information here, I choose to use the asana official website just mentioned to explain this block, and because of space, I will only mention a few indicators that I think are often used - Memory , Frames, Timing, Main, Network, Experience.

Memory

Click the Memory option in the red block, and the memory usage of the web page during this profiling period will be displayed below. For example, by observing the change in the usage of the blue JS Heap, we can roughly observe whether the web page has a memory leak problem, and we can also know that Presumably what operations are causing the memory usage to skyrocket.

The trash can in the orange block can force the browser to do GC (Garbage Collection), because GC is uncontrollable in JavaScript, so it is difficult to find out the situation that may cause Memory Leak just by looking at the code. By forcing GC, we can observe the difference in memory usage before and after executing a function. For example, after a function is executed, GC is forced. If the memory usage is still at a high point or even getting higher, it may be the situation of Memory Leak.

If you observe that GC is triggered frequently, don't be too happy. Although it may solve the problem of Memory Leak, it also means that the memory usage of the website is a bit too much. GC has a feature called "Stop The World". Because GC is also executed in the Main Thread, too frequent may lead to bottlenecks in website performance.

Frames

The Frames Section in the middle block shows the Screenshot of each UI update in the page, and each UI update can be called a "frame". When the UI is stuck for a long time and cannot be updated, it is called a "long frame".

Click on one of the frames displayed in Frames, and the summary tab below will display the detailed information of the frame, including Duration, FPS and CPU Time.

If you click the Screenshot in the summary, you can also browse the captured frames step by step in chronological order.

Timing

Timing Section can see the timeline of some important indicators of web page loading performance, these indicators are:

• DCL (DOM Content Loaded) : The point in time when HTML is loaded and parsing is completed.
• FP (First Paint) : The time when any pixel (pixel) is drawn to the page by the browser, such as the background color of the page.
• FCP (First Contentful Paint) : Chinese for "First Contentful Paint". After the viewer arrives at the website, the time it takes to display the content of the website for the first time also refers to the time when the browser displays text or pictures for the first time. Test the reason for the first display When the website is displayed again for the second time, the browser already has a cache file, so it will not be so accurate.
• LCP (Largest Contentful Paint): It calculates the loading time of the largest component in the viewport of the web page, that is, the time when the main content of the page is seen by the user, and is an indicator of speed.
• L (onload) : Represents the point in time when all requested resources are loaded after parsing HTML

The Total Blocking Time (TBT) will also be displayed at the bottom of the Performance Tab, which represents the total time that the browser Main Thread is blocked during the Profiling process. Of course, we hope that this time can be as short as possible.

Experience

From Experience, you can see where Layout Shift occurs, which is the CLS that everyone cares about in Core Web Vital.

Network

Display the time spent grabbing each resource and the dependencies between resources in order. If you click on any resource, you can see more detailed information in the summary tab below, such as URL, Duration, Priority, Mime Type, Encoded Data Size, Decoded Body size.

However, I usually use Devtool's Network Tab directly when debugging networking-related resources, and the overall information is more detailed and intuitive.

Main (CPU Flame Chart)

The Main Section presents the CPU task of the Main Thread, and it is presented in the form of an inverted flame chart, which means that the function or task below is triggered by the task of the upper layer. We can use this to track The dependencies and triggering relationships of each task and function.

If a red triangle appears in the upper right corner of the Task, it means that it is a long task, and it is also a warning that there may be some problems here that cause the task to execute for too long.

After clicking the task with the red triangle, the detailed information as shown above will appear. Sometimes it will point out the location of the task in the code, so that we can debug and find potential problems faster. For example, we click the content.js :

It will directly switch to the Sources Tab and display the corresponding line number, which is very convenient for Debug.

Sometimes you will find that in addition to Main, there are other Frames and Workers. These Frames do not refer to Frames that can observe FPS just mentioned, but refer to embedded iframes in web pages, and Worker refers to Web Workers, etc. Threads other than Main Thread, Performance Tab can even debug these, which is really amazing.

some regrets

Due to the space, there is actually a lot of rich information on the Performance Tab that has not been introduced, such as Layer-related information, Advanced Paint Instrumentation, and Call Tree, Bottom-Up, etc. under the Summary Tab, which can observe CPU activities in a finer-grained manner It is recommended that readers who are interested and in need can study it by themselves.

So, how much impact does website animation have on performance after refactoring?

After understanding the basic operation mode of Performance Tab, let's go back and look at the analysis status of the website used for Demo in Performance Tab.

It can be seen that the frame will be seriously dropped when the animation is triggered, and the workload of the CPU will also become very large. The main things to do are Rendering (purple) and Painting (green), and Idle (white) is not much time. , which may cause the user's input behavior that cannot be handled.

According to the method just introduced, you can also further look at the tasks marked as long tasks in the Main Section , and find that most of the time is spent on painting , and the time spent is very long. According to the standard of RAIL Model , such time spends It will make the user feel that the page is stuck, and even the event browser triggered by the user interaction will not be able to handle it in time, and the user experience is very bad.

At this point, it can be roughly determined that this version of the animation has a big problem. Now that the problem is determined, let's take a look at the animation code.

It is found that this code directly changes the element top to achieve the animation, which will cause the page to recalculate the Layout through Reflow every time. But we should have a better way to achieve the same animation effect, so I tried to change the code to the following:

And use the will-change CSS property on the transform:

Then we directly perform Performance Profiling on the new version of the website:

It can be found that the frame rate and CPU usage have been optimized a lot. From the summary tab, you can also find that the same time is about one second. The idle time of the new version of the web page has increased, which means that it has a better chance to process the user's input and avoid using it. The user feels that the entire website is unresponsive.

Although there are still some frame drops after the revision, it should be improved further, but it has improved a lot compared to the previous version.

Through this simple example, readers should know how to debug when they encounter problems such as unsmooth pages or freezes in the future, and know how to compare whether there is a real improvement after correcting the writing method.

Example address: https://github.com/kylemocode/it-ironman-2021/tree/master/css-transform-demo

Summarize

Today's websites rely on and value the scores calculated by performance testing tools like Lighthouse, but I have encountered a situation where the Lighthouse Performance score is a perfect score, but it is obviously stuck and not smooth when using it. This means that we cannot fully trust and rely on these scores. When users experience poor performance experience, the debugging of Runtime Performance becomes very important. Although I only introduced the fur today, I hope this article can make you no longer be deterred by the dazzling Dashboard when you need to use the Performance Tab in the future, and you can clearly know how to find the bottleneck of the problem.

The bugs that may exist after the code is deployed cannot be known in real time. In order to solve these bugs afterwards, a lot of time is spent on log debugging. By the way, I recommend a useful bug monitoring tool , Fundebug .

Original: https://medium.com/starbugs/%E8%A%AB%E7%82%BA%E5%89%8D%E7%AB%AF%E9%96%8B%E7%99%BC%E8 %80%85-%E4%BD%A0%E4%B8%8D%E8%83%BD%E4%B8%8D%E7%9F%A5%E9%81%93%E7%9A%84-runtime- performance-debug-%E6%8A%80%E5%B7%A7-4f0efd27b86d

comminicate

If you have dreams and dry goods, you can search for [Great Move to the World] on WeChat and pay attention to this Shawanzhi who is still washing dishes in the early hours of the morning.

This article GitHub https://github.com/qq449245884/xiaozhi has been included, there are complete test sites, materials and my series of articles for interviews with first-line manufacturers.