Analysis of rendering performance

This article focuses on performance after the resource is loaded, because most users are not interested in how the app is loaded but specifically used. So to quickly respond to users, especially the wireless side, we need to understand the browser rendering performance.

RAIL Performance Model

First, a question to think about, what kind of website is smooth? We may be able to give a general feeling, such as a second-level response. In fact, can also give a very flattering answer: users feel smooth Web site it is smooth. Because almost all sites want to leave users on the page, it is necessary to create a performance model that is user-centric. Here is a user-centric performance model proposed by Google, the data is not Google's first, there are some papers to do similar research (such as: 100ms response to the user is a very appropriate time, etc.).

is the specific meaning of RAIL, here are some key data indicators:

• Respond:0-100ms, Windows generally need to respond to users in this time period, more than this time period, the user will feel the delay.
• Animation:0~16ms, the screen refreshes 60 times per second, and 16ms represents the time of each frame. The user is very concerned about the animation, when the animation lost frame is easy to arouse the user awareness. So animation generally to control in 60FPS.
• Idle: Maximizes the idle time of the main process so that it responds to user input in a timely manner.
• Load: Content needs to be loaded in 1000ms Nega, more than 1000ms will feel slow loading.

What do the applications need to do to reach the above performance model? If we know how the browser renders a page, and to optimize the key steps in the rendering process, is it possible to do more with less?

Critical Render Path

is the key path for browser rendering, first, let's start by parsing a page from the browser.

• Conversion: The browser reads the original bytes of HTML from a disk or network, and the browser decodes the original file according to the appropriate encoding specification (now generally utf-8).
• Symbolization: converted to corresponding symbols according to the universal standard (usually within angle brackets).
• DOM Build: The HTML parser parses the tag tag, generates tokens, and encounters CSS or JS to send the corresponding request. HTML parsing is blocking the main process, CSS is generally blocking the main process (media query exceptions), that is, they are not able to respond during the parsing process. and JS manually add async after the asynchronous load, according to token generation of the corresponding DOM tree.
• 。
• Cssdom build, add CSS styles to generate Cssdom tree.
• The render tree is built, starting from the root node of the DOM tree, traversing each visible node, finding the corresponding matching CSSOM rules for each visible node, and applying these rules, with its contents and calculated styles.
• For style calculations, the browser converts all relative positions to a series of style calculations, such as absolute positions.
• Layout, the browser locates and lays out the elements.
• Draw, draw element styles, colors, backgrounds, sizes, borders, and more.
• Compositing, which synthesizes the layers together and displays them on the screen.

If we are making an animation, we will usually use JS to change the corresponding style, then the browser will go through the JS run, style calculation, layout, drawing, composition and other important steps (later on this step will be more in the actual process can be longer or shorter). The optimization to be done is to optimize in these steps and eliminate the intermediate time-consuming steps as much as possible.

Optimizing the execution of JavaScript

The four scenarios described are likely to affect the response to user input or animation. function input event processing, time-inappropriate JS, long JS Run and garbage collection.

Input event handling for functions

First, one of the facts we need to know is that the browser is handled by multiple processes: compositor, Tile Worker, Main. When the user enters the operation (scrolling, clicking, etc.), such as scrolling, the compositor process will receive this event (it can actually accept any user input events), and if so, it will not notify the main process, directly said: "Roll, cow baby." As a result, the page scrolls. Of course, this includes updating layer positioning and having the GPU draw frames while the main thread is idle. But things are not always the case. If the input event is bound to the JS processing event, the compositor process will not be able to actively skip the main process.

For example, when the JS processing event is too long, the response of the input event will remain blocked until the JS processing is complete. When the response is more than 100ms, the user will feel the delay. So when dealing with user events, we should:

• Avoid long-time JS execution.
• Avoid changing the style in the process. Because changes in style can cause subsequent layouts, drawing, compositing, and so on.
• The user input is shaken.

Optimized processing

Other optimizations:

