I read this article before:

Let’s start with a piece of code

width: 150px;
height: 150px;
font-size: 24px;
position: absolute;
Copy the code

When the browser parses to position, found that the element is absolute positioning, need from the document flow, but before the properties are resolved according to convention, so have to render, then rendering engine is the element in the document again to contact placeholder, so it could lead to other elements affected by his return to rearrangement.

Adjusted code

position: absolute;
width: 150px;
height: 150px;
font-size: 24px;
Copy the code

Root cause:Reflow

In fact, this element is caused by backflow, and reducing the browser reflow can improve the browser’s dom rendering performance

So the question is, right? How can we reduce itReflow?

To avoid this, you need to know how the browser renders!

  1. Parsing HTML to build A DOM tree, parsing CSS To build a CSS tree: Parsing HTML into a tree data structure, parsing CSS into a tree data structure
  2. Build render tree: The render tree formed by combining THE DOM tree and CSS tree.
  3. Render tree: With the Render tree, the browser already knows what nodes are in those pages, their CSS definitions and dependencies, and calculates where each node is on the screen.
  4. Render tree: Using the graphics card to draw the content on the screen according to the calculated rules.

The CSS code goes from being parsed to being displayed on the browser screen, which is essentially the above2 – > 3 – > 4In the process.

  • The browser does not immediately parse CSS styles as soon as they are obtained. Instead, it distributes the render styles according to the structure of the DOM tree according to the writing order of CSS styles, and then merges them with the DOM tree to generate the Render tree, which is the second step above.
  • Then the CSS styles of each node of the Render tree are iterated for parsing. At this time, the traversal order of CSS styles is exactly the previous writing order. During parsing, if the browser finds that a change in the positioning of an element affects the layout, it needs to go back and re-render. The third step takes too long, which directly affects the display of the fourth step.

Here is a specification, suggested in roughly the following order:

1. Positioning attributes:

Position, display, float, left, right, overflow, clear, z-index

2. Own attributes:

Width, height, padding, border, margin, background

3. Text style:

The font-family, font size, the font style, font weight, the font – varient and color

4. Text attributes:

Text-align, vertical-align, text-wrap, text-transform, text-indent, text-decoration, letter-spacing, word-spacing, white-space, and T ext-overflow

5. New attributes in CSS3:

Content, box-shadow, border-radius, transform

Recommendations to reduce the performance impact of Reflow

  1. Instead of changing the STYLE of the DOM one by one, pre-define the class and then change the DOM className
  2. Take the DOM offline and modify it, for example: first give the DOM to display: None (once Reflow), then you modify it 100 times before displaying it
  3. Do not place DOM node property values in a loop as variables in the loop
  4. If possible, do not modify DOM that has a large impact
  5. Use absolute/fixed positions for animated elements
  6. Do not use the table layout, it is possible that a small change will cause the entire table to be rearranged


P S : To see if it really does affect performance, here’s an experiment. \color{FF0000}{PS: To see if it really does affect performance, here’s an experiment. }

extension

Repaint:

The browser behavior triggered by a change in the appearance of an element. The browser redraws the element based on its new attributes. The process is redrawing. Rearrangement always leads to redrawing, but redrawing does not necessarily lead to rearrangement

Common attributes that cause redraw:

Color, border-style, visibility, background, text-decoration, background-image, background-position, background-repeat, outline- Font-size: 14.0px; white-space: normal; white-space: normal; white-space: normal; white-space: normal; white-space: normal; white-space: normal; white-space: normal; white-space: normal; white-space: normal

Recommendations for reducing repaint’s impact on performance

  1. Don’t change the STYLE of the DOM line by line. You can define the CSS class first and then change the DOM className.
  2. Do not place DOM node property values in a loop as variables in the loop.
  3. Use fixed or Absoult position for animated HTML elements, then modifying their CSS will not reflow.
  4. Never use a table layout. Because a small change can cause the entire table to be rearranged. (Except for table and its inner elements, which may require multiple computations to determine the attributes of its nodes in the rendered tree, usually taking 2-3 times as long as the equivalent elements. This is one reason why we should avoid using tables for layout.
  5. Do not make queries when layout information changes (this will force a refresh of the render queue)
  6. Replace top with translate
  7. Use opacity instead of visibility (optimize redrawing under a separate layer)

The experiment

This is a page of a fire engineer advertisement project, the page layout is too simple, may not see the gap

P tag after the position property defined!

The position of the P tag is defined first


Results: \color{FF0000}{result:}

After about 30 tests, the perfomancs item of Chrome debugging tool is slightly different when CSS is used a lot in the project (thanks for some CSS intentionally, in order to make more CSS). Basically, it directly shows that CSS calculation time is reduced, but paint calculation time is actually increased!! .


Conclusion: \color{FF0000}{conclusion:}


Seems to c s s There was a slight impact, but the overall browser time didn’t change much ( Mean of multiple times ) . Color {FF0000}{seems to have some effect on the CSS calculation, but the final browser total time is not much different (average of multiple times). }

PS: I remember that Chrome has a timline option, but I can’t find it. I don’t know if it’s because of the version. I tried perfomancs test this time, and I have a chance to use Timline again later. This test was conducted under MAC (about 30 times of comparison), and only one Chrome window and wechat were opened on the computer (screenshots were used) to prevent the influence of other applications. Perfomancs automatically recorded 5s data, and remember to clear the cache after changing the attribute position. Interested partners can experiment on their own. Welcome correction!!