Performance is a Performance monitoring tool provided by Chrome. According to my usage, the simple understanding is that we can record browser activity for a period of time through it, and analyze whether there is room for improvement through the data of the activity. To capture activity data for a page, the first step is to record browser activity.

Recording, the beginning of analysis

Open F12, enter the Perfomance TAB, and we can see the prompt appear. We don’t want to look at the text in what to say, we just want to start with (not), because I have baidu translation (not, read it), so the text prompt is in the place of arrow, solid round on behalf of the recording, and refresh icon has said that it can help you to refresh and recorded the whole process from click page refresh to page load. When we want to see the first screen load speed, we can click on the refresh icon, and when we want to do whatever we want, we can use the record button represented by the solid circle.

So the next question is what to record, and I know your answer: “Record anything and see.” But a quick recording will probably just give you an idea of what’s on the Performance panel, which gets boring pretty quickly. According to one of my methodologies, finding or creating a page with a Performance problem and using Performance to look at the Performance bottleneck can help us understand.

Fortunately, I found such a demo in the introduction to Performance on the official website. The demo requires a scientific website to access, but I was lucky enough to read the Performance index of one of my friends, who had demo2 in his warehouse as the official old demo (and it worked just as well).

  1. Run projects or open web pages in Chrome incognito mode, as extensions affect performance evaluations
  2. The page shows a bunch of little blue squares moving up and down, with buttons like Add 10 squares, Remove 10 squares, Stop moving (start moving), Optimize (unoptimize), and Help
  3. Open F12 and switch to the Performance TAB

Before the official recording, we know that we are in the STATE of PC, and the CPU of mobile phones is usually not as powerful as that of PC. If we want to evaluate the performance of mobile phones, the CPU of PC will get better results and affect the performance judgment. The Perfomance panel provides network speed and CPU limits so that we can simulate the state of the phone. The gear shape in the image below can expand the network, CPU and other Settings. In order to simulate the animation lag faster, the CPU can be set to 4x slow.

With the setup done, it’s time to record

  1. Click the Add button repeatedly until the page feels a bit stuck
  2. Click the Record button to record a period of time
  3. Click the optimization button, the naked eye can see that the blue block moves more silky, continue recording for a period of time and then stop recording
  4. Wait for a performance evaluation error to be generated

Below is the report we generated

Read the report, the second step of analysis

  1. In the whole panel, the area where 1 and 2 merge is the overview panel, 3 is the threads panel, and the pie chart details panel is at the bottom
  2. The blue part is the performance evaluation data before optimization, and the pink part is the performance evaluation data after optimization
  3. The area where the number 1 is is the FPS data before and after optimization. The higher the FPS, the smoother the picture.
  4. A large number of red color blocks appeared in the blue area 1, indicating that during this period of running time, frame loss was obvious, and the redder the color was, the more serious it was. However, the absence of red color blocks in the pink area proved that no frame loss occurred.
  5. The height of the green block in area 1 represents the current frame number, and we can see that the green block in area pink 1 is higher than the green block in area blue 1.
  6. The number 2 is in the area of CPU usage and how it is used. Different colors represent different activities that are processed. We can see from the pie chart at the bottom: yellow (executing JS), purple (rendering), green (drawing to page) and other colors.
  7. The area where the number 3 is located is the specific activity of each browser process. Here we focus on the Main thread

The Compositor thread is responsible for composing the main thread’s submitted Painting list. This part is related to how the browser works. Here is a brief overview.

Next, we need to look at the specific evaluation data for a certain period of time. We can use the mouse wheel or click or drag the overview panel to look at a specific period of time. In order to see where the performance problems occurred before optimization, I reduced the Overview panel to a size where only three tasks were performed.

The individual task is called from top to bottom. Anemotion Frame Fired calls Function Call and Function Call app.update. We Call the diagram 🔥 when Main expands, but the flame is downward. As the call stack gets deeper and deeper, each task gets smaller and smaller, resulting in an inverted flame shape that is wide at the top and narrow at the bottom.

Keep narrowing down until we see only one task executing.

