Wednesday, August 18th, 2010
When does JavaScript trigger reflows and rendering?
Category: CSS, Performance
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:
JAVASCRIPT:
-
-
someElement.style.fontSize = "14px";
-
if(someElement.offsetHeight>100){ /* ... */ }
-
someElement.style.paddingLeft = "20px";
-
if(someElement.offsetWidth>100){ /* ... */ }
-
could be twice as fast if you wrote it like this:
JAVASCRIPT:
-
-
someElement.style.fontSize = "14px";
-
someElement.style.paddingLeft = "20px";
-
if(someElement.offsetHeight>100){ /* ... */ }
-
if(someElement.offsetWidth>100){ /* ... */ }
-
because there are two reflows in the first example, and only one in the second.
Related Content:
3.7 rating from 3 votes
Very simple article for beginners.
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.
Stoyan Stefanov has some related findings on Chrome vs. IE layout behaviours when changing class names, setting display and so on – “Will it reflow?”
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.
great tutorial!
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.
very nice javascript performance tip and good comments.
thanks a lot
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
exciting tips and helpful comments, thanks a lot,.