12

The Question:

An invaluable article on the issue - mentioned by JackPattishallJr.

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

For example:

  • I didn't know CSS took effect based on the user's location in the page. Does this behavior determine that it does?

  • Is there conflicting or unusual CSS positioning, animation, etc. that might cause poor performance?

  • How is CSS styling directly and consistently linked to page performance? Specifically, page paint time.

Update: I've edited the question and examples based on two tests I just did:

  1. Without javascript enabled in my browser, the poor performance issue (surprisingly) is consistent.

  2. After removing the styling of the problematic area, the issue is resolved (But not quite, because now my page is ugly).


Issue with Page Paint Time

I've noticed that my webpage was performing poorly (laggy) at one specific area on the page.

To study the issue, I enabled show paint rectangles and enable continuous page repainting in order to get some readings on the page repaint rate.

Here's a Youtube video that I took to demonstrate the issue.

Here's a healthy reading, in the area of my page that is responsive and smooth:

enter image description here

Here's an unhealthy reading (in the problematic area), where the page's responsiveness is slow and the scrolling is very laggy:

enter image description here

The page performs perfectly, with healthy repainting rates at the top (where the most activity is going on, actually), and performs terribly (nearly stops) at a lower area of the page. It returns to perfect performance when I scroll away from the problematic area.

Update: I completely disabled Javascript and got the same performance issue and readings as before.

  • Almost certainly a Javascript problem. Did you run the [profiler](https://developer.chrome.com/devtools/docs/cpu-profiling)? Usually the Flame Chart helps a lot – user123444555621 Jun 04 '14 at 23:00
  • I disabled Javascript in my browser, and get the same performance issue and readings as before. This is not scripting based, then, I would assume... @Pumbaa80 –  Jun 04 '14 at 23:54
  • @jt0dd I tried signing up but got an error that the server was down. I was curious if you looked at CSS being the issue? (Certain CSS3 properties can be very taxing...) – Jack Jun 05 '14 at 00:10
  • @JackPattishallJr. It looks like you're right. Removing all styling of the problematic area fixes the issue. Now I can add further detail to this question –  Jun 05 '14 at 00:16
  • 3
    @jt0dd - That's great! More than likely, the issue comes down to vendor-prefixed rules (-webkit-filter) or a combo of CSS3 rules (or specific values). Here's an article with more info: http://www.html5rocks.com/en/tutorials/speed/css-paint-times/ Good luck! – Jack Jun 05 '14 at 00:33
  • @jt0dd Here is a good article for debugging issues like this http://updates.html5rocks.com/2013/02/Profiling-Long-Paint-Times-with-DevTools-Continuous-Painting-Mode. Also I've faced a similar issue when I had a decent amount of large images downsized to fit a much smaller size. – Kirill Fuchs Jun 05 '14 at 01:28

3 Answers3

4

Thanks to JackPattishallJr.'s extremely helpful comments, the solution is almost comically simple, so I have recorded a video of the real-time fix for my my issue.

Watch as the removal of a single character of CSS changes everything, instantly.

Lesson learned. Never use a 2000 pixel box shadow. Ever. EVER.


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

CSS styling has a very advanced, direct relationship with page paint times, and this article by HTML5Rocks explains and demonstrates it well.

Basically, different style features (and certain combinations of them) have very serious effects on page render weight. This behavior can be observed clearly via the use of chrome's continuous page repainting feature.

If anyone can provide a more elaborative, insightful answer, please do.

Update: I've posted a bounty to promote an answer that will explain this issue in more detail. While the article explains things pretty well, it may not exist tomorrow, so a fully detailed answer is always much better (and often is of greater quality than source articles). And I have neither the time nor understanding necessary.

  • 5
    I don't have anything to say other than 1) lol 2) 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 ;) – BoltClock Jun 05 '14 at 02:37
  • Awww, what happened to the youtube video? It says "this video is unavailable" I was really interested in seeing that. – RustyToms Jan 29 '15 at 21:50
3

I didn't know CSS took effect based on the user's location in the page. Does this behavior determine that it does?

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.

Is there conflicting or unusual CSS positioning, animation, etc. that might cause poor performance?

Since this is a very broad question I'll answer it more broadly than I usually would. Here's an article on what happens during an animation 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 certain properties can "animate cheaply" without the browser having to do too much.

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.

How is CSS styling directly and consistently linked to page performance? Specifically, page paint time.

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. Writing efficient selectors is important if you're dealing with large stylesheets in particular. You want to cut corners wherever possible.

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 wholly 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.

The third that you specify in your question is paint time. The article you linked goes into it well, explaining that box-shadow stinks for paint time. There are lot's of reports of this because it exists. This is the essence of your specific problem; the main cause. You should avoid them, especially in bulk, whenver you can. Using gradients instead will likely improve the paint times because they're less expensive.

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, Sara Soueidan in her article on the will-change property 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 translate3d(0, 0, 0); or translateZ(0px) to force the browser to render it with GPU, but in the future we will have the will-change property.

As Sara says in the article, don't make the GPU handle everything, as the browser is processing it as best as it can, and "some of the stronger optimizations that are likely to be tied to will-change 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."


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.

BoltClock was spot on when he commented,

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 ;)


If your page or part of your page is running slowly, it's best to look into it further to find out what, if anything, is being repainted

Community
  • 1
  • 1
Zach Saucier
  • 24,871
  • 12
  • 85
  • 147
0

Since you have already addressed rasterizing, here's some more information on css performance.

1) Selectors

Here is a talk about some issues Github had with CSS, specifically with selectors and how they can impact page performance: http://vimeo.com/54990931 Slide version here: https://speakerdeck.com/jonrohan/githubs-css-performance

If you aren't careful, css preprocessors can generate some very long selectors, such as this one taken from Bootstrap's dist css:

.table > thead > tr > th,
.table > tbody > tr > th,
.table > tfoot > tr > th,
.table > thead > tr > td,
.table > tbody > tr > td,
.table > tfoot > tr > td {
  padding: 8px;
  line-height: 1.42857143;
  vertical-align: top;
  border-top: 1px solid #ddd;
}

2) Multiple instances of SVG XML

Recently I tried using SVG XML to draw and fill up 'star rating' widgets. This worked fine until I placed about 20 instances in page, and then some of them would randomly disappear and/or flicker on mouseover.

3) Using background-image inside a drop-down menu. The image isn't downloaded until the popup is clicked, which creates a noticeably slow load time for users on slow connections. Although the total time is exactly the same wherever you put the image, users noticed it more when the download time was after clicking. So I'm being careful about icons in dropdowns.

Jen
  • 1,663
  • 1
  • 17
  • 34