Wednesday, August 18th, 2010

When does JavaScript trigger reflows and rendering?

Category: CSS, Performance

Thomas Fuchs has some good performance things to say reflows and rendering. A video of wikipedia gives you an idea of how much happens when a basic page is rendered:

The advice?

The important thing is to always remember that reflowing and rendering HTML is the single most expensive operation browsers do. If your page feels sluggish it’s most likely a problem with rendering. While the easiest way to optimize is to get rid of as many nodes as you can, and trying to have simpler CSS rules, sometimes JavaScript is the culprit.

Following changes to the page, a Javascript query like someElement.offsetHeight will block execution – to give you the right answer, any pending reflow has to be executed first. So code like this:


  1. = "14px";
  2. if(someElement.offsetHeight>100){ /* ... */ }
  3. = "20px";
  4. if(someElement.offsetWidth>100){ /* ... */ }

could be twice as fast if you wrote it like this:


  1. = "14px";
  2. = "20px";
  3. if(someElement.offsetHeight>100){ /* ... */ }
  4. if(someElement.offsetWidth>100){ /* ... */ }

because there are two reflows in the first example, and only one in the second.

Posted by Michael Mahemoff at 6:26 am

4 rating from 4 votes


Comments feed TrackBack URI

Very simple article for beginners.

Comment by GreLI — August 18, 2010

Basically, keep DOM manipulations to a minimum, right? Use class names (to *minimize* reflow) instead of style objects. Utilize documentFragment instead of the old school looping/adding each iteration (reflow) or add your loop iterations to a string and then add that string to the DOM.

Comment by cancelbubble — August 18, 2010

Stoyan Stefanov has some related findings on Chrome vs. IE layout behaviours when changing class names, setting display and so on – “Will it reflow?”

Comment by Schill — August 18, 2010

Sorry, but I don’t understand why there are 2 reflows in the second code and one in the first.
The fact is that I probably don’t understand what ‘reflow’ really is.
Thx for any hints.

Comment by Antheor — August 18, 2010

great tutorial!

Comment by stoimen — August 19, 2010

cancelbubble: no, this isn’t about DOM manipulation (although that costs for other reasons). The expensive thing here is that when you read back a style value, you force the browser’s hand: it HAS to immediately and synchronously do recalculation about the document flow, match styles, etc. This is all work that was going to be done anyway, but in this case, you’re making it synchronous with your script and THAT can slow things down. The lesson here is not to avoid DOM operations, but to avoid *reading computed style values*. That, or tie them to an onresize handler when you know that layout has been recently computed.

Comment by slightlyoff — August 19, 2010

very nice javascript performance tip and good comments.

thanks a lot

Comment by ejsmont — August 20, 2010

Schill: In the first example the document is modified, the position of an element is requested so it must immediately reflow (& halt the script/browser while doing so), the document is then modified again, & a position requested once more (so yet another blocking reflow must occur)
In the second example there are two modifications (but no queries, so the browser isn’t required to actually reflow the page yet). If the document has not reflowed yet by the time it reaches the first offsetHeight query then it will block, but this means the state is guaranteed to be current when it reaches the second query.
So at maximum there will be 2 reflows from the first example, but only 1 from the second.
In summary: do as many layout-modifying changes in batch as possible, before you make any calls that then query that modified state in order to guarantee a minimum number of reflows & the best possible performance of the page

Comment by ProPuke — August 23, 2010

exciting tips and helpful comments, thanks a lot,.

Comment by allex — June 17, 2011

Leave a comment

You must be logged in to post a comment.