• Use Requestanimationframe to change setTimeout to Requestanimationframe, because setTimeout time control may result in the middle of a frame, the current browser Requestanimationframe's support has been better.
• Using Web Workers, JS with complex computation is processed using Web Workers.
• Reduce garbage collection, garbage collection is an easy to ignore problem, because garbage collection time is not controlled, it may be in the middle of an animation, blocking the execution of the animation, more ideal is to reuse the object in the loop.

Style calculation

Adding or removing a DOM element, modifying element attributes and style classes, applying animation effects, and so on, can cause changes in the DOM structure, causing the browser to recalculate the style of each element, re-layout the page, or part of it (in most cases).
The first step in calculating a style is to create a matching set of style selectors that the browser uses to apply styles to an element. The second step is to obtain the corresponding specific style rule based on the matching style selector, and to calculate which styles are ultimately applied to the DOM element. So the optimization of the style is also the two steps:

Reduce the complexity of selectors

How do I reduce the complexity of selectors?

.box:nth-last-child(-n+1) .title {  /* styles */}.final-box-title {  /* styles */}

The above code selects the same element, and when there are many elements, the second selector performs significantly better than the first. The BEM specification has done something similar, and the ability to select elements directly from a selector by feature tends to be more optimal.

Reduce the amount of calculation for a style

Because the amount of the element is proportional to the number of elements being changed, you only need to be aware of the fact that the invalid element is reduced.

<div>  <div>    <p>多层无意义的标签</p>  </div></div>

Like the example above, some redundant tags are sometimes created. When changing the style of the outer layer, redundant labels also require style calculations, wasting performance.

Layout

The process by which the browser computes the geometry information of a DOM element: the element size and position in the page. Each element has an explicit or implicit size information, determined by the setting of its CSS property, the size of the content of the element itself, or the size of its parent element. In the Blink/webkit kernel browser and IE, this process is called Layout. In Gecko-based browsers (such as Firefox), this process is called Reflow.

Avoid triggering layouts

Currently, transform and opacity only cause compositing and will not cause layout and redraw. The more cost-intensive layout and drawing process across the process will skip directly, and performance is clearly good. Other CSS property changes caused by the process will be different, some properties will also skip the layout, in particular, to view the CSS Triggers. Therefore, the first step in optimization is to avoid triggering the layout as much as possible.

Using the Flexbox layout

The Flexbox layout scheme performance is better than the previous layout scheme, and the browser has a fairly high level of support for Flexbox at the moment:

Avoid forcing synchronization of layout events

The first is to execute the JS script, then the style calculation, then the layout. However, we can also force the browser to execute the layout procedure before executing the JS script, which is called forcing the synchronization layout. When the JS script runs, it can get the element style attribute value is the previous frame, all the old values. So, if you want to read the height property of an element at the beginning of this frame, you can write the JS code like this:

