We have several raw stylesheets that are full of documentation in the form of css comments. We run these through CSSTidy before concating them all into one file

We have several raw stylesheets that are full of documentation in the form of css comments. We run these through CSSTidy before concating them all into one file. CSSTidy, while a few years old, does a reasonable job of cleaning out a lot of the cruft that we need internally but don't want to deliver to the end user. You should not be doing any kind of minification or cleanup on your css & js during the page request. These need to be done during your build process and cached on a CDN, or at least as a static file somewhere. Edit As a further note, here's a short list of things to do before deploying css, images, and javascript live. css/javascript/images should be considered static. Unless you're running a specialized application, these are resources that require no modification from one page request to the next. css & javascript are text files. Images are binary formats. 1) Minify css & javascript. If you have multiple stylesheets internally on your dev environment that you use for purposes of keeping code separated, but all the code ends up being used on all your pages, combine them together into 1 file. The same thing for javascript files. 2) Compress images. There are a number image compression techniques. Most of these are accessory applications that are run during deployment. They take your original images and create optimized versions that are smaller but same dimensions. The images are then stored elsewhere and don't affect the originals. 3) Images come in 2 varieties: Style and content. When and where possible, images used for Style should be turned into background sprites. Multiple images in one file can be moved around with css to achieve different affects. Content images tend to be more dynamic (imagine a news site with lots of new pictures each day). These images should be optimized but can't easily be sprited the same way background images can. 4) Serve static content (ie css/js/style images) from a server that does NOT pass cookies. Cookies are extra bandwidth that you don't need to transfer for things like this. So say you have www.mysite.com. Serve your static resources from a non-cookie subdomain like static.mysite.com. 5) Use multiple subdomains to serve static resources. Modern browsers allow something like 6 simultaneous connections to the same domain on average. So if you have a lot of stuff on your page (like a news or photo site), you can get a big performance boost by loading your static stuff from static1.mysite.com, static2.mysite.com, static3.mysite.com, etc. The technique I have used to good effect is a 'round robin'. During my build process, I do a search and replace on my default path variable {csspath} in my stylesheets. I rotate the replacement through each sub-domain. As the browser is loading the content of the page, its doing many more simultaneous requests. Each sub-domain is loading from the same place.