The web page generation process

  • HTMLCode conversion toDOM
  • CSSCode toCSSOM (CSS Object Model)
  • In combination withDOMandCSSOM, generate a render tree (containing visual information for each node)
  • Generate layout (layout), that is, all nodes of all render trees are planar composited
  • Draw the layout (paint) On the screen

The most time-consuming is in the fourth and fifth steps to generate the flow and paint, collectively called render.

When rearranging and redrawing pages are generated, they are rendered at least once. As the user visits, it is constantly re-rendered. Modifying the DOM, modifying the stylesheet, and user events (hovering, scrolling, entering text in the input box, resizing the window, etc.) all cause the page to be re-rendered. To rerender, you need to regenerate the layout and redraw. The former is called reflow; the latter is called repaint. Redrawing doesn’t have to be rearranged. Changing the color of an element, for example, will only trigger redrawing because the layout hasn’t changed, but rearranging will definitely cause redrawing. Changing the position of an element, for example, will trigger both rearrangement and redrawing because the layout has changed. Improving web performance means reducing the frequency and cost of rearranging and redrawing, and triggering rerenders as little as possible. Today, browsers are smart enough to try to cluster all changes together in a single queue, and then execute them all at once, avoiding multiple rerenders. But a style write followed by a read with the following attributes causes the browser to immediately rerender

  • offsetTop/offsetLeft/offsetWidth/offsetHeight
  • scrollTop/scrollLeft/scrollWidth/scrollHeight
  • clientTop/clientLeft/clientWidth/clientHeight
  • getComputedStyle()

General rules for rendering

  • The simpler the stylesheet, the faster the rearrangement and redrawing
  • Rearranged and redrawnDOMThe higher the element level, the higher the cost
  • tableRearrangement and redrawing of elements is higher thandivThe element

Nine tips for Improving performance

  • DOMMultiple read operations, or multiple write operations, should be placed together. Do not add a write operation between two read operations.
  • If a style is rearranged, it is best to cache the result so that the browser does not have to rearrange it the next time it is used.
  • Don’t change styles one by one, go throughclassorcsstextProperty to change the style once and for all
  • Use offline whenever possibleDOM“, rather than the actual net surfaceDOMTo change the element style. For example, operationsDocument FragmentObject, and then add that object when you’re doneDOM. Another example is usingcloneNode()Method, perform operations on the cloned node, and then replace the original node with the cloned node.
  • Let’s set the element todisplay: none(requires 1 rearrangement and redraw), then perform 100 operations on the node, and finally restore the display (requires 1 rearrangement and redraw). That way, you have two re-renders instead of maybe 100.
  • positionThe property is Absolute orfixedThe rearrangement will be less expensive because there is no need to consider its effect on other elements
  • Use the element only when necessarydisplayProperty is visible because invisible elements do not affect rearrangement and redraw. In addition,visibility : hiddenElements of are only affected by redrawing, not rearrangement.
  • Using the virtualDOMScript library, such asReactAnd so on.
  • usewindow.requestAnimationFrame(),window.requestIdleCallback()These two methods regulate re-rendering

Refresh rate Most of the time, intensive re-rendering is unavoidable, such as the scroll event callback function and web animation. Every frame of web animation is a re-rendering, less than 24 frames per second, the human eye can feel the pause, the general web animation, need to reach 30 and 60 frames, to compare the flow, if it reaches more than 70 frames per second, it will be extremely smooth,60 frames means 60 times of redrawing in a second. Each rerender cannot take more than 16.66 milliseconds. The number of rerenders that can be done in a second is known as the refresh rate FPS. To achieve a refresh rate of 60 frames means that the JavaScript thread must take less than 16 milliseconds per task. One solution is to use a Web Worker, where the main thread is only used for UI rendering, and all tasks unrelated to UI rendering are placed on the Worker thread. Timeline panel the Timeline panel provides two viewing modes: the horizontal bar is “Event Mode”, which displays the elapsed time of various events that have been re-rendered; The vertical bar is Frame Mode, which shows where each Frame is spent. Web performance optimization scheme using Windows. RequestAnimationFrame (), it can put some code in the next to render, to read and write operation, put all writes in the next to render. Use Windows. RequestIdleCallback (), which specifies only when have free time, at the end of a frame of will implement the callback function. Window. RequestIdleCallback (() = > {}) only when the current frame of the running time is less than 16.66 ms, function. Otherwise, it is postponed to the next frame, and if there is no free time for the next frame, it is postponed to the next frame, and so on. Window. RequestIdleCallback (() = > {}, 5000) it can also accept the second argument, says the number of milliseconds specified. If there is no free time in each frame within the specified period of time, the function is enforced.