Ruan Yifeng: webpage performance management details, Ruan Yifeng

Ruan Yifeng: detailed explanation of webpage performance management (transfer) and Ruan Yifeng

Have you ever encountered a webpage with poor performance?

This kind of webpage response is very slow, taking up a lot of CPU and memory, browsing is often choppy, and the page animation effect is not smooth.

What would you do? I guess most users will close this page and access other websites. As a developer, I certainly don't want to see this situation. How can I improve performance?

This article describes in detail the causes of performance problems and solutions.

　　1. webpage Generation Process

To understand why the webpage performance is poor, you must understand how the webpage is generated.

The webpage generation process can be roughly divided into five steps.

In these five steps, the first step to the third step are very fast, and the time consumed is step 4 and Step 5.

The two steps "generate layout" (flow) and "painting" (paint) are collectively called "rendering" (render ).

　　Ii. Shuffling and re-painting

When a webpage is generated, it is rendered at least once. During user access, the service will be re-rendered continuously.

In the following three cases, the webpage will be re-rendered.

Re-rendering, you need to re-generate the layout and re-draw. The former is called reflow, and the latter is called repaint ).

Note that "re-painting" does not necessarily require "re-arrangement". For example, changing the color of a webpage element triggers "re-painting" and does not trigger "re-arrangement ", because the layout has not changed. However, "shuffling" will inevitably lead to "re-painting". For example, changing the location of a webpage element triggers "re-painting" and "re-painting" at the same time, because the layout changes.

　　Iii. Impact on Performance

Shuffling and re-painting will be triggered continuously, which is inevitable. However, they are very resource-consuming and are the root cause of poor web page performance.

To improve web page performance, we need to reduce the frequency and cost of "re-painting" and "re-rendering", and trigger re-rendering as little as possible.

As mentioned above, DOM changes and style changes will trigger re-rendering. However, the browser is very intelligent. It will try its best to put all the changes together in a queue, and then execute them once, so as to avoid re-rendering multiple times.

div.style.color = 'blue';div.style.marginTop = '30px';

In the code above, the div element has two style changes, but the browser will trigger only one re-painting.

If the data is not well written, the system will trigger two shuffling and re-painting.

div.style.color = 'blue';var margin = parseInt (div.style.marginTop);div.style.marginTop = (margin + 10) + 'px';

After the code above sets the background color for the div element, the second line requires the browser to give the position of the element, so the browser has to rearrange it immediately.

Generally, after a style write operation, if the following read operations are performed on these attributes, the browser will immediately re-render them.

Therefore, from the perspective of performance, try not to put read and write operations in a statement.

// baddiv.style.left = div.offsetLeft + 10 + "px";div.style.top = div.offsetTop + 10 + "px";// goodvar left = div.offsetLeft;var top  = div.offsetTop;div.style.left = left + 10 + "px";div.style.top = top + 10 + "px";

The general rule is:

　　4. Nine skills for improving performance

There are some tips to reduce the frequency and cost of browser re-rendering.

The first is as mentioned in the previous section. Multiple read Operations (or write operations) of the DOM should be put together. Do not add a write operation between two read operations.

Second, if a style is obtained by shuffling, it is best to cache the result. This prevents the browser from re-arranging when it is used for the next time.

Article 3: do not change the style one by one, but change the style one by changing the class or csstext attribute.

// badvar left = 10;var top = 10;el.style.left = left + "px";el.style.top  = top  + "px";// good el.className += " theclassname";// goodel.style.cssText += "; left: " + left + "px; top: " + top + "px;";

Article 4: Use offline DOM instead of the real DOM to change the element style. For example, to operate on the Document Fragment object, add the object to the DOM. For example, use the cloneNode () method to operate on the cloned node, and then replace the original node with the cloned node.

Article 5: first set the element to display: none (requires one re-arrangement and re-painting), and then perform 100 operations on the node, then restore the display (one re-arrangement and re-painting are required ). In this way, you can use two re-renders to replace up to 100 re-renders.

Article 6: if the position attribute is an element of absolute or fixed, the overhead of rescheduling is relatively small because it does not have to be considered as an impact on other elements.

Article 7: The display attribute of an element is visible only when necessary, because invisible elements do not affect the arrangement and re-painting. In addition, the visibility: hidden element only has an effect on the shuffling and does not affect the re-painting.

Article 8: Use a virtual DOM script library, such as React.

Article 9: Adjust the re-rendering using the window. requestAnimationFrame () and window. requestIdleCallback () methods (see the following document ).

　　V. Update Rate

In many cases, intensive re-rendering is unavoidable, such as the scroll Event Callback Function and webpage animation.

Each frame of a webpage animation is re-rendered once. The human eye can feel the pause when the animation is less than 24 frames per second. Normal webpage animations can be smooth only when they reach 30 to 60 frames per second. If it can reach 70 or even 80 frames per second, it will be extremely smooth.

The refresh frequency of most monitors is 60Hz. To stay consistent with the system and save power, the browser automatically refreshes the animation at this frequency (if possible ).

Therefore, if the webpage animation can achieve 60 frames per second, it will be synchronized with the display to achieve the best visual effect. This means that 60 re-rendering times within one second, each re-rendering time cannot exceed 16.66 milliseconds.

The number of re-rendering tasks that can be completed in one second. This metric is called "refresh rate". The English format is FPS (frame per second ). 60 re-rendering, that is, 60FPS.

　　6. Timeline panel of Developer Tools