In the panel, we can click a color block to view the details. Following the footprint of the call stack, we find the Js color block located at the top of the flameapp.updateSee the details of the blue area in the figure, which shows that it took 23ms to execute its own Js rendering, and 24ms to rendering the next Js call, which can be seen in the figureapp.updateThe color block has an infinite number of little purple squares, and waiting for the execution of those little purple squares lengthens the entire Js execution time.

Adjust the scope of your view until you see specific tasks optimized.

We can see that the optimized panel app. Update all the purple color piece small squares have disappeared, while purple small squares is related to the layout of activity, see here we can lock optimization are present in the js code before change the layout of the operation, there is no doubt that the little blue square, will inevitably lead to the change of the layout, and before and after optimization, What is it that causes the layout calculation to be repeated while JS is being executed before optimization, and then only once after JS is executed and the page is updated? Looks like we need to get to the code level and continue our investigation.

Let’s look at the differences between the two by going into the specific code in the following steps

  1. Adjust the scope of view in the Overview panel until you can click to see the details of a task
  2. Click on theapp.updateColor piece
  3. Click the corresponding Function in the details panel to enter the relevant code

Analyze performance bottlenecks and optimize code

App. The update is a blue square location update code, using the window. The requestAnimationFrame represented in the process of execution animation needs to redraw the page calls when, this method is to perform the animation timer used to replace the commonly used means of optimization, This prevents us from executing animation-related code when the browser is not updating the page.

In this screen, we can see that in addition to the number of lines of code on the far right, we can also see how long it takes the code to execute a particular line. The darker the yellow, the longer the execution time. It can be seen that the biggest difference in the execution time before and after optimization lies in the two lines of code surrounded by the red box. In these two lines of code, the top line indicates setting the current top value of the blue box to achieve the effect of moving the blue box. The next line of code determines whether the blue square has hit the top after setting the top value to determine whether the next movement direction is up or down.

After the optimized code changed the position of the blue square, it immediately re-used offsetTop to get the position of the current small square. In this case, the browser had to rearrange the page to get the position of the current blue square, which is called forced synchronous layout. Fetching offsetTop over and over in the loop causes layout jitter, which is the large number of small purple layout squares we saw earlier under the app.update color block. Using style.top, which fetches the top value in the element’s style attribute, and pos, which is the cached top variable, does not trigger a synchronous layout.

Talk about rearranging and redrawing

In the previous code optimization, we recognized the performance bottleneck caused by forced synchronous layout. However, both before and after optimization, due to the change of the location information of the elements, the browser will perform a complete rendering pipeline, and the complete rendering pipeline is roughly shown below. From performing Js -> Generating styles -> Computing layout -> Drawing -> Composition -> Display, we call the action of performing the completion pipeline rearrangement.

Some Js styles do not change geometry, such as transparency, background color, etc. At this point, the computational layout on the rendering pipeline is not executed, a rendering process we call redrawing. Redrawing is more efficient than arranging because it reduces the operation of calculating the layout. But in this case, changing geometry is necessary, and we cannot optimize performance by redrawing. Is there another way? Yes, using CSS animations can help us further optimize performance.

CSS animation, synthesis of wit

Using CSS’s Transform animation, some animations that do not trigger geometry changes can skip Js execution, style generation, layout calculation, and drawing altogether and go straight to composition. The compositing phase is performed in the compositing thread and does not block the main thread, so we sometimes find that the animation is still running even though the web page is stuck.

The transform animation can be divided into a separate layer, which you can think of as a layer in Photoshop, and the animation of this layer will be taken over by the compositing thread. The animation of each frame of this layer will be compositing into the main layer, and the effect of the animation is complete. This is why using CSS for animation is the best choice.

We can use will-change to tell the browser that this part of the content needs to be mentioned in a separate layer, and the browser will handle this part of the transformation through the composite thread. But every coin has two sides. Using will-change too many layers creates too much memory for the browser, so we need to use will-change appropriately. The following code tells us that browsing the Box class requires geometry and transparency changes.

.box {
	will-change: transform, opacity;
}
Copy the code

conclusion

  1. Before recording with Performance, use stealth mode and configure the correct network and CPU to simulate the environment
  2. Record for a while and stop
  3. In the overview panel, focus on the long mission, which is marked with a red triangle at the end
  4. Follow the call stack of the flame chart and the pie chart of the detail panel to find possible performance bottlenecks
  5. Go into the Js code to check the execution time and try to optimize