gzip the css

the browser already caches external css files (along with other external files like javascript, images, etc.). thus, there is little benefit to zipping them. if you have the capability to gzip, then it makes sense to gzip all text files where the browser supports it.

my first reaction was indeed that the webserver ought to do the gzipping. however, your point that this will only use more cycles when under /. is true. gzipping this static content so every user will get the same page (provided they use the same theme) looks like a good thing.

I would like to revive this issue.

The two css files for pushbutton (I mean misc/drupal.css at 8% and theme/pushbutton/style.css at 12%) together make up for 20% of the bandwidth consumption.

Although it is true that css are cached, for sites that receive a lot of new traffic (not repeat visitors), this will be a problem. More so when you get Slashdotted as well!

I have resorted to a hack to reduce the size of the CSS files (remove all un-necessary white space, and newlines, as well as modules I do not use (e.g. aggregator, calendar, ...etc.). This reduces the file sizes by 25% for one file and 30% in the other. This should translate to 5% savings of the monthly bandwidth.

It seems a more proper solution is to implement what link that Killes pointed to in the original comment.

This, combined with PHP gzip compression for output, should cut down on bandwidth usage significantly.

I've had a bit of a think about this and I'd like to throw out a plan for discussion.

First, the scope.

• We want to send gzipped versions of .css files to browsers that support them.
• We want to cache the gzipped versions of .css files to save CPU.
• We should probably also gzip and cache the .js files via the same mechanism.

No matter how these files are stored they need to be served up by a script. This script needs to:
- check that the browser can handle gzipped data
- send the appropriate headers
- send the gzipped data to the browser
- manage cache expiry
- rebuild the cached gzipped data from the original files

The @import and src= statements needs to point to this script. Either all the code that outputs one of these statements needs to be modified or these statements need to be re-written on the fly. I think the best option is to re-write the statements in drupal_get_html_head. This would allow this feature to be controlled from one place should a "on/off" setting be required. The rewriting should be achieved by a fairly simple PCRE.

There are as I see it two options for the script that gets called.

The first is to create a new .php script that contains whatever code (or imports chunks of the drupal base code) to manage the caching etc. This would allow the caching code to be pretty streamlined.

The second option is to let index.php catch these requests. This would suggest that the caching mechanism might follow the same code path through Drupal as a page request. This would perhaps add some overhead to each request but probably require less code and be a more elegant solution. Or index.php could detect that this is a request for a cached file and fork off to a different code-path.

I'm not sure which of these two options would be best. Would someone with better knowledge of the relevant parts of Drupal care to offer an opinion?

Whatever option we chose should have a way to turn this off at the admin's choice. This can be a hidden variable in $conf array in settings.php.

wow... +1 from me - I got 43k html and 40k css on http://www.marketingfan.com/ !!!

I'm all for it too! It's a great idea, and would save transfer which is expensive as we all know.

Following #1 and #5 there are two things to do:

1. reduce CSS files and split them to be smaller and better re-used (done on current HEAD)
2. configure correctly the webserver to compress pages (HTML, CSS, JS, etc) and choose the right options to optimize webserver performance.

Compressing this kind of data (to gain performance) is *not* a Drupal problem, but a webserver one. Why would we add more code (add more bugs) in Drupal to have a feature that will do another (or several) database hits?

Even if we go throught the "file cache" path, we would only "re-inventing the wheel" because who really needs to save copies of compressed pages wwould be the webserver and never Drupal.

@killes: those stats are for uncompressed CSS? Can you activate your webserver compression module and re-evaluate the stats within one month or two?

I could never really say with 100% confidence that the compression is working on my server.
If you look at a web page analyzer on the web, and query your page, they almost always come back with different results at different times.

No need to re-invent the wheel. A webserver like Apache and lighttpd, compress static files and save them on a dedicated cache, also having mechanisms to detect and re-compress changed files.

FWIW, groups.drupal.org is now compressing its css, js, and HTML at the apache level and is working well.

Just my two cents:
not every host provides support for mod_gzip or mod_deflate.

Mine doesn't, at least. So I looked around for a solution and I found JSmart (farhadi.ir/jsmart.html). It's a tool that compress both js and css at site level using php gzip compression. It seems it's fast (it implements an internal cache for gzipped contents) and it's easy to setup.

It's not perfect (it tries to minimize both js and css with mixed results), but it's simple enough to be modified really easily: I disabled compression commenting out just one line of code.

And it needs just mod_rewrite: js and css requests are redirected to the php compressor.

I finally published a module based on JSmart called SmartCache.

It handles Expires headers, transparent gzipping of js and css files and updates the cache when a requested file has been modified.