Browser Reflows & Repaints

Notes on HTML Reflow

All reflows have a reason, which is maintained in the reflow state object (and may mutate, as described below). The reflow reason controls how a frame reacts during a reflow, and is one of the following:
* Initial, for the very first time that the frame hierarchy is flowed. In this case, a frame knows that there is no residual state that can be used to simplify geometry computation.
* Incremental, when something in the frame tree changes; for example, when more content is read from the network, or some script manipulates the DOM. An incremental reflow is targeted at a single frame in the frame hierarchy. During an incremental reflow, a frame can assume that none of the constraints computed ``from above'' (for example, available width) have changed; instead, something ``within'' the frame has changed, which may have bottom-up impact to the frame hierarchy.
* Resize, when the containing boundary for the frame hierarchy changes. During a resize reflow, the frame can assume that none of the frame's internal state (e.g., a text frame's text) has changed; instead, a top-down change in the layout constraints has occured.
* StyleChange, when the entire frame hierarchy must be traversed to recover from stylistic change; for example, a change in the default font size.
* Dirty, when a container frame has consolidated several individual Incremental reflows that have been targeted at its child frames.

Ajaxian » Browser Reflows & Repaints; How do they affect performance?
Stubbornella » Blog Archive » Reflows & Repaints: CSS Performance making your JavaScript slow?

Avoid tables for layout. As if you needed another reason to avoid them, tables often require multiple passes before the layout is completely established because they are one of the rare cases where elements can affect the display of other elements that came before them on the DOM. Imagine a cell at the end of the table with very wide content that causes the column to be completely resized. This is why tables are not rendered progressively in all browsers (thanks to Bill Scott for this tip) and yet another reason why they are a bad idea for layout. According to Mozilla, even minor changes will cause reflows of all other nodes in the table.

The biggest performance problem with reflows is accidentally causing an excessive number of them. This happens when you constantly change something and then query for geometry.

For example if you do:

element.style.width = ‘50px’;
var v = element.offsetWidth;
element.style.width = ‘55px’;
v = element.offsetWidth;

You just caused two reflows to happen, since asking for offsetWidth forced the element to reflow in order to answer you question (because it had a pending change to style).

This is the real performance bottleneck to be wary of. Browsers are smart about avoiding reflows when they can, but if you create code that forces a reflow in order to answer a question, then you can create severe performance bottlenecks.

In some cases, browsers reflow to answer the question even when they don’t need to. This is the case in WebKit with getComputedStyle for example (even if you ask for some style info that has nothing to do with geometry), so that’s something to watch out for in WebKit.

Basically a reflow/repaint isn’t that bad by itself, but your goal should be to minimize the # of them that occur.