The Timeline panel of the Chrome browser developer tool is the best tool for viewing the "update rate. This section describes how to use this tool.

First, press F12 to open "Developer Tools" and switch to the Timeline panel.

There is a gray dot in the upper-left corner. This is the recording button. pressing it turns red. Then, perform some operations on the webpage and press the button again to complete the recording.

The Timeline Panel provides two ways to view events: the Event Mode is used to display the time required for re-rendering events; the vertical bar is the Frame Mode, which shows the time consumption of each Frame.

First, let's look at the "Event Mode". You can determine which part of the performance problem occurs, whether it is JavaScript execution or rendering?

Different colors indicate different events.

 
 

  
  
Blue: network communication and HTML Parsing
  
  
Yellow: JavaScript Execution
  
  
Purple: style calculation and layout, I .e. re-arrangement
  
  
Green: repainting
 
 

If there are many color blocks, it means the performance is consumed. The longer the color block, the greater the problem.

Frame mode is used to view the time consumed by a single frame. The lower the Color Bar Height of each frame, the better, indicating less time consumption.

As you can see, the frame mode has two horizontal reference lines.

The following is 60FPS, which is lower than this line and can reach 60 frames per second. The above is 30FPS, which is lower than this line and can reach 30 rendering times per second. If the color bar exceeds 30 FPS, the webpage may have performance problems.

You can also view the time consumption of a specific interval.

Or click each frame to view the time composition of the frame.

　　VII. window. requestAnimationFrame ()

Some JavaScript methods can be used to adjust the re-rendering, greatly improving the web page performance.

The most important one is the window. requestAnimationFrame () method. It can put some code into the next re-rendering for execution.

function doubleHeight (element) {  var currentHeight = element.clientHeight;  element.style.height = (currentHeight * 2) + 'px';}elements.forEach (doubleHeight);

The above Code uses a loop operation to double the height of each element. However, each loop is followed by a write operation. This will trigger a lot of re-rendering in a short time, which is obviously unfavorable to the web page performance.

We can usewindow.requestAnimationFrame ()To separate read and write operations and put all write operations to the next re-rendering.

function doubleHeight (element) {  var currentHeight = element.clientHeight;  window.requestAnimationFrame (function () {    element.style.height = (currentHeight * 2) + 'px';  });}elements.forEach (doubleHeight);

The page rolling event (scroll) Listening function is suitable for window. requestAnimationFrame (), which is postponed to the next re-rendering.

$(window) .on ('scroll', function() {   window.requestAnimationFrame (scrollHandler);});

Of course, webpage animation is the most suitable scenario. The following is an example of rotating an animation. Each frame of an element is rotated at 1 degree.

var rAF = window.requestAnimationFrame;var degrees = 0;function update () {  div.style.transform = "rotate (" + degrees + "deg)";  console.log ('updated to degrees ' + degrees);  degrees = degrees + 1;  rAF (update);}rAF (update);

　　8. window. requestIdleCallback ()

There is also a function window. requestIdleCallback (), which can also be used to adjust the re-rendering.

It specifies that the callback function is executed only when the end of a frame has idle time.

requestIdleCallback (fn);

In the code above, function fn is executed only when the running time of the current frame is less than 16.66 ms. Otherwise, it will be postponed to the next frame. If there is no idle time for the next frame, it will be postponed to the next frame, and so on.

It can also accept the second parameter, indicating the specified number of milliseconds. If there is no idle time for each frame within the specified period, the function fn will be executed forcibly.

requestIdleCallback (fn, 5000);

The code above indicates that the function fn will be executed in 5000 milliseconds at the latest.

Function fn can accept a deadline object as a parameter.

requestIdleCallback (function someHeavyComputation (deadline) {  while(deadline.timeRemaining () > 0) {    doWorkIfNeeded ();  }  if(thereIsMoreWorkToDo) {    requestIdleCallback (someHeavyComputation);  }});

In the above Code, the someHeavyComputation parameter of the callback function is a deadline object.

The deadline object has a method and a property: timeRemaining () and didTimeout.

(1) timeRemaining () method

The timeRemaining () method returns the remaining milliseconds of the current frame. This method can only be read, cannot be written, and will be dynamically updated. Therefore, you can constantly check this attribute and execute some tasks if there is still time remaining. Once this attribute is equal to 0, the task is assigned to the next round.requestIdleCallback.

In the previous sample code, the doWorkIfNeeded method is continuously called as long as the current frame has idle time. Once there is no idle time, but the task has not been fully executed, it will be allocated to the next roundrequestIdleCallback.

(2) didTimeout attribute

Deadline objectdidTimeoutReturns a Boolean value indicating whether the specified time has expired. This means that if the callback function is triggered due to a specified expiration time, you will get two results.

• The timeRemaining method returns 0.
• The didTimeout attribute is equal to true.

Therefore, if the callback function is executed, there are only two reasons: the current frame has idle time, or the specified time has reached.

function myNonEssentialWork (deadline) {  while ((deadline.timeRemaining () > 0 || deadline.didTimeout) && tasks.length > 0)    doWorkIfNeeded ();  if (tasks.length > 0)    requestIdleCallback (myNonEssentialWork);}requestIdleCallback (myNonEssentialWork, 5000);

The code above ensures that the doWorkIfNeeded function will be executed repeatedly in a relatively idle time (or after the specified time expires) in the future.

RequestIdleCallback is a very new function, just introduced the standard, currently only supported by Chrome.

　　IX. Reference Links

 

Original article: Ruan Yifeng: webpage performance management details