views:

164

answers:

4

In the context of improving overall site performance (downloading and rendering speed) there appears to be a contradiction between the following two best practices:

  1. Only bring down the CSS that you need for the page being viewed. (Because too many CSS rules cause slow rendering)

  2. Always minify CSS and combine it into one file. (Because more requests means slower page load)

Now say I decide to follow rule 1.

The following issues come up:

What if 2 pages share 1 set of CSS rules?

In this case, I need to put those rules in a separate file and reference that file from both pages.

However, if I begin to have a lot of these "shared rules", I might end up referencing a lot of separate files from each page, and thus, breaking rule 2.

For example, page A might depend on CSS 1 and 2, while pages B and C both depend on CSS 2 and page D depends on CSS 1.

In this scenario, it's impossible to have exactly one CSS per page or even multiple CSS's per page, since some pages will need to share some CSS files with other pages.

But can't we solve this problem by combining all the CSS for each page into a separate per-page CSS file?

We could, but this would create other problems.

If two pages shared one fragment of CSS, even if we compress the hell out of it, we're still going to download that fragment repeatedly, every time we request a page who's CSS contains that fragment.

Because we've compressed the CSS by page, we've allowed redundancies to occur where a CSS fragment is shared by two or more pages.

Browser caching does us no good here because to the browser, each CSS file has a different filename, and is thus a separate file, even if some of them contain content that is the same.

So which rule should we break?

The one I'd cross off is:

1. You should only bring down the CSS that you need for the page being viewed.

I think it's much simpler and more practical to minify/combine the hell out of all the CSS for my site, and bring it down in one go.

As for the performance problems this might create, I think they're lessened by the following facts:

  • Modern browsers are getting faster at processing CSS rules, so pretty soon it won't matter if you have a lot of rules in memory that aren't being used.

  • Having all your CSS cached will improve speed a lot more than any improvement you'd gain from leaving out unnecessary rules, which are going to get loaded anyway, when the user browses to the pages that require those rules.

Am I right here?

+2  A: 

1. You should use Gzip

alt text

http://www.fiftyfoureleven.com/weblog/web-development/css/the-definitive-css-gzip-method

http://paulstamatiou.com/how-to-optimize-your-css-even-more

For asp.net

http://web2asp.net/2009/01/introduction-one-of-big-complaints.html

Edit:

2. And write CSS selectors efficiently

http://code.google.com/speed/page-speed/docs/rendering.html#UseEfficientCSSSelectors

http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/

https://developer.mozilla.org/en/Writing_Efficient_CSS

3. And combining

http://rakaz.nl/2006/12/make-your-pages-load-faster-by-combining-and-compressing-javascript-and-css-files.html

RewriteEngine On
RewriteBase /
RewriteRule ^css/(.*\.css) /combine.php?type=css&files=$1
RewriteRule ^javascript/(.*\.js) /combine.php?type=javascript&files=$1

4. Read suggestion from answers of this question http://stackoverflow.com/questions/421205/css-performance-issues


I don't like to have multiple CSS files for each page. 4-5 css files is enough.

1. Common.css (with reset and common layout and typography and Form styling)
2. pagespecific.css (css of home and other landing pages)
3. print.css
<---- ie only css --- >
4. ie6.css
5. ie7.css
<--- >

And stripping white space from CSS will make edit hard through FTP.

Here is a good article on one css or multiple css http://css-tricks.com/unique-pages-unique-css-files/

metal-gear-solid
I think the number of CSS files you have should be based on what makes sense to you the developer, and what is the easiest way to keep the code clean, organized and modular. It shouldn't be driven by performance concerns. Performance is important, but performance improvements should be separated from CSS layout/design.
jonathanconway
@jonathanconway - right. i write css so i keep 4-5 css always and these are enough for me to keep Code clean, organized and modular. This topic is depend person by person one rule can't be right for everyone.
metal-gear-solid
@metal-gear-solid gzipping or not the question is about `page render` speed and not data transfer
Frankie
No one needs to edit minified CSS. If you have a process that automatically does the minification, you can just edit your normal, uncompressed files, and let the minification process take care of minification.If you need to debug a live page, you could temporarily turn disable your minification process or perhaps download the page source, stick a base-tag in the top and re-reference your local uncompressed CSS files.
jonathanconway
@Frankie- but data transfer speed is related to rendering speed. rendering speed will depend on speed of system. and on speed if internet connectivity both
metal-gear-solid
@Frankie, it is about both actually. Firstly, Gzip doesn't reduce payload nearly as much as minification does, and for best results you should use *both*. (See: http://stackoverflow.com/questions/807119/gzip-versus-minify/807161#807161).
jonathanconway
@Frankie Secondly, data transfer is something the developer needs to think about, since GZip doesn't combine files, it only compresses them and only a little.
jonathanconway
@jonathanconway then please edit your question to reflect that. As you were *explicitly* talking about rendering time I assumed you wanted a specific answer.
Frankie
@metal-gear-solid, there's a difference between increasing performance by 1) reducing site payload, or by 2) reducing the amount of work the browser needs to do.In the context of CSS, I think the 2) aspect is less important, because a) browsers are getting more powerful and better at processing CSS, b) well-written CSS will be faster than badly-written CSS to such an extent that a few hundred lines of unused rules won't make a big difference.
jonathanconway
A: 

