Page Rendering & Reflow Performance

by Warren Gaebel | Apr 13, 2012

Taxonomy of Tips presented a classification scheme for the many performance tips that abound on the Internet. The consensus seems to be that initial page rendering (category #5) and after-the-fact reflow (category #6) affect performance more dramatically than any other category. Today’s article provides a basic understanding of rendering and reflow.JavaScript can execute before the page is fully loaded, after the page is fully loaded, or both. JavaScript that is executed before the page is fully loaded affects time to interactivity, which is arguably the most important performance measurement.JavaScript that is executed after the page is fully loaded can cause page reflows, where the page suddenly changes its layout right in front of the user’s eyes. If the user is reading or interacting with the page, he must immediately stop and wait for the page to render one more time. If he is not expecting this reflow, it can be quite annoying.

Repaints are not such a big problem, but they are a distraction. A repaint affects the appearance of some rectangular area within the page, but does not cause a reflow of the entire page. A repaint can still derail the user’s train of thought, but not as severely as a reflow does.

Reflow is sometimes called reload or relayout. Repaint is sometimes called redraw. A reflow will cause a repaint, but a repaint will not cause a reflow.

Understanding the page rendering process is essential for anyone who wants to get a handle on client-side performance issues. Simply applying tips without understanding how they work can be a fruitless endeavour.

The following reference section contains a few best-of-the-best articles that help us understand page rendering (especially reflow). These articles are so well written that I cannot present a better explanation. The most useful thing I can do is point you to them, which I do now.

References

Rendering: repaint, reflow/relayout, restyle

by Stoyan Stefanov. Published 2009.12.17 by Stoyan Stefanov. Accessed 2012.04.11.

This is the best explanation of rendering, repaints, reflows, redraws, restyles, relayouts, resizing, reformatting, requesting style info, and whatever other R words Stoyan can come up with. It provides a detailed explanation of the rendering process, including the difference between the DOM tree and the render tree, and the difference between a reflow and a repaint in terms of its impact on the render tree. It lists and demonstrates reflow/repaint triggers (and cautions us not to be trigger-happy).

After acknowledging that modern browsers are smart enough to batch reflows, it advises that the programmer should batch reflows himself for even better performance and warns us that querying style and layout information can eliminate the benefits of batching.

Perfection Kills

by Juriy Zaytsev. Published 2012.01.04 by Juriy Zaytsev. Accessed 2012.04.11.

This article recounts the author’s experiences while optimizing a one-page web application that uses lots and lots of CSS3. It details his performance results, including measurements, and ends with a few tips regarding CSS’s impact on reflow. Some of these tips are new. Did you know that page zoom affects CSS performance?

Reflows & Repaints: CSS Performance making your JavaScript slow?

by Nicole Sullivan. Published 2009.03.27 by Nicole Sullivan. Accessed 2012.04.11.

This article distinguishes between reflows and repaints, lists some of the things that cause a reflow, and describes six tips for minimizing the number or impact of reflows. The See It In Action section provides links to videos that help us visualize the reflows associated with loading Google’s, Mozilla’s, and Wikipedia’s web pages.

Writing Efficient JavaScript: What Makes JavaScript Slow and What To Do About It

by Nicholas C. Zakas. Published 2009.06.13 by Nicholas C. Zakas. Accessed 2012.04.11.

Pages 67-95 of this slideshow demonstrate how to avoid reflows and optimize DOM-tree interactions. The code samples are especially helpful.

Tip Summary

This is a quick summary of the tips included in the above articles. For a full discussion, please read the articles. I’m begging you … please read the articles. And if you’re going to skimp, read the first ones first.

• Whenever possible, avoid changing anyformatting after the initial page load.
• Whenever possible, use static CSS instead of dynamic CSS.
• Don’t include CSS rules in the HTTP reply stream if they are not used on the page.
• Use fixed or absolute positioning as much as possible, especially for animations.
• Avoid using HTML tables for layout.
• In animations, reduce the frames per second as much as possible.
• Avoid asking for layout information. If you must, cache the value rather than asking a second time.
• Batch DOM changes and apply them all at once.
• Make changes as low in the DOM tree as possible.
• Keep in mind that HTMLCollection objects rerun a query every time you access them. Whenever possible, cache the HTMLCollection in an array for future use.
• Page zoom affects layout performance. Depending on the browser, resizing the window may also affect layout performance.
• Use as few CSS selectors as you can.
• Avoid universal and multi-class CSS selectors.
• Beware the performance of pseudoselectors.
• Avoid setting multiple inline styles.
• Change class names instead of styles.
• Avoid dynamic styles, but if you must use them, change the cssText property instead of the element’s style property.
• The border-radiusCSS property may be affecting repaint performance more than you think.
• In Internet Explorer, do not use JavaScript expressions within CSS.

And one additional tip from yours truly: Invest in the slowest, least advanced computer available on the shelves. Use it for testing your webapps.