function logBoxHeight() {  box.classList.add(‘super-big‘);  // Gets the height of the box in pixels  // and logs it out.  console.log(box.offsetHeight);}

In order to give you the value of the Height property of box, the browser must first apply the box's property modification (because it adds the Super-big style) and then perform the layout procedure. After that, the browser can return the correct height property value. This creates a synchronous layout event that is very performance-intensive. In most cases, you should not need to modify and then read the element's style property values, and using the previous frame value is sufficient. Performing style calculations and layouts prematurely is one of the bottlenecks of potential page performance.

function logBoxHeight() {  // Gets the height of the box in pixels  // and logs it out.  console.log(box.offsetHeight);  box.classList.add(‘super-big‘);}

Avoid fast, continuous layout

There is another situation worse than forcing a synchronous layout: Execute it more than once in a row.

function resizeAllParagraphsToMatchBlockWidth() {  // Puts the browser into a read-write-read-write cycle.  for (var i = 0; i < paragraphs.length; i++) {    paragraphs[i].style.width = box.offsetWidth + ‘px‘;  }}

The preceding code loops through a set of paragraph labels, setting the value of the Width property of the P tag to the same width as the box element. It looks like this code is fine, but the problem is that in each loop, a style property value for the box element is read, and then immediately updated with the value of the P element's Widt H property. When reading the box element Offsetwidth property in the next loop, the browser must first make the style update operation in the last loop take effect, that is, perform the layout process before responding to the style read operation in this loop. The layout process will occur in each loop. Optimized code:

// Read.var width = box.offsetWidth;function resizeAllParagraphsToMatchBlockWidth() {  for (var i = 0; i < paragraphs.length; i++) {    // Now write.    paragraphs[i].style.width = width + ‘px‘;  }}

You can use Fastdom if you want to make sure that the written read and write operations are safe. It helps you automate the batch processing of read and write operations, and avoids accidentally triggering a forced synchronization layout or a fast, continuous layout.

Draw

Raise the drawing layer of a moving or gradient element

Drawing is not always done in an in-memory single-layer screen. In fact, the browser will, if necessary, draw a frame into a multi-layered picture, and then merge the layers into a single picture to display on the screen. By rendering layer elevation, you can reduce the drawing area, and we can use the Debug tool to view the drawing layer:

The best way to create a new render layer in a page is to use the Will-change property, and then use it with the Transform property, creating a new composition layer:

.element {  will-change: transform;}

For browsers that do not currently support the Will-change property but support the creation of a render layer, you can use a 3D transform property to force the browser to create a new render layer:

.element {  transform: translateZ(0);}

Note: Don't blindly create a render layer, be sure to analyze its actual performance. Because creating a render layer is a cost, each creation of a new render layer means new memory allocations and more complex layers of management. And there is a limit to the bandwidth of the GPU and CPU on the mobile side, and when too many render layers are created, the composition consumes more time.

Carefully plan animations and simplify the complexity of drawing

Sometimes, although the element is lifted to a separate render layer, the browser merges the rendering tasks of the two adjacent areas, which will cause the entire screen area to be drawn. So you can use the Debug tool to view and carefully plan the animation.
The cost of drawing different CSS properties is not the same, drawing a shadow is more time consuming than drawing a border. Of course, this browser is also constantly optimizing, now the time-consuming rendering properties can be changed at any time, so need to pay more attention.

Synthesis

The merge of the render layer is to merge the part of the drawing process completed in the page into one layer and then display it on the screen. The following two points related to composition are also mentioned earlier.

animating effects with transform/opacity

The advantages of transform/opacity have been mentioned earlier, and the elements that apply the Transforms/opacity attribute must be exclusive to a render layer. In order to create an own rendering layer for this element, you must promote the element.

Manage the render layer, avoid too many layers

Creating a new render layer consumes additional memory and management resources. On devices with limited memory resources, the impact on page rendering performance due to the overhead of too many render layers is far more than the benefit of performance improvements. Since textures for each render layer need to be uploaded to GPU processing, we also need to consider the bandwidth issues between the CPU and GPU, and how much memory is available for the GPU to handle these textures.

Other

• Looking at trends, many of today's performance bottlenecks are likely to be no longer a problem in the future. As previously concerned about a technical Web animations, can use JS to achieve the native animation effect. Houdini, you can add more JS code to the animation without worrying about performance issues.
• Using the tool Chrome DevTools, the above rules are only the direction of optimization and are good at using tool analysis. Mobile use of Inspector is also very convenient, and can also save data, comparative analysis and so on. Almost everything needed for analysis tools, DevTools all have.
• It is not necessary to do micro-optimization, and sometimes it takes a short performance boost to be small, and it is unnecessary for the daily fast iterations of the business.

RELATED LINKS

• Paul Lewis related articles, the Chrome development team, are designed to help developers improve their apps and sites.
• Performance Calendar, from 2009 to 2015, lists the optimization options that are worth paying attention to every year.
• Performance,google developers official site for performance-optimized articles.
• Webkit,webkit blog site, introduced the comparison of the bottom of the rendering and other articles.

Original link

Analysis of rendering performance