Redrawing and rearrangement of browsers

The process of downloading a document from the browser to the display page is a complex process that includes redrawing and rearrangement. Each browser engine works slightly differently, but there are certain rules. Simply put, the browser engine parses the HTML document to build the DOM tree when the document is first loaded, and then constructs a tree for rendering based on the geometry attributes of the DOM element. Each node of the render tree has properties such as size and margins, similar to a box model (because hidden elements do not need to be displayed, the render tree does not contain hidden elements in the DOM tree). When the render tree is built, the browser can place the element in the correct location, drawing the page based on the style properties of the render tree node. Because of the browser's flow layout, the calculation of the render tree is usually done by traversing only once. With the exception of table and its internal elements, it may take several calculations to determine the properties of its nodes in the render tree, which typically takes 3 times times the same time as the elements. This is one reason why we should avoid using table for layout.

Redrawing is a browser behavior triggered by a change in the appearance of an element, such as changing visibility, outline, background color, and so on. The browser redraws the element based on its new properties, giving the element a new look. Redrawing does not bring a re-layout, and does not necessarily accompany reflow.

Rearrangement is a more obvious change that can be understood as a rendering tree that needs to be recalculated. The following are common triggers for reflow operations:

1. Changes in geometry properties of DOM elements

When the Geometry property of a DOM element changes, the associated node in the render tree is invalidated and the browser re-constructs the failed node in the render tree based on the changes in the DOM element. This part of the page will then be redrawn based on the new render tree. Also, the rearrangement of the current element may result in the rearrangement of related elements. For example, when the render tree of a container node changes, the recalculation of the child nodes is triggered, and the subsequent sibling nodes are re-queued, and the dimensions of the ancestor nodes that need to recalculate the child nodes also result in rearrangement. Finally, each element is redrawn. As can be seen, reflow is bound to cause the browser to redraw, the rearrangement of an element usually brings a series of reactions, even trigger the entire document Reflow and redraw, the performance cost is high.

2. Structure changes of the DOM tree

When the structure of the DOM tree changes, such as the increase or decrease of the nodes, moving, etc., will also trigger the rearrangement. The process of browser engine layout, similar to a tree's pre-order traversal, is a process from top to bottom from left to right. Usually in this process, the current element no longer affects elements that have been traversed before. So, if you insert an element at the top of the body, it will cause the entire document to be re-rendered, and then insert an element after it, without affecting the previous element.

3. Get some properties

The browser engine may be optimized for reflow. Opera, for example, waits for a sufficient number of changes to occur, or until a certain amount of time is available, or when a thread ends, and then it is processed together, so that only one rearrangement occurs. But in addition to the direct changes in the rendering tree, when getting some properties, the browser will also trigger a reflow to get the correct value. This makes the browser's optimizations ineffective. These properties include: OffsetTop, Offsetleft, offsetwidth, offsetheight, ScrollTop, ScrollLeft, ScrollWidth, ScrollHeight, ClientTop, ClientLeft, ClientWidth, ClientHeight, getComputedStyle () (Currentstyle in IE). Therefore, the values should be cached when they are used more than once.

In addition, changing some of the elements ' styles, resizing the browser window, and so on will also trigger a reflow.

In the development, the better practice is to minimize the number of rearrangement and reduce the impact of the range of rearrangement. For example:

1. Merge the actions of the style property multiple times into one operation. For example

Js:

var changediv = document.getElementById (' Changediv '); changeDiv.style.color = ' #093 ′;changediv.style.background = ' # Eee '; changeDiv.style.height = ' 200px ';

Can be combined into:
Css:

Div.changediv {background: #eee; color: #093; height:200px;}

Js:

document.getElementById (' Changediv '). ClassName = ' changediv ';

2. The element that needs to be re-position is set to absolute or fixed so that the element is out of the document flow and its changes do not affect other elements. For example, an animated element is best set to absolute positioning.

3. Operate the node multiple times in memory and add it to the document when you are done. For example, to get tabular data asynchronously, render to a page. Instead of looping through each row, you can make an HTML fragment of the entire table in memory and then add it to the document once.

4. Because the display property is none element is not in the render tree, the operation of the hidden element does not cause the rearrangement of other elements. If you want to perform complex operations on an element, you can hide it and then display it when the operation is complete. This only triggers 2 reflow when hidden and displayed.

5. Cache to variables when you need to get the property values that cause the browser to reflow frequently.

One of the more frequently asked questions in the last few interviews: how to implement a sort of table in the front end. If the candidate's scenario takes into account how to reduce the impact of redrawing and rearrangement, it will be a satisfying scenario.

Redraw and rearrange the browser (go)