× {{alert.msg}} Never ask again
Get notified about new tutorials RECEIVE NEW TUTORIALS

How can CSS have a significantly negative effect on page paint time in a specific area of a web page?

Zach Saucier
Feb 02, 2015
<blockquote> <p>I didn't know CSS took effect based on the user's location in the page. Does this behavior determine that it does?</p> </blockquote> <p>It absolutely does because the browser doesn't want to render everything on a page at once. Therefore the spots of the page (if any) that require more to process will be slower than spots that take less to process.</p> <blockquote> <p>Is there conflicting or unusual CSS positioning, animation, etc. that might cause poor performance?</p> </blockquote> <p>Since this is a very broad question I'll answer it more broadly than I usually would. Here's an article on <a href="http://blogs.adobe.com/webplatform/2014/03/18/css-animations-and-transitions-performance/" rel="nofollow">what happens during an animation</a> which covers in fair detail what is happening behind the scenes. In essence it says there is a main thread and compositor thread; you want to stay on the compositor side for most of the time. This is precisely the reason why <a href="http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/" rel="nofollow">certain properties</a> can "animate cheaply" without the browser having to do too much.</p> <p>Other reasons that I can think of that would cause more poor performance than usual is if an element's animation or transformation can affect the layout or state of other elements that are not a part of the animation or transformation. It's important to prevent elements being animated or transformed from affecting other elements, especially their layouts, as this forces them back onto the main thread.</p> <blockquote> <p>How is CSS styling directly and consistently linked to page performance? Specifically, page paint time.</p> </blockquote> <p>CSS is related to page performance in a several ways. The first is in how much time it takes for the compiler to read the CSS and to apply it to the elements necessary. <a href="http://csswizardry.com/2011/09/writing-efficient-css-selectors/" rel="nofollow">Writing efficient selectors</a> is important if you're dealing with large stylesheets in particular. You want to cut corners wherever possible.</p> <p>The second place CSS effects performance is how elements are positioned. If you position 1,000 elements in the same position, it will naturally perform worse than if you have 1 in the same location, regardless of how many can be seen or affect the layout. This is not <em>wholly</em> related to CSS, but CSS positioning is what determines where the elements are, thus how many are affecting performance at once. Changing the layout of elements puts it back into the main thread, which forces more thought on the processor's part in addition to repainting.</p> <p>The third that you specify in your question is paint time. The <a href="http://www.html5rocks.com/en/tutorials/speed/css-paint-times/" rel="nofollow">article you linked</a> goes into it well, explaining that <strong><code>box-shadow</code> <em>stinks for paint time</em></strong>. There are <a href="http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/" rel="nofollow">lot's</a> <a href="http://stackoverflow.com/questions/1249619/scroll-lag-with-css3-box-shadow-property">of</a> <a href="http://stackoverflow.com/questions/4789853/css3-box-shadow-causes-scroll-lag-slow-performance-on-safari-5-0-2">reports</a> of this because it exists. This is the essence of your specific problem; the main cause. You should <strong>avoid them</strong>, especially in bulk, whenver you can. Using gradients instead will likely improve the paint times because they're less expensive. </p> <p>The fourth is that CSS determines whether or not an animation or transition is rendered using the CPU or the GPU. Although we don't have the feature yet, <a href="http://dev.opera.com/authors/sara-soueidan/" rel="nofollow">Sara Soueidan</a> in <a href="http://dev.opera.com/articles/css-will-change-property/" rel="nofollow">her article on the <code>will-change</code> property</a> delves fairly deeply into this. In summary, the CPU (Central Processing Unit) is the brains of the computer and takes longer to render things while the GPU (Graphics Processing Unit) is faster at rendering things, but can't "think" as much. At the moment we do tricks like <code>translate3d(0, 0, 0);</code> or <code>translateZ(0px)</code> to force the browser to render it with GPU, but in the future we will have the <code>will-change</code> property. </p> <p>As Sara says in the article, <strong>don't make the GPU handle everything</strong>, as the browser is processing it as best as it can, and "some of the stronger optimizations that are likely to be tied to <code>will-change</code> end up using a lot of a machine’s resources, and when overused like this can cause the page to slow down or even crash."</p> <hr> <p>In summary, CSS can significantly negative effect a page's paint time in a specific area of a web page by increasing paint times, changing the way elements are laid out, forcing too many elements to be processed in the CPU or GPU, and how long it takes the compiler to interpret and apply the CSS.</p> <p><a href="http://stackoverflow.com/questions/24048653/how-can-css-have-a-significantly-negative-effect-on-page-paint-time-in-a-specifi/24213761#comment37081748_24050275">BoltClock</a> was spot on when he commented,</p> <blockquote> <p>box shadows typically are one of the most expensive to render in most any browser. There is almost no reason to have such a large spread - you might as well use a gradient or something ;)</p> </blockquote> <hr> <p>If your page or part of your page is running slowly, it's best to <a href="http://addyosmani.com/blog/devtools-visually-re-engineering-css-for-faster-paint-times/" rel="nofollow">look into</a> it further to find out what, if anything, is being repainted </p> <p>This tip was originally posted on <a href="http://stackoverflow.com/questions/24048653/How%20can%20CSS%20have%20a%20significantly%20negative%20effect%20on%20page%20paint%20time%20in%20a%20specific%20area%20of%20a%20web%20page?/24213761">Stack Overflow</a>.</p>
comments powered by Disqus