We have some of universal and non-direct descendant selectors in the CSS. I believe we can speed up reflowing in general by eliminating unnecessary specificity.

(In reply to Doug Sherk (:drs) from comment #0) > We have some of universal and non-direct descendant selectors in the CSS. I > believe we can speed up reflowing in general by eliminating unnecessary > specificity. Actually this is going to speed up all kind of interactions, +1 :)

I think we should especially have more classes and less compound selectors. I don't really mind about non-direct descendants by itself if this is only 2 parts, but we have compound selectors with like 4 parts, and 2 IDs. I'm all for removing IDs in the CSS too. This is gonna be hard and better do it panel by panel.

Here are my two cents: I think we can start from splitting huge sms.css file into more panel-specific files, at least composer, inbox, thread and etc... and optimize it one by one.

Yep, definitely. All common things should be building blocks already.

+1 To Julien's comment in #2, removing all the tag and descendant selectors and moving towards single class names as much as possible will really speed up selection time.

Okay, I did some looking into this, and suffice it to say I think this is a bust, at least from the perspective of performance. There's definitely some sanity issues, including duplicated styles, bizarre selectors, etc., but I don't think that it's a good use of our time at this point to tackle them. For starters, I did some research into this. Here are some of the articles I read and a talk I listened to: [1] http://dbaron.org/talks/2012-03-11-sxsw/slide-1.xhtml (slides) / http://audio.sxsw.com/2012/podcasts/11-ACC-Fast_CSS_How_Browser_Layout.mp3 (audio) [2] http://calendar.perfplanet.com/2011/css-selector-performance-has-changed-for-the-better/ this article is written about WebKit, but we have since implemented almost everything in it [3] http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/ [4] https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS The older articles give specific optimization tips which involve the things already mentioned in this thread, while the newer ones and the talk mostly focus around eliminating overly generic selectors (such as universals). They also allude to this not actually being worth the time spent to optimize in a lot of cases. In particular, after listening to David's talk [1], I chatted with him on IRC, and he told me that the new bloom filter that we've implemented in Gecko [2] has eliminated most of the gains we can get by reducing complexity of selectors. Still, I decided to try doing some optimizations to see what happened. The attached patch includes some really obvious optimizations that could be made. I profiled with and without this, and here are the results: without patch: http://people.mozilla.org/~bgirard/cleopatra/#report=19967db6979ea1f56dce9ffa333e3b0493510e20 with patch: http://people.mozilla.org/~bgirard/cleopatra/#report=bcfdbcd7b02bb6877a6d031377fbdd43d775b1f9 without patch: 1415 ms in layout flush with patch: 1394 ms in layout flush So we eked out 21 ms, or a ~1.5% gain with several of the most obvious optimizations that we could make. Steve Souders wrote an article [3] which includes benchmarks and shows that even older browsers don't experience significant performance degradation with poorly written selectors. It seems that performance is mostly a function of number of DOM nodes and number of CSS selectors. We're not even close to having the number of CSS selectors or DOM nodes where performance degrades, even on these older browsers. I'm still not happy that layout takes 1415 ms to complete, and I again chatted with dbaron about this. He says that there's no easy way to profile individual CSS selectors. We also have to remember that a lot of our selectors come from building blocks. He linked me to a snippet which will flush layout, but it isn't indicative of real-world performance: http://dbaron.org/talks/2012-03-11-sxsw/slide-34.xhtml Anyways, if anyone has any ideas, I'm all ears. If not, I'm going to resolve wontfix this.

As a somewhat humorous thought experiment, I tried deleting all the CSS from sms.css that wasn't absolutely necessary for being able to delete a message. This resulted in about 80% of it being removed. (ship it!) I then profiled this: http://people.mozilla.org/~bgirard/cleopatra/#report=cff6bcf3604ce1c5ce64f16738d1771252804246 We still spend 1173 ms in layout, and this is obviously not a realistic goal. So I think it's pretty clear that this is a bust.

We can open more bugs to fix sanity issues, but I'll leave that to the SMS app peers for now.

Thanks a lot Doug, that was very useful even if no change in the end. At least we know now that this is a dead end! More than 1sec for layout, this is a lot :(