There is always trade-offs. If you find yourself making many CSS files and there are too many dependencies such that tracking which CSS file to inlcude becomes difficult, it would be better to make one (or at most two) CSS files and minify them. Hopefully your CSS files are not crazy-big.

Zabba
Personally I want to minimize the influence of performance concerns over CSS layout/design. I want the CSS to be nice-looking, clean, modular, easy to work with, etc. I want a separate compression/minification process to take care of performance/speed concerns for me. Because of the above, I favor breaking the first rule, and just minifying *everything* into *one* file, since this allows me to break up my CSS files in a way that makes sense and it easy to work with and worry about performance later.
jonathanconway
+1  A: 

This is a very nice view Mr.Jonathaxxx..

Yes I agree with you, the above both point you bring are major point. My one comment regarding your first point which is..

  1. You should only bring down the CSS that you need for the page being viewed. (Because too many CSS rules slows down rendering).

I think we can achieve this as well.

In web application we would have a common skeleton for all views of the apps. We can say it Master page. All of our different pages/views are adopting from it. So there is a common look and feel between all pages. In that case why we can not make one style sheet only for that. So it can be shared among all pages/views. This can be a layout file.

This is one CSS file.

Next, we can generate another CSS for controls in the page or we can link the control's styles also in layout CSS file.

After any styles what different pages might get, we can have a different file for them. This will not increase the amount of CSS files for a single page. Maximum a page will get 2 or 3 style sheets which are completely relevant.

[EDIT]

Default CSS file would be always cached and would be used among all pages/views of the application.

Muneer
+5  A: 

Like always both cases are valid.

Your solution has to go with benchmarking your costumers.

But I would probably stick to just one css file for as long as I possible could. And if your site grows into such an extravagant size were you need two different files try to use them in two very different site sections site_general and logged_in for example.

Nevertheless, some things may help you:

  • compress css with YUI Compressor (gives me the best results)
  • have apache (or whatever) deflate your css files
  • and the most important of all, make sure the file is cached by the user!


Keep CSS Clean

One thing you may find useful after having several developing runs on a site is Dust-Me Selectors a Firefox extension that covers your site for unused selectors.


Use Selectors Wisely (render speed!)

Probably all selector engines go from right to left making .parent div.myclass faster than div.parent .myclass. When writting your CSS keep this in mind. Also remember that ID's # are much faster than classes. Apart from that it's the usual, avoid universal selectors, don't hover on non link elements, ... Google has a great article on it.

On top of that run Firefox's Extension - Page Speed that gives you a very detailed info on slow selectors and much, much more.


Apache Deflating Example deflating is smaller than gzipping as Jeff so kindly put for us on his blog.

LoadModule deflate_module modules/mod_deflate.so
<FilesMatch "\.(js|css|html|htm|php|xml)$">
    SetOutputFilter DEFLATE
</FilesMatch>

Apache Caching Example

# Set up caching on media files for 1 month as recommended by page speed
<FilesMatch "\.(gif|jpg|jpeg|png|swf|js|css)$">
    ExpiresDefault A2629744
    Header append Cache-Control "public, proxy-revalidate"
    Header append Vary "Accept-Encoding: *"
</FilesMatch>


Hope it helps!

Frankie
Thanks Frankie, good tips there. I think splitting compressed CSS by *site section* might be a good idea, although even then, you'll have that annoying issue of what to do with CSS that's shared across both sections.
jonathanconway
@jonathanconway use a 3 files system (general, secA, secB).
Frankie
Another useful answer, except that from my point of view rendering speed isn't that important. I just avoid using the universal selector (star `*`) esp. alone for brute-resetting `* { margin: 0; padding: 0; }` and that's OK. Optimization of images and JS are important though, but effect of poorly written CSS isn't that important from a performance POV.
Felipe Alsacreations
@Felipe Alsacreations - css can effect on performance http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/
metal-gear-solid
In most cases it doesn't. Or more exactly it's not a priority. From the article *"For most web sites, the possible performance gains from optimizing CSS selectors will be small, and are not worth the costs."* There are many other aspects of a website that need our attention before these.
Felipe Alsacreations