Related knowledge of repaint and Reflow

Article Introduction: page refactoring should pay attention to repaint and reflow.

Recently learned about the next repaint and reflow related knowledge, feel that in the page refactoring process should consider front-end development (JS) staff to operate the DOM, can reduce the customer browser pear.
Here to tidy up a bit of relevant information, recommended to see the article at the bottom of the post, if the layout is not good enough please visit my blog onlookers. This is a discussion post, to talk about their experience in the work ~

1. What are repaint and reflow?

A page is made up of two parts:
DOM: Describes the structure of the page
Render: Describes how the DOM node (nodes) renders on the page

When a property of a DOM element changes (such as color), the browser notifies the render that the corresponding element is being redefined, a process called repaint.

If the change involves an element layout (such as width), the browser discards the original attribute, recalculates and passes the result to render to recreate the page element, a process called reflow.

These two processes are very browser-intensive, from the IE series and Chrome rendering page speed gap can see that the rendering engine calculation of the corresponding values and rendering is not necessarily efficient, and each of the operations on the element will occur repaints or reflow, so writing a DOM interaction if not attention will cause the page Low surface performance.
The process of page rendering is as follows:

1. Parse the HTML code and generate a DOM tree.

2. Parsing CSS files, in order: Browser default style-> custom style-> the style within the page.

3. Generate a render tree (render). The difference between this rendering tree and the DOM tree is that it is influenced by styles. It does not include those nodes that are not visible.

4. When the rendering tree is generated, the browser "draws" the nodes in all rendering trees on the screen.

2. Under what circumstances will trigger the browser's Repaint/reflow?

In addition to the fact that the page is bound to go through the process the first time it is loaded, the following behavior triggers this behavior:
Reference:
1. Add, modify (content), delete DOM elements (reflow + Repaint)
2. Modify only the font color of the DOM element (only repaint, because you do not need to adjust the layout)
3. Apply the new style or modify any attributes that affect the appearance of the element
4. Resize browser window, scrolling page
5. Read some of the attributes of the element (Offsetleft, offsettop, offsetheight, offsetwidth, Scrolltop/left/width/height, clienttop/left/width/ Height, getComputedStyle (), Currentstyle (in IE))
3. How to optimize?

1. Avoid direct and frequent DOM operations on the document, and if it is really necessary to do so in a off-document manner, the specific methods include, but do not fully include, the following:

Reference:
1. Remove elements from document first, complete the changes and put the elements back to their original position
2. Set the display of the element to "none", complete the modification and then change the display to the original value
3. If you need to create multiple DOM nodes, you can use DocumentFragment to create a one-time join document
2. Change the style centrally

Reference:
1. Modify the attributes on the element style as little as possible
2. Modify the style as much as possible by modifying the ClassName
3. Set style values by Csstext property
3. Cache Layout Property Value

Reference:
For values that are not reference types in the Layout property (numeric), you can save multiple accesses to a local variable and then use local variables to avoid rendering the browser every time you read the property.
4. Set the element's position to absolute or fixed

Reference:
When the element's position is static and relative, the element is in the DOM tree structure, and the browser renders the entire page when an operation on the element needs to be rendered again. Setting the position of an element to absolute and fixed allows the element to be detached from the DOM tree, and the browser needs to render the element only as well as the elements underneath it, thereby shortening the browser rendering time to some extent. This is particularly worth considering in today's growing number of JavaScript animations.
5. Balance the smoothness of the speed

Reference:
For example, to implement an animation, 1 pixels to move the most smooth, but reflow will be too frequent, the CPU will soon be fully occupied. It would be much better if you moved in 3 pixel units.
6. Do not use tables layout

Reference:
Another reason not to use the tables layout is that when an element in tables triggers reflow, it causes all the other elements in the table to reflow. When suitable for table, you can set Table-layout to auto or fixed, so that the table can be rendered on one line, which is also to limit the impact of reflow
7. Do not write expression in CSS

Reference:
In many cases, reflow is triggered, and if there is expression in CSS, it will be recalculated every time.
Reference articles:

1. How to reduce browser repaint and Reflow
2. Repaint, Reflow/relayout, Restyle
3. Reflows & Repaints:css Performance making your JavaScript slow?
4. Repaint tracking Browser Rendering [If your FF is 3.5beta+ Monitor Web page redraw situation]