Timeline, which was originally called “Timeline” before Chrome 57, has now been given a longer name, “Performance,” which is better known as “long ～～～～～～～～～.”
Maybe you’ve accidentally launched the tool and been as giddy as I was when you saw the colorful charts inside. But after introducing it today, I’m sure you’ll know it like a Swiss Army knife.
The panel is called “Performance,” though the name doesn’t specify what it is. Since it is a Chrome debugging tool, it should be related to the page, we will start from the page performance chat.
What affects your page performance
In recent years, WEB developers have come up with a number of solutions to shorten user wait times. For example, using PWA to cache more available offline resources and make web applications open faster; Use the WebAssembly specification to reduce resource size and improve execution efficiency. These programs focus on network links, front-end resource processing speed and other dimensions, to improve user experience.
As a WEB developer, I feel that page performance is deeply linked to several dimensions: network links, server resources, front-end resource rendering efficiency, client hardware.
The network link
Network links are often the focal point of page performance. Domain name resolution, switches, routers, ISPs, content distribution networks, servers, and nodes on the link that have problems or are too slow to respond can all have a bad experience.
Server resources
In the context of HTTP, all requests are ultimately handled by the server. Improper processing of the server dad cannot respond or slow response will directly affect the interaction between the page and the user.
Front-end resource rendering
The process of obtaining static resources, such as HTML, CSS, scripts, and images, and rendering the first screen for users. Or the process by which the browser recalculates what needs to be rendered after the user interacts with the page, and then redraws it. The processing efficiency of these processes is also an important factor affecting performance.
The user hardware
Initiate network request, parse network response, page rendering and other processes need to consume computer hardware resources. So computer resources, especially when CPU and GPU resources are scarce (such as video card killer games), can also affect page performance.
Of course, the above dimensions are not ruled by lines, they are more of a cross – tooth relationship. For example, the browser is slow to respond during rendering, it could be a poorly scripted performance bottleneck, or it could be a graphics killer game that takes up too much computer resources; For example, in the analysis of front-end resource rendering, the network waterfall diagram is often used to analyze the acquisition time of resources, because the rendering page is also a dynamic process, some key resources need to wait, and some can be loaded at the same time of rendering.
Why sacrifice Performance
Chrome’s developer tools have their own focus, such as the Waterfall graph of the Network tool, which has detailed information about the pull order of resources, and its focus is on analyzing Network links. The Performance tool focuses on the front-end rendering process. It has modules such as frame rate bar chart, CPU usage area chart, resource waterfall chart, main path flame chart, event overview, etc. These modules are closely related to rendering and can be used to see the entire rendering phase clearly. You don’t have to worry about the module names mentioned above, though, because I’ll cover them all in the pages that follow.
Start Performance with correct posture
Open the Performance
First, we open the Chrome anonymous window. In the anonymous environment, the browser does not have additional plug-ins, user features, caches, and other factors that affect the repeatability of the experiment. If your window is wide enough, you can see Performance in column 5 of the top TAB bar. If you are not wide enough, you can find it by clicking on more tabs from the >> button on the top right.
This is the default boot page for Performance. The operation corresponding to the first prompt is to immediately start recording all events occurring on the current page, and the recording will be stopped only after clicking the stop button. The tool will automatically stop recording when the page has finished loading and is in an interactive state. Both will eventually generate a report (generating a report takes a lot of computation and some time).
Now the tools are ready to analyze the page.
Simple page analysis
First we analyze the process of a simple page from blank to rendered. All of the sample pages in this article are in the following repository, cloned by command and switched to the repository root:
git clone [email protected]:pobusama/chrome-preformance-use-demo.git && cd chrome-preformance-use-demo
Next, install the dependency package: NPM I
Finally, launch the sample page: NPM Run Demo1
Since it is difficult to know when the page will start rendering, we collect rendering data using a second reload method, logging the process beforeunload -> unload -> Send Request -> load.
After the tool stopped recording automatically, we got a report like this:
The four areas delineated in the figure are:
1: Control panel, used to control tool features. Network and CPU: limit Network and computing resources respectively, and simulate different terminal environments to easily observe performance bottlenecks. The “Disable JavaScript samples” option turned on will cause the tool to ignore the call stack for logging JS, which we’ll cover later. Enabling “Enable Advanced Paint Instrumentation” will record the details of some render events, which we will talk about later.
2: Overview panel, which has 3 charts describing frame rate (FPS), CPU usage and network resources. Frame rate is a measure of how many frames are rendered per second. The higher the frame rate, the smoother the look and feel. The network is presented in the form of a waterfall diagram, in which you can observe the loading time and sequence of resources. The CPU usage area chart is actually a continuous stacked bar chart (the enlarged version of the CPU area chart below is a schematic diagram, the data is not strictly corresponding) :
The vertical axis is CPU usage, the horizontal axis is time, different colors represent different event types, where:
- Blue: Loading event
- Yellow: Scripting events
- Purple: Rendering events
- Green: Painting the event
- Gray: Other (Other)
- Idle: The browser is idle
For example, in the first column of the diagram, the total CPU usage is 18, with load events (blue) and script calculation events (yellow) evenly split (9). As time goes by, the CPU usage of script calculation events increases gradually, while the CPU usage of load events decreases to 0 at about 600ms. On the other hand, the use of render events (purple) rose first and then fell, dropping to 0 around 1100ms. The whole graph clearly shows what events occupy what percentage of CPU usage at which time.
3: Thread panel, used to observe details of events, in the overview panel zoom out to see details of the thread diagram. The main thread flame chart is used to analyze the rendering performance of the main chart. Unlike the “normal” flame chart, the flame chart shown here is inverted, meaning that the top layer is the parent function or application, the call stack gets shallower as you go down, and the bottom cell (which looks like a vertical line if the time dimension is not stretched long enough) represents the top layer of the function call stack.
By default, the flame chart records each level of function (down to the granularity of a single function) in the call stack of executed JS programs, in great detail. With Disable JS Samples enabled, the flame diagram will only be accurate to the event level (calling a function in a JS file is an event) and all JS function call stacks under that event will be ignored.
In addition, Frames and Network waterfalls allow you to view the page and resource loads drawn from the time dimension, respectively.
4: Details panel. The incident has been mentioned many times before, I think if I don’t explain, I may be sent razor blades. The most fine-grained record of all in the Performance tool is the event. The event here does not refer to the event in JS, but an abstract concept. We open the main thread flame chart, click a square at will, you can see the details of the event in the details panel, including the event name, event time, initiator and other information. Parse HTML is a Loading event (blue), which indicates that Chrome is executing its HTML parsing algorithm during the event time; An Event is a Scripting Event (yellow) that indicates that a JS Event (such as Click) is being executed; Paint is a draw event (green) that means Chrome will draw the resultant layer.
Here are some common events, just to give you an idea, and since we have to deal with them every time we do performance analysis, it’s hard not to remember them.
A very important part of the detail panel is the event time pie chart, which lists the proportion and time consumed by different types of events (loading, scripting, rendering, drawing, other events, daze 🙂 in the time period you select. Analyzing the elapsed time ratio has the same implications as analyzing the CPU area graph — which events are consuming a lot of computing power and time, causing performance bottlenecks.
So far, we’ve gone over the main features of the Performance tool, not all of them, but enough to start the Performance analysis journey. Let’s take a look at a slightly more complex animated page to really understand how to use this chart data to locate performance issues.
Talk a little bit about the browser rendering process
Knowing how the browser renders is important for our understanding and analysis, here’s a quick look at how the browser renders:
When rendering the first screen, the browser parses the HTML and CSS files to generate a document Object Model (DOM) and a style sheet object model (CSSOM). Combine DOM and CSSOM into Render Tree; Compute Style; Calculate the exact position and Layout of each node on the screen. Draw the render tree on the layer as calculated in the previous step (Paint). The rendering engine composes all Layers to make them visible to the human eye.
If you change the layout of the page, you update the DOM with JS and then go through the process of calculating the style and compositing the image. If only non-geometric changes (color, visibility, transform), you can skip the layout step.
Animation analysis
With all the above preparations, you’re ready to start. We run another Demo under the sample repository: CD Chrome-preformance -use- Demo && NPM run Demo2
Initially, the 10 cubes will move up and down at a constant speed, hitting the browser boundary and backtracking. “Add 10” adds 10 of these cubes, “Substract 10” reduces 10, “Stop/Start” pauses/starts all the cubes, “Optimize/Unoptimize” optimizes/unoptimizes the animation.
How does a browser animate a frame
By default, we click on the circle in the upper left to record events, and a few seconds later we can click on Stop in Performance to generate analysis data. In the overview panel, we can see that after the first few hundred milliseconds, the proportion of events in the CPU area graph changes at a fixed period. We can click on a small segment and observe it. In the main thread graph, we can see a similar group of events. 10 Recalculate Style + Layout loops -> Update Layer Tree -> Paint -> Composite Layers As we know, after the Composite Layers event, it means that the human eye can see the new page layer, that is, after such a group of events, a frame is drawn in front of the eyes.
We click “Framse” in the upper column of the main thread flame diagram and find that the dashed line shortly after the Composite Layers event is the node appearing in the next frame, which confirms the above conclusion.
When the bottleneck appears
So far, the animation looks fine. Click the “Add 10” button 20 times to increase the number of squares, and you can see a noticeable lag in the animation. If you don’t feel the lag, your computer is beating 99% of the users in the country (or, uh… You may have to go to the hospital for an eye check), at which point you can reduce CPU power in the control panel. Ok, let’s record the performance data again:
We see a lot of bold red in the report, including the big red bars on the frame rate chart and the small corner markers on the main thread chart.
The Recalculate Style and Layout events that occur in the app.update function are both warned that the performance bottleneck may be caused by a forced rearrangement. If you go into the JS file and look at the detailed code, you can see lines of code that are consuming a lot of time in dark yellow in the left column, then these lines are most likely the problem.
Note: Automatically calculating the line of code runtime requires unchecking the “Disable JavaScript Samples” option for the control panel.
So, what’s wrong with this line of code, and what’s the rearrangement?
Rearrangement and redrawing
In short, reflow and Repaint are steps that change the style of a page. The rearrangement step includes render events such as Recalculate Style, Layout, Update Layer Tree, and the redraw step includes Paint and Composite Layers. A rearrangement necessarily causes a redraw, and an operation that causes a redraw does not necessarily cause a rearrangement. Some of the common operations that cause rearrangements or redraws are listed below. See CSSTRiggers for more
Because it takes a lot of time to calculate the layout, rearrangement is much more expensive than redrawing, and we need to avoid rearrangement as much as possible to achieve the same effect. For example, if display: None and Visibility: Hidden both work, the latter is preferable.
To solve the bottleneck
Looking back at our animation Demo, in the detail panel of Performance, the pie chart shows the proportion of rendering (rearrangement) in the animation drawing process. Combined with the code, we find the reason: Several times in the loop, the DOM position is fetched offsetTop as soon as the style position is updated to the DOM. Such an operation forces a rearrangement, because the browser does not know if the DOM position changed in the last loop and must be rearranged immediately to calculate the DOM position. Not so fast, as you may have noticed, we also have an “Optimize” button.
To solve this problem, our optimization solution is to replace offsetTop with style.top. Although the latter takes the element position of the last animation frame, it does not affect the calculation of the next animation frame position, thus eliminating the process of rearranging the position and reducing unnecessary rearrangement.
Note: In this example, there’s one other optimization that was done with non-optimize, which is pass
requestAnimationFrameThe function converts all style changes within a frame loop (
m.style.top = pos + 'px';) accumulated in the next drawing unified processing. In addition to optimizing style writes, this gives us a clearer look at the offsetTop read problem.
Let’s compare the reports before and after optimization:
First, from pie and CPU area charts, Rendering events accounted for a decrease, while Painting events accounted for an increase. As can be seen from the frame rate and frames thread graphs, the frame rate increases significantly and the drawing time of a frame decreases significantly, which means the animation smoothness is greatly improved and the optimization goal has been achieved. When we look at the details, we find that in the event group that draws a frame of animation, the Recalculate style and Layout events are not included in the app.update function, so the execution time of the whole function is significantly reduced, which proves that our optimization scheme works.
Review and notes
In this discussion of Performance tools, we start with the factors that affect page Performance and then lead to the dimension in which Performance tools excel – front-end resource rendering. Next, we looked at the four main panels of the Performance tool: Control, Preview, Threads, details, and several useful charts: frame rate bar chart, CPU area chart, main thread flame chart, frame thread timing chart, and event time pie chart. They were then used to locate and solve a performance problem.
However, Performance problems in the real environment are more complex. While skillfully using Performance, we need to keep the factors that affect Performance in mind. This part of knowledge and experience need to be accumulated in the actual combat for a long time. Improving WEB Performance is an interesting topic, and there are many excellent blogs on the Google WEB Developer site that discuss it, but there is no magic in the browser, so have fun with Performance
reference
Get Started With Analyzing Runtime Performance
Rendering Tools
Render Tree Construction
Avoid Forced Synchronous Layouts
How to read a fire map? – Ruan Yifeng’s web log
Web page performance management details – Ruan Yifeng’s web log