views:

78

answers:

3

As I was working on a small website, I decided to use the PageSpeed extension to check if their was some improvement I could do to make the site load faster. However I was quite surprise when it told me that my use of CSS selector was "inefficient". I was always told that you should keep the usage of the class attribute in the HTML to a minimum, but if I understand correctly what PageSpeed tell me, it's much more efficient for the browser to match directly against a class name. It make sense to me, but it also mean that I need to put more CSS classes in my HTML. It make my .css file harder to read.

I usually tend to mark my CSS like this :

#mainContent p.productDescription em.priceTag { ... }

Which make it easy to read : I know this will affect the main content and that it affect something in a paragraph tag (so I wont start to put all sort of layout code in it) that describe a product and its something that need emphasis. However it seem I should rewrite it as

.priceTag { ... }

Which remove all context information about the style. And if I want to use differently formatted price tag (for example, one in a list on the sidebar and one in a paragraph), I need to use something like that

.paragraphPriceTag { ... }
.listPriceTag { ... }

Which really annoy me since I seem to duplicate the semantic of the HTML in my classes. And that mean I can't put common style in an unqualified

.priceTag { ... }

and thus I need to replicate the style in both CSS rule, making it harder to make change. (Altough for that I could use multiple class selector, but IE6 dont support them)

I believe making code harder to read for the sake of speed has never been really considered a very good practice . Except where it is critical, of course. This is why people use PHP/Ruby/C# etc. instead of C/assembly to code their site. It's easier to write and debug. So I was wondering if I should stick with few CSS classes and complex selector or if I should go the optimisation route and remove my fancy CSS selectors for the sake of speed?

Does PageSpeed make over the top recommandation? On most modern computer, will it even make a difference?

+1  A: 

I personally have found that the complex selectors are more confusing long term, just be sure to give the classes appropriate names.

Long selectors are going to have a performance impact as it requires walking of the DOM each and every time to analyze the process. The way I see it there are times and places for it, but it is an exception, not the standard rule.

Mitchel Sellers
+1  A: 

Define you priorities.

  1. Readability
  2. Efficiency
  3. Speed

Nowadays, except on a real specific projet and complex page, you don't need to obfuscate your code to speed it up.

First think to maintainability.

By the way, using #id is a good practice both for readability and speed, since it doesn't need to walk through all the DOM to find it. Same apply for you.

Boris Guéry
+3  A: 

should I make my CSS easier to read or optimise the speed?

You should do both.

You should write your CSS so it is readable and if you want to collapse it, use a tool that automates that to generate the "production CSS".

So you should be working with nice readable blocks and the published file should be tiny.

In terms of the specific selectors

#mainContent p.productDescription em.priceTag { ... }

Only adds value if you have

p.productDescription em.priceTag { ... }

Or

em.priceTag { ... }

In other places that you don't want to affect - for example if you had a "#secondaryContent p.productDescription em.priceTag" that you didn't want to apply the style to.

So if you want to use

em.priceTag

And have the rule applied to all, you'll actually see no performance issue (the difference would be about the same as the file-size difference you save anyhow by having less chars in the rule).

HOWEVER... don't pollute your HTML with tons of class="" attributes just because you don't want to write a proper rule.

Sohnee
Thank you. That what worried me : putting tons of CSS classes attribute that add clutter to the page.
Laurent Bourgault-Roy