Why do front-end developers need to understand page rendering ?, Front-end developers
Rendering should be optimized from the very beginning when the page layout is defined. styles and scripts play a very important role in page rendering. Professionals know some tips to avoid performance problems. This article does not go deep into the technical details of browsers, but provides some general principles. Different browser engines work in different ways, which makes learning for specific browsers more complex.
How does a browser render a page?
Let's start with the general process of page rendering in the browser:
- DOM is formed by HTML received from the server (Document Object Model ).
- The style is loaded and parsed to form a CSSOM (CSS object model ).
- Then DOM and CSSOM created a rendering tree, which is a set of rendered objects (Webkit calls them "renderer" and "render object" respectively ", the Gecko engine is called "frame "). Except for invisible elements (such as the head label and some elements with the display: none attribute), the rendering tree maps the DOM structure. In the rendering tree, each text string is treated as an independent renderer. Each rendered object contains the corresponding calculated DOM object (or a text block ). In other words, the rendering tree describes the intuitive representation of DOM.
- For each rendering element, its coordinates are calculated. This is called layout )". The browser uses a "stream method" that only needs to be processed once to layout all elements (tables needs to be processed multiple times ).
- Finally, the layout is displayed in the browser window. This process is called "painting )".
Redraw
When you modify some positioning styles (such as background-color, border-color, and visibility) on the page ), the browser will only re-draw the new style to the element (this is called a "re-painting" or "re-define the style ").
Rearranging
When changes on the page affect the content, structure, or element positioning of the document, the document will be rearranged (or "re-layout "). Shuffling is usually triggered by the following changes:
- DOM operations (such as adding, deleting, modifying, or changing the sequence of elements ).
- Content changes, including text changes in the Form.
- Calculate or change CSS attributes.
- Adds or deletes a style sheet.
- Change the "class" attribute.
- Browser window operations (change the size and scroll the window ).
- Activate pseudo-classes (for example, hover status ).
How does the browser optimize rendering?
The browser tries its best to restrict the rescheduling process to only the area of the changed element. For example, the size change of an element whose position is absolue or fixed only affects its own and its descendants, doing the same operation on an element whose position is static will cause the rearrangement of all elements after it. Another optimization is that when a piece of Jjavascript code is run, the browser will cache some modifications, and then execute these modifications at one time when the code is executed. For example, this code will trigger a re-painting and a re-arrangement:
As mentioned above, attributes accessing an element are forcibly reordered. If we add a line of code to the above Code to read the element attributes, this situation will occur: The result of the above Code is:
TwiceRearranging. Therefore, to improve performance, you should organize the code for reading element attributes (For details, refer to the Code on JSBin ). One case is that it must be triggered once.
Force reschedule. For example, to change the same attribute of an element twice (for example, margin-left), set 100px at the beginning without animation, and change the value to 50px in the form of animation. For more details, see the example. We start with a CSS class with transition:
Then implement: The above implementation does not run as expected. All the modifications are cached by the browser and will only be executed at the end of the code above. What we need is a forced rescheduling, which can be implemented through the following modifications:
Now this code is as expected.
Practical optimization suggestions
Some useful information is summarized. I suggest the following:
- Create valid HTML and CSS. Do not forget to develop the file encoding. The Style should be written in the head tag, and the script tag should load the end position of the body tag.
- Try to simplify and optimize the CSS selector (this optimization point is ignored by most developers who use the CSS Preprocessor ). Minimum number of nested layers. The following shows the top performance of the CSS selector (starting from the fastest ):
- ID selector: # id
- Class selector:. class
- Tag: div
- Adjacent sibling elements: a + I
- Parent element selector: ul> li
- Wildcard selector :*
- Pseudo class and pseudo element: a: hover, you should remember that the browser processing selector is from right to left, which is why the rightmost selector is faster -- # id or. class.
- Reduce DOM operations as much as possible in your script. Cache everything, including attributes and objects (if it can be reused ). When performing complex operations, it is best to operate an "offline" element (the "offline" element means that it is separated from the DOM object and only has elements in the memory ), then insert this element into the DOM.
- If you use jQuery, follow the jQuery selector best practices.
- To change the style of an element, modifying the "class" attribute is one of the most efficient methods. The deeper you want to change the hierarchy of the DOM tree, the more efficient this one will be (which also helps to separate the presentation from the logic ).
- As far as possible, only the elements whose position is absolute or fix are animated.
- It is a good idea to disable some complicated theme when rolling: hover animation (for example, adding a no-hover class to the body label.
