Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.
Like Joseph Smarr said, Performance is something that you need to take seriously from the day one. If you don’t, may be too late when you find out.
Watch your DOM
Reflow is one of the most expensive functions of a browser. This is a far more significant change. The reflow happens when:
- When you add or remove a DOM node.
- When you apply a inline style.
- When you get a measurement or info that must be calculated, such as accessing offsetWidth, clientHeight, or any computed CSS value (via getComputedStyle() in DOM-compliant browsers or currentStyle in IE), while DOM changes are waiting to be made.
Doing any of these examples above, the engine must then reflow all the related elements to work out where the various parts of it should now be displayed. Its children, Ancestors and all the elements that appear after it in the DOM tree, will alson be reflowed to calculate their new layout, as they may have been moved by the initial reflows. After all this processes, finally, everything is redrawed.
Visualize some Redraw and Reflow
This videos, show how the Redraw and Reflow process works on the web browser.
Good with them, better off without them.
Reflows and Redraws, affect the whole widget performance, because they affect the whole document. The more it happens, the longer the document will take to make all the changes.
Tough animations, transitions and stuff are all based on reflows, we still want them to make our app prettier. That makes reflows something, that developers should keep at minimum, as long as they want to make their scripts running fast.
Notice that some elements have significantly slower reflows than others. Reflowing an element with table display, can take as much as three times as long as reflowing an equivalent element with block display
How to get rid of them
Another common source of multiple reflows is making changes to an element’s appearance via the Style (CSS in case you're usign jQuery) property. For example:
//Style Changes using jQuery
/*The same changes now are in the CSS*/
Changing the class of an element counts allows all of the styles to be applied at once, within a single reflow. This is much more efficient and also more maintainable in the long run.
Apply animations to elements fixed or absolute.
Elements which are positioned as Fixed or absolute don’t affect the document or other elements layout, so they will only cause a repaint instead of a total reflow. This is much lighter and better for your widget.
Trade smoothness for speed
Means that you should choose the best option for your user. As tempting as making a smooth animation transition can be, you should set them to animate the fastest as you can. Instead of seting the transition animation using a 1 pixel(10ms) at a time you shoul try something less smooth, like a 5 pixels (50ms).
It can be neccessary to swallow the developer pride, and trade some of the smoothness of the animation for speed instead. The sophisticated animations, may make your widget look slow, because it will need much more processing power. That is a bad response to the user. I recomend you to use the simple Hide/Show jQuery Solution, which is a less smooth solution, but is the fastest response your user can get on lower powered processors.
- [Lindsey Simon wrote a bookmarklet for you to test reflows in any browser. http://ua-profiler.appspot.com/reflows/]
- [John Resig's bookmarklet to visualize paint events. http://ejohn.org/blog/browser-paint-events/]