What is Layout Thrashing?
What causes Layout Thrashing?
Web browsers are lazy and will try to minimize the work required to draw the page. They do this by putting operations that require a reflow into a queue to execute at some point in the future. When required, the browser will execute everything in the queue as a single reflow. But sometimes we don’t allow the browser to be lazy. If our script requests style information such as offsetWidth or scrollTop, the only way that the browser can be sure to return the correct answer is to execute any reflow operations that are in the queue. This means that whenever we request some layout information, we could potentially be forcing a page reflow.
How to detect Layout Thrashing:
The best way to find out if you are causing layout thrashing is to profile your page load. For those unfamiliar with programming, to ‘profile’ something basically means to measure how long your code takes to execute and to allow you to find out which pieces of your code take the longest time. I have found that one of the best tools for profiling web page loading is actually Google Chrome. In Chrome, press F12 to bring up the Developer tools, and then select the ‘Timeline’ tab. In the top left is a grey circle – if you hover over this it will say record. Press this button, reload your web page and then press this button again to profile your page. If your timeline looks anything like the screenshot above then you have a problem. If your timeline looks more like the screenshot below, then you’re probably OK.
Wilson Page has an excellent article that discusses layout thrashing and explains his FastDom library, aimed at speeding up DOM work.
Stoyan Stefanov has a fantastic article that covers (at great depth!) browser rendering (repainting, reflow/relayout and restyling).
Bobby Grace has a really nice article that explains how he made Trello go from 7.2s to load a large board to just 960ms.