Revisiting page rendering optimization of efficient front-end

The first thing I still have to mention is the "processing after the client gets the HTML":

• Parse HTML documents from top to bottom to generate a DOM tree;
• Load the analytical style to build the CSSOM tree;
• Load and execute JavaScript code;
• Generate a render tree based on the DOM tree and CSSOM tree;
• Rendering
• layout;
• draw

We may have heard many times: "Reflow and redraw as much as possible, because they will affect browser performance."
But why?

In fact, a page is composed of many layers (just like a layer cake)-the "layer" here refers to the "DOM element rendering layer (Layer)". A page has gone through a "special process" after constructing the render tree to displaying it in front of us:

1. The browser will first obtain the DOM tree and divide it into multiple independent rendering layers according to the style
2. The CPU draws each layer into a carry map
3. Upload the bitmap as a texture to the GPU (graphics card) for drawing
4. The GPU caches all the rendering layers and composites multiple rendering layers to finally form our image (if the rendering layer uploaded next time does not change, the GPU does not need to redraw it)

(: From the above steps, we can know that the layout is processed by the CPU, and the drawing is done by the GPU .
As this picture says (from the Layers hierarchy of the 3D View plug-in of Firefox)

The problem occurs in steps 2 and 4 of the above-mentioned process. Think about it: if we bring up those elements that are subject to complex movements/changes or that have been undergoing a lot of rearrangement and redrawing, and trigger them on a separate rendering layer, then it will not affect other elements!

So under what circumstances will the rendering layer be triggered?
For example video, WebGL, Canvas, CSS3 3D, CSS滤镜, z-index大于某个相邻节点的值elements will trigger new Layer - here to understand one thing: it is not only refers to the z-index! Here I highly recommend Zhang Xinxu’s article: In- depth understanding of the stacking context and stacking order in CSS. The
simpler way is to add the following styles to the elements:

transform: translateZ(0);
backface-visibility: hidden;

We separate the elements that easily trigger rearrangement and redrawing to trigger the rendering layer separately, isolate it from those "static" elements, and let the GPU share more rendering work. We usually refer to such measures as hardware acceleration or GPU acceleration. You must have heard this statement before-like in CSS will-change.

Whether it is reflowing or redrawing, it will block the browser. To improve web page performance, it is necessary to reduce the frequency and cost of rearrangement and redrawing, and re-rendering may be triggered less frequently. As we mentioned above: the rearrangement is processed by the CPU, and the redrawing is handled by the GPU. The processing efficiency of the CPU is far less than that of the GPU , and the rearrangement will definitely cause redrawing, and the redrawing will not necessarily cause the rearrangement. . Therefore, in performance optimization work, we should focus more on reducing the occurrence of rearrangements.

---

What else can be optimized?

1. CSS property reading and writing separation: When the browser does not read the element style every time, it must be re-rendered (reflow + redraw), so when we use JS to read and write the element style, it is best to combine the two Separate the readers, read first and write later to avoid cross-use of the two
2. By switching or class style.csstextattribute style element to batch operation
3. DOM element offline update: when the DOM related operations, for example, appendChildand so can use documentFragmentthe object off-screen operation with elements of "assembly" is inserted after the completion of a page or the use display:noneof hidden elements, the elements in the "disappeared" Related operations, and then display
4. visibility: hiddenIt's a good thing. It has both display hiding and opacity space. And it also supports moving animation
5. Specify the size of the image before rendering: Because the img element is an inline element, the width and height will be changed after the image is loaded. In severe cases, the entire page will be rearranged, so it is best to specify its size before rendering or leave it out Document flow