DevUI is a team with both design and engineering perspectives, serving huawei DevCloud platform and huawei internal background systems, as well as designers and front-end engineers. Add devui Helper (Devui-Official) DevUIHelper plugin: Devuihelper-lsp (welcome Star)
The introduction
Performance is an issue.
Every project that grows to a certain size is almost bound to encounter performance problems, and when we do, we are:
A face meng force, know very card, very slow, do not know why
or
Quickly identify performance bottlenecks and find effective optimization solutions
It depends on how well we understand performance and whether we have a good set of tools and methods.
I’m going to share with you the three steps I often use to locate business performance problems, which I’ve summed up in one sentence for your convenience:
Bake pancakes over a flame under a waterfall
Don’t say more words, drink saliva directly open masturbation!
Performance Panel overview
Before introducing the three-step method, take a look at the Performance panel of Chrome Developer Tools and the basic components of a Performance analysis report.
Generate a performance analysis report
Take the DevUI team’s gold Digger homepage as an example. Visit it using Chrome: juejin.cn/user/712139…
Then press F12 to open Chrome developer Tools and select the Performance panel.
Here’s a simple guide:
There are two buttons in the guide, the top button is manual recording, the bottom button is automatic recording, we click the idiot automatic recording, automatic recording will automatically refresh the page, after the page loading is complete, generate the page performance analysis report, without manual intervention, very convenient.
Wait for a few seconds to generate a report, a look, colorful, do not know from where to look?
Composition of a performance report
Let’s do a simple panel classification of the generated performance analysis report and it becomes clear.
The toolbar
At the top of the performance report is a toolbar (or control panel) with a bunch of buttons. The ones I use most are the first three, the first two of which are described in the guide, and the third for clearing the report.
There are also two hidden features that are useful, one that simulates slow Internet speeds and another that simulates slow CPUS, which may be used to optimize performance for mobile applications.
The overview panel
Below the toolbar is an overview panel that shows the Frames Per Second (FPS) of the entire page loading process, which is used to assess the smoothness of the page, with large red patches indicating that the page may be stuck.
Below FPS is the amount of time the CPU takes to process each task, below is the amount of time the network request takes, and at the bottom of the overview panel is a screenshot of each frame.
Thread panel
Below the overview panel is the threads panel. By default, the network request waterfall is expanded. Details for other threads are folded.
Each thread panel is valuable for performance analysis, and the waterfall and fire charts I use most often are the ones I’ll focus on later and how to use them to analyze performance bottlenecks on your site.
Memory panel
Further down is the Memory panel, which needs to be opened manually in the control panel and is a categorized memory usage line chart.
Each polyline is the memory footprint of a task over time:
- JS stack
- The document
- HTML node
- Event listeners
- GPU memory
Details panel
At the bottom is the details panel. The first thing you see is a pie chart that shows the percentage of each type of task. This is very useful to see at a glance what type of task is a performance bottleneck.
Is it resource loading or script execution? Is it page rendering or image rendering? Or too much free time?
Step 1: Look at the pie chart
When introducing the composition of the Performance panel, three useful Performance analysis tools were mentioned, namely the detail pie chart, request waterfall chart, and main thread flame chart.
Let me summarize these three pictures in one sentence:
Bake pancakes over a flame under a waterfall
This sentence is also my own performance analysis and optimization, the tried-and-true tips.
The pie chart in the details panel shows the time consumption of various types of tasks.
There are mainly the following tasks:
- Blue is resource loading
- Yellow is script execution
- Purple is for page rendering
- Green is graphic drawing
- White is free time
So let’s take that example.
As you can see from the pie chart, script execution and idle account for the largest proportion.
The script takes a Long time to execute, so we can probably guess that there may be Long tasks in it.
The idle ratio may be due to waiting too long for the server to respond.
Pie charts are a quick way to form a basic judgment, while specific reasons need to be analyzed for waterfall and fire charts.
Step 2: Look at the waterfall
Let’s take a look at the request waterfall. The waterfall and the fire are both part of the thread panel. The horizontal axis of the waterfall is the time axis, and there are many colorful blocks on the waterfall.
- Blue is the HTML file
- Purple is the CSS file
- Yellow is JavaScript files
- Green is the picture
- Gray is the background interface
We focus on long color blocks, which mean time consuming and can be a performance bottleneck.
Take a look at the waterfall on the Nuggets’ homepage.
Summarize the characteristics of waterfall diagram
We first observe what the characteristics of this graph, graph observation ability, I believe that we have been cultivated in primary school, roughly we can sum up the following obvious characteristics:
- Feature 1: The waterfall is divided into three smaller waterfalls
- Feature 2: Most of the waterfall on the left is yellow, most of the waterfall in the middle is gray, and most of the waterfall on the right is green
- Feature 3: there is a distance between the first two waterfalls, and there is no color in the middle
- Feature 4: The latter two waterfalls are connected by a gray block “tail”
- Feature 5: An extra long grey block on top
We can summarize many similar characteristics, but what do these characteristics show? Can it help us locate performance bottlenecks?
Answering these questions requires a lot of knowledge about waterfall diagrams and how browsers work, so let’s walk through them step by step.
Analyze the meaning of waterfall diagram
We analyze it from left to right and from top to bottom. There are two color blocks on the left, a gray one and a blue one. We click these two color blocks respectively to see their details in the details panel.
Look at the gray blocks first
We have noticed that the Initiator of this request is a Chrome plugin: Chrome ://new-tab-page/omnibox.mojom-lite.js
So let’s not focus on that, let’s look at the blue block
As we mentioned earlier, the blue block represents an HTML file, which we can verify from the details of the Mime Type text/ HTML.
Let’s scroll the mouse wheel to zoom in on the waterfall to see the details of the blue request block
Request block composition
By looking at the details, we found something new:
Each request block consists of four parts:
- Left line: time Before Request Sent
- Light-colored block: Request Sent until the server returns the First Byte to the browser (TTFB, Time to First Byte)
- Dark block: All Content returned by the server is downloaded to the browser.
- Waiting for main thread
This HTML file is the starting point for rendering the entire web page. The successful request and download of this file will lead to the rest of the story.
The lighter portion of the request block is larger. As described earlier, the lighter portion represents the response speed of the server. The browser sends the request early and the server responds late (the first byte reaches the browser).
In the middle, the network may be slow, or the server processing speed is slow, need specific investigation, after all, this HTML file is not big, only 111KBb, but it took 179ms.
Another file, layouts.default.js, is 124KB larger and takes half as long to request, at 74ms. (It turns out that this data is unstable, and the HTML file should not pose a performance bottleneck.)
In addition, all subsequent requests depend on this HTML, without which no other request can occur, it is a blocking request, and performance must be guaranteed.
Identify potential performance bottlenecks
Let’s continue to look at the request block on the right. The long gray block at the top is still a Chrome plugin request. We don’t care.
After the HTML file is downloaded, it will start parsing the HTML tags line by line. When the
As you can see from the waterfall diagram, there are eight JavaScript files downloaded in parallel, all with the same domain name: sf1-scmcdn2-tos.pstatp.com
Chrome has a maximum of 6 concurrent requests for the same domain name.
Not only the JavaScript file, but also the following 3 image resources with the same domain name were also requested in parallel, meaning that 11 requests were made almost simultaneously.
This suggests that
Nuggets static resource server upgraded to HTTP/2
HTTP/2 multiplexing enables the simultaneous transfer of multiple resources over a single TCP connection.
We went to the Network panel to take a look at the details of these JavaScript requests, as we guessed, which must be given a thumbs up to 👍
Post a comparison between a 86 site and the Nuggets to give you a feel for it
86 website:
The nuggets:
While the former is more like a waterfall, I love the silky experience of the latter.
Let’s take a closer look at these 8 requests. If you are careful, you must find a phenomenon:
- What they have in common except for the domain names mentioned above is that these request blocks have very short left and right lines
- There are three extremely long request blocks, 1/5/8, that require special attention
It is a good sign that the left and right lines of the request block are very short, indicating that there is no waiting time and all the time is spent transferring data.
We click on the 1/5/8 request block to see their details
| Request block | details |
|---|---|
| 1 | Size: 4 KB Time: 635 ms |
| 5 | Size: 90 KB Time: 635 ms |
| 8 | Size: 3.9 MB Time: 633 ms |
This is very strange, 1/5 of the resource is not on the same order of magnitude as 8, but it takes more time than 8.
To determine whether this was accidental or inevitable, I recorded two more performance reports of the Nuggets’ homepage
This time, as expected, 8 takes longer than the others, and the JavaScript file is 3.9MB, which is too large and likely to be a performance bottleneck.
other
Moving on, there are three different color blocks under the yellow JavaScript color block:
- Purple: CSS style file
- Green: Picture file
- Grey: Font file (size 189KB)
These files are not large in size, and after generating performance reports for many times, it is found that these requests take less time than the eighth JavaScript file, so it is preliminarily judged that these requests do not constitute a performance bottleneck.
Moving on to the middle waterfall, there are no particularly time-consuming requests for the middle waterfall by generating performance reports multiple times, but no matter how many reports are generated, one thing is certain, is that
There is always a gap between the three falls
What do these gaps really mean?
Look at the fire chart, and you’ll see.
Step 3: Look at the flame map
Before looking at the formal fire map, let’s look at a waterfall and fire map together
After looking at this comparison of the waterfall and the flame, you must see a phenomenon
Where there is white space in the waterfall, there is color in the fire. Where the waterfall diagram has color, the fire diagram is blank.
But Why?
To answer this question, you need to understand how the main thread of the browser does what it does, and what a flame map does, so don’t worry, let’s go through it step by step.
What is a fire map
The flame chart is also part of the threads panel and represents the flow of tasks for the main thread of the browser:
What does the main thread do over time as the page loads
The horizontal axis of the flame chart is time, and the vertical axis is each macro task.
There are several microtasks below each macro task, and there may be many sub-tasks below each microtask, and so on.
Some tasks have a deep nesting level, while others have a shallow nesting level, so they have an inverted flame.
Each type of task has a different color (no need to memorize, get a general impression) :
- HTML Parse HTML: blue
- Parse Stylesheet: blue
- Evaluate Script: yellow
- Recalculate Style: deep purple
- Draw Paint: dark green
- Executing Microtasks: yellow
- Ajax request XHR Load: yellow
- Function Call: yellow
- Trigger Timer Fired: Yellow
Let’s take a quick look at the fire chart on the Nuggets’ homepage
Summarize the characteristics of the flame diagram
Then use the skills we learned in primary school to look for patterns and find out what the characteristics of the graph are. After a brief glance, we can summarize at least the following characteristics:
- Feature 1: Generally speaking, both sides are blank, and there are three big flames in the middle
- Feature 2: Two large flames on either side correspond to two gaps in the waterfall map (this explains why there are gaps between the three smaller waterfalls in the waterfall map)
- Feature 3: Some macros are extremely long and the background color is a red shadow line (instead of gray) with a small red triangle in the upper right corner
With a little more time, we might have found more, but these are the most obvious.
To answer these questions, we need to take a closer look at the fire diagram.
Analyze the meaning of the flame diagram
Since the fire diagram represents what the main thread is doing at every point in time, blank space naturally means that the main thread is not doing anything, so what is it doing?
It is waiting for
Wait for what?
Wait for the server to return some necessary resources and data
so
The margins of the flame chart are filled with browsers waiting for the server to return data
Looking for a long mission
Of all the tasks performed by the main thread, we need to pay special attention to those Long tasks that take a very Long time. The characteristics of these Long tasks have been described above:
The background color is a red shadow line with a small red triangle in the upper right corner
Three long missions, one second
Analysis long task
The next step is to analyze the long tasks and find specific modules/components/methods that take a long time.
Let’s zoom in on the biggest flame on the far right to see what’s inside.
Zooming in, we quickly see that 90% of the 591ms task was spent on a method called init, which was executed six times, with 3/4/6 taking a particularly long time
| The NTH init method | details |
|---|---|
| 3 | Time: 197 ms |
| 4 | Time: 93 ms |
| 6 | Time: 111 ms |
So what does this init method actually do?
May be hanging in the Vue component, is it possible that some components are too big, the logic inside is too complicated, here needs the front end of the nuggets to give the answer.
Take a look at the second largest flame on the left and zoom in again with the mouse wheel
One of the forEach loops we found was particularly time-consuming, taking 150ms to calculate something.
This still needs to look at the specific source code to find the root cause of the problem.
Examples of performance bottlenecks found through flame charts
Finally, I would like to share with you some of my own previous work on the XBoard Kanban project, where I found a performance problem with a dependent library using the flame diagram.
It follows the same line:
- Find the Long task
- Zoom in on the long mission flames
- Work your way down until you find a method that takes a long time and has a name (most of the code on the live network is compressed and confused, so you can’t see the name, so the development environment can more easily locate the method that has a performance problem)
- Click on the method in the flame diagram to see the link after Function in the details panel. Click on the link to jump directly to the specified method in the corresponding file
- Search for the method name in the source code to find it
- Finding a solution
The XBoard kanban page had a bunch of long tasks, and I looked for the TOP3
Then I scaled up the first long task, which soon paid off. I found that one method called drawQrCode took a long time, 192ms in total.
The library defines a drawQrCode to draw a TWO-DIMENSIONAL code, which is not actually on the kanban page, but needs to hover to a button to load.
So the solution was to delay the drawQrCode method, that is:
The drawQrCode method is not executed when the home page is loaded. The drawQrCode method is executed when the mouse moves over the corresponding button.
Waterfall diagram and fire diagram
Waterfall diagrams and fire diagrams complement and validate each other.
The waterfall diagram represents the browser making a request to the server. The browser then executes the logic and rendering of the page through a script based on the data returned by the server.
When the waterfall has a request block, the browser is asking for data from the server. If the browser has to rely on this data to do the next page rendering, it is likely that the browser will have nothing to do before the server returns the data, and the flame chart will be blank and the pie chart will be Idle.
By the time the browser gets the data back from the server, the main thread is processing the data and rendering the page, so there’s probably no way to send a request to the server, and the waterfall graph will go blank.
so
- The waterfall diagram is found to be blank, and there is likely to be a long task. Specific time-consuming methods need to be found and optimized
- It is found that the flame map appears blank, which is probably caused by the slow background interface or the existence of large static resources. It is necessary to locate the cause of the slow and optimize it
summary
This article first gives you a brief introduction of how to generate a website performance analysis report, and the general composition of the report;
Then I share with you the three steps I often use to identify business performance problems: baking a pancake under a waterfall;
From pie charts we can get a general idea of site performance, from waterfall charts we can quickly find slow interfaces and large resources, and from fire charts we can get a detailed insight into which specific modules/components/methods are likely to be performance bottlenecks.
Finally to recommend Google’s official performance evaluation guideline: developers.google.com/web/tools/c…
Join us
We are DevUI team, welcome to come here and build elegant and efficient human-computer design/research and development system with us. Email: [email protected].
The text/DevUI Kagol
Previous articles are recommended
Denver 🏆 DevUI x | 2020 people
Rollup package 📦 and publish your toolset 🔧
Dark Mode and Thematic Development of Web Interfaces