Author: Doodle – Water mirror
Come doodle work: job.tuya.com/
Direction of performance optimization
The main criteria for front-end Performance are load-time Performance and run-time Performance. Run-time Performance refers to how your page performs when running in the browser. In this article, we share the React Profiler and Performance tools for detecting runtime Performance
1, the React Profiler
introduce
Profiler is used to measure how often a React application is rendered and the “cost” of rendering once. The purpose of the Profiler is to identify parts of the application that render slowly. You can use it directly in the React application. For details, see the Profiler API, but we’ll focus on using it in the browser developer tools
React-dom 16.5+ supports Profiling only in DEV mode, but a Profiling bundle can also be used in production environments. See how to use this bundle on react-profiling
use
DevTools adds a Profiler TAB column for apps that support the new profiling API. Once you start recording, DevTools will automatically collect performance data for your APP at every moment (after launch). You can use your APP as usual, and when you’re done with your profile, click the “Stop” button.
What each Tab item does
Before recording, first enable some important Settings (to open the Settings panel, click on the upper right corner gear ⚙).
Enable Highlight updates when Components Render
After this setting is checked, all render components on the page will be highlighted as wireframed, as shown below
Note: This option can also be turned on in production to see which components are being rendered
Enable Record Why each Component Rendered while profiling.
When enabled, we can see the specific cause of the component rendering in the Commit message
Viewing Performance Data
Commit figure
Conceptually, React runs in two phases:
- The Render phase determines what changes need to be made to data such as the DOM. In this phase, React will execute the Render method (for each component) and then calculate what changes were made before the Render method was called.
- The COMMIT phase is where React commits any changes (in the React DOM, this is when React adds, modifies, and removes DOM nodes). Also during this phase React executes periodic functions like componentDidMount and componentDidUpdate.
Profiler DevTools collects performance data during the COMMIT phase. Each commit is displayed in a bar chart at the top of the screen
Take the homepage of official website as an example, after opening profile, go to hover one of the menus
You can see that this operation triggered nine commits
Flame figure
The flame map is like a virtual DOM tree that displays information about the commit you specified. Each column represents a React Component. The size and color of each column indicate the render time of the Component and its children. The color of the column represents the time taken to render in that commit. Yellow means long, blue means short, and gray means the Component is not re-rendered in the commit.
As shown in the image above, you can see that the Header component was rerendered during the commit. Click on the Header component to see the details
The longest rendering time is 18.2ms for the Header component. The reason for rendering is Hooks Changed. The most high-performance subcomponent of the Header component is HeaderDrawer. The render time is 16.9ms, and click on the HeaderDrawer component to see more
As you can see, there are two reasons for rendering the HeaderDrawer, and the main reason for its long rendering time is that the HeaderDrawer has so many child components rendering for the first time
Sequence diagram
Like the fire diagram, the sort diagram shows the commit you specified, and each column in the diagram represents a React Component. The difference is that the sorting diagram is no longer displayed as a DOM tree. Instead, components are sorted by time. The components that take the longest time are displayed in the first line. This allows us to find the components that take the longest to render in a large number of renderings
Used to summarize
1, first by highlighting render components to render 2, those places were identified by viewing the flame figure to find the rendering time component 3, by looking at the rendering component to find out the reason, trigger the render view trigger the cause of the rendering is normal 4 excessive, if apply colours to a drawing of the component can be found through sorting chart to render the longest components
Chrome Devtool Performance
introduce
React Profiler can help you quickly identify Performance bottlenecks in React applications. However, if your application does not use React, how do you analyze Performance bottlenecks
Before using it, you can set it according to your own needs. Briefly introduce the function of each setting item
Screenshots: this parameter is selected by default, and each frame will be captured. 2. Memory consumption records: After this parameter is selected, you can see various Memory consumption curves. Enable Advanced paint Instrumentation (slow) record the details of rendering events. CPU: Enable advanced paint Instrumentation (slow) Simulate performance on low performance cpus
use
Once you start recording, DevTools will automatically collect performance data for your APP at every moment (after launch). You can use your APP as usual, and when you’re done with your profile, click the “Stop” button.
At the end of the recording, we will have a picture like this above. At first glance, there is a lot of information, but the main information we need to pay attention to is mainly these parts
FPS
The higher the green, the better. Red indicates a low FPS, which can be seen in Frames
If a red line appears, the FPS is too low
CPU
In the Main area, we can view the execution of the call stack. For example, the requestAnimationFrame API is executed first. We then called app.update and created Recalculate Style, Layout, Update Layer Tree, Paint, and so on to calculate the Style, then Layout, update the render Tree, and finally draw to the screen
If a small red triangle appears at the upper right corner of the event bar, it indicates that the event is problematic and needs special attention.
For example
Google provides a DEMO for analysis. This page is full of little blue squares moving up and down. Click Add until the page freezes, click Optimize to find the deadlock disappears, and we run a performance analysis of the Carton page
A simple observation shows that there is a red line on the FPS, which indicates that the FPS is too low. When looking at the small squares in Main, there are red triangles, which indicates that there are problems in each event invocation, and the Rendering takes too long in the Summay diagram
If the code is not compressed in the development environment, we can directly click to jump to the source code to view
This is why the page is stuck. We know that the browser backflow redraw operation is similar to the setState operation in React. Browser batch will be redrawn reflux operation in an execution queue, when performing the queue reaches a certain number or arrived at specified conditions will batch the execution of the redraw reflux operation, thus avoiding the frequent redrawn and reflux operation, but the performance in the React setState is asynchronous, we won’t be able to get the latest state, However, in the browser, no matter how the DOM moves, we can get its latest location information every time. At this time, because in the browser, if js performs the operation of reading the DOM location information, the browser will immediately clear the execution queue to redraw the flow to ensure that JS can read the latest location information.
The details can be viewed:
1, developers.google.com/web/fundame…
2, muyiy. Cn/question/br…
So how do you optimize this operation? We can look at the optimized code below and find that the optimized code will read offset directly instead of reading style. Top, so that we can get the latest position information. And although the location information on the style is updated, the backflow operation is still in the execution queue, so there is no forced backflow
Click “Optimize” and then conduct a wave of performance analysis. It can be seen that the optimized performance information has returned to the normal standard
conclusion
This article briefly introduces two performance testing tools, which can be used to test from time to time during development to see if there are obvious performance problems and then optimize them in time.
Come doodle work: job.tuya.com/