Repaint and Reflow#

Repaint and reflow are operations performed during browser rendering. When the content on a page changes, it triggers a repaint or reflow.

Repaint#

When some elements in the render tree need to update their properties, and these properties only impact the appearance and style of the elements without affecting the layout, such as background-color, it's called a repaint. Repaint does not necessarily trigger a reflow.

Reflow#

When a portion (or all) of the render tree needs to be reconstructed due to changes in the size, layout, or visibility of elements, it's called a reflow. Some also refer to it as restyling, which can be understood as a layout change. Every page requires at least one reflow, which occurs during the initial page load, triggering a repaint as the render tree is constructed. Reflow is far more costly than repaint. Each node in the DOM Tree has a reflow method, and a node's reflow can likely cause reflows for its child nodes, parent nodes, and even sibling nodes. While reflows might not be an issue on high-performance computers, they can cause lag and battery drain on mobile devices.

Triggers#

• When modifying CSS styles
• When altering the default font of a webpage
• When adding, removing, or modifying DOM nodes
• When resizing the window or scrolling
• When moving DOM positions or animating

Optimization#

Browser Optimization#

Browsers come with built-in optimization methods. They accumulate repaint and reflow operations and perform an asynchronous reflow or incremental asynchronous reflow when a certain number of operations are reached or a time threshold is met. However, there are cases where the browser does not utilize these optimizations, such as window resizes or changes to the default page font. For these operations, the browser immediately initiates a reflow.

Minimize Operations#

Since repaint and reflow can be costly, it's best to reduce their occurrence. To minimize occurrences, multiple DOM and style modifications can be combined and handled at once, or styles can be pre-designed and dynamically changed via classes.

Offline DOM Modification#

Use the documentFragment object to manipulate the DOM in-memory. Modifying the DOM in memory detaches the elements from the document flow, thereby not triggering a repaint. All modifications to the DOM can be batched, making it possible to make any necessary changes and then place the node back into the document flow, only triggering one reflow.

Absolute Positioning#

For complex animation effects, frequent reflows and repaints can be avoided by using absolute positioning to detach elements from the document flow. Otherwise, it would cause frequent reflows for parent elements and subsequent elements.

Avoid Multiple Inline Styles#

Dynamically setting styles through the style attribute operates on a small DOM fragment, which can lead to multiple reflows. Avoid setting multiple levels of inline styles; instead, merge the styles into an external class. This way, when the class property of an element can be controlled, it only results in one reflow.

Terminal Operations#

Where possible, change the class of nodes at the terminal or lower levels of the DOM tree. Reflows can propagate from top to bottom or bottom to top and affect surrounding nodes. Reflow is unavoidable, but its impact can be minimized. Modifying nodes at the terminal or lower levels can limit the scope of the reflow, reducing its impact on other nodes, although it can also potentially trigger widespread reflows.

Smoothness versus Speed#

Opera also advises sacrificing smoothness for speed, meaning that animating each 1-pixel movement may lead to a subsequent reflow using 100% of the CPU, causing the animation to appear jumpy as the browser battles with updating the reflow. Moving the animation element by 3 pixels each time may result in decreased smoothness on very fast machines, but it won't cause the CPU to jitter on slower machines and mobile devices.

Avoid TABLE Layout#

Before the layout is fully established, table often requires multiple checkpoints, as it's rare for elements that appear after the table to be affected by elements that have already entered the DOM. Consider how a change in the content of the last cell of a table might completely alter the column size. This is why all browsers are gradually discontinuing support for rendering table layouts. There's another reason why table layouts are a bad idea: even slight changes can trigger reflows for all other nodes within the table.

CSS3 Hardware Acceleration#

CSS3 hardware acceleration, also known as GPU acceleration, can make transform, opacity, filters and other animations not cause reflow or repaint. However, for other properties of the animation, such as background-color, they still cause reflow and repaint, but it can still improve the performance of these animations. However, there are also some issues, if css3 hardware acceleration is used for too many elements, it will lead to high memory usage and performance issues. Rendering fonts on the GPU can make anti-aliasing ineffective. This is because the algorithms of the GPU and CPU are different. Therefore, if hardware acceleration is not turned off at the end of the animation, it will cause font blurring.

Debugging#

In the developer tools of many browsers, performance analysis of rendering operations is provided. Taking Google Chrome as an example, its performance tool can be used to view the performance consumption of each construction process. In Rendering, it can use Paint flashing to highlight the repainted area, Layout Shift Regions to highlight layout changes in the interactive page, and FPS meter to display frame rate to conduct performance analysis tests.

Daily Question#

References#