alt131 - 11:32 pm on Mar 11, 2011 (gmt 0)

Wahoo! You have been busy - and without a yes/no, I did the tests myself. Want more time to reflect on your last post, but a first read suggests my results confirm - maybe inform - some parts of it.

How this relates to your tests
Although you have now moved to general optimisation techniques, these tests were designed around the OP, so provide a sub-set of more detailed information. The issue was that pagespeed wants efficient selectors and seems to treat some selectors as more efficient than others - which prompts the question
"Does pagespeed consider one "efficient" selector more "efficient" than others?
Second, although unused selectors are not significantly "penalised", they are the opposite of "efficient" - so what happens when they are removed.

Where this takes the thread
Nowhere new - just providing finer detail on a sub-set of questions prompted by the OP. It does reinforce the general thread theme that pagespeed scores reflect usual performance improvement techniques (optimsation, caching, etc). It confirms already identified oddities, and I think confirms that "refactoring" around the detailed warnings/suggestions relating to css and selectors is best left until the tool matures.

The chosen test page:
On a well-known site, mostly text, reasonably well-written code. I'm still struggling to find a pagespeed definition for "interactive", and this one may not qualify. But it provides an opportunity to test whether "non-interactive" pages respond the same way as "interactive" pages.

In the original weboptimisaton analyser gave all "congratulations", total weight 43000kbs, 7 htttp requests, 4s download at 128k. pagespeed (version 1.10.2) scored 91, complaining of un-combined css, inefficient selectors and unused css*. Downloaded and reassembled so it could be manipulated for testing scored 79 - an acceptable difference given it was uncached, no expires-by, a couple bad requests, etc
* Included alternate, print and other media css - all treated as required downloads, then all selectors reported "unused"

The tests:
# just id's versus just classes
Made no difference to the score.
# just classes versus multiple classes
Could not be tested because (randomly) first or last class was reported as unused.
# "pagespeed efficient" descendent selectors versus just id's versus just classes
Results ceased to be meaningful:

1. Definite counting issues
   
2. Unused selectors were incorrectly reported.
   
3. Sometimes a certain number of unused selectors seemed to be required before the warning triggered. In small test files only one, in larger pages either: adding/deleting a particular selector would trigger/remove the warning, OR large numbers of rulesets (but not all selectors reported as unused) had to be removed. (Code was double-checked for validity)
   
4. Attribute selectors not recognised and therefore reported as unused. (Confirmed by a test file using only attribute selectors.)
   
5. Randomly reported pseudo-elements, pseudo-classes and adjacent siblings as for 4, also randomly failed to count siblings correctly which meant different test runs would report a different group of adjacent sibling selectors as unused
   
6. When all unused selectors were removed, bar one to trigger the warning, pagespeed warned "0 of 0 is not used by the current page" followed by a list of a few selectors from each of the css files. (Confusing as previously reported unused, not used selectors.)
   
7. Consistently reported 42.7% unused selectors and the same (but wrong) size css files. This was maintained despite deliberately increasing/reducing file size. Continued despite trying to clear a "sticky memory" - clearing caches, starting/restarting browser and pagespeed, cold booting, etc
   
8. Score increased to 81 when all css was moved to a single file.
   
9. Score increased to 85 when all claimed unused selectors were removed. As these were incorrectly reported, all page style was lost - but pagespeed then reported 87.4% unused selectors.