Add option for compressed cached CSS files

[K. T. Walrus]

Here is an idea that I just had when looking into compressing my very large (>44KBs) CSS file.

Why not change the Skin Manager to save two versions of the css file:

[*]css_3.css, and [*]css_3.php

<?php

ob_start ("ob_gzhandler");

header("Content-type: text/css; charset: iso-8859-1");

header("Cache-Control: must-revalidate");

$offset = 60 * 60;

$ExpStr = "Expires: " .

gmdate("D, d M Y H:i:s",

time() + $offset) . " GMT";

header($ExpStr);

?>

And then, add a setting to import css_3.php instead of css_3.css (so the admin could choose whether to use the compressed version or not). You could also just tie this to the gzip setting to avoid yet another setting although maybe not all browser work with compressed CSS? I know you could put this compression code in .htaccess and do this without changing the CSS file at all or just use mod_gzip to compress CSS files, but this seems to be a nice idea for those that don't want to bother with all this and just have an optimization setting in IPB. For my 44KB CSS file, the compressed file is just under 8K. Not a huge savings, but still might help especially with loading the first page the user hits on the forum. Note also that you could set the cache expiration to be longer (or shorter) than the hour in the above example. I'll probably set mine to a day or even longer. Just a thought... I haven't tried this yet on a production board to see if any browsers still have issues with compressed CSS files.

The css_3.php would be the same as css_3.css except that the following PHP code is prepended to the beginning:

[Matt]

The bandwidth savings are offset by the added overhead of firing up another PHP / gzip process. Maybe, as you say, as an option so those with low CPU but high bandwidth concerns can switch it on.

[K. T. Walrus]

Well, if the compressed CSS file is truly cached, then I wouldn't think the compression time is going to be that significant. I really just hate the idea that the first page loaded on the forum for a dialup user downloads a 44KB CSS file. The graphic files and other code (like all that Javascript you now use) needs to be downloaded as well on these first page loads.

Besides, I see you have gzip enabled here for the PHP forum pages (like probably a lot of users) so gzip'ing the CSS once in a while shouldn't be that big an added load.

Regardless, I'm suggesting it be an Optimization setting so it would really be just a choice that people could enable or not. This isn't a huge feature request. It would only take a few minutes to code up and I'll probably do it for my board (if I ever get my forum open for members - its been 2 years since I bought IPB and have been thinking of opening a site). Just thought I'd mention it here since maybe you hadn't thought of doing this before. That is, having an option to compress and cache the CSS just like the HTML output is currently compressed (as an option).

[ellawella]

This is one of the neater tricks that can be pulled off with IPB. I agree with the suggestion, it would be lovely to have a Yes/No option for CSS gzipping :thumbsup:

[athlonkmf]

There are some tricky stuff that you need to consider with this feature.

1) css files are cached. If you take a look at the logfiles, you'll see that often css-files are requested, but the server gives back a "file not changed" response so it doesn't get send back anymore. If you compress it, this could throw this response out of whack and you actually have to download it again. (just a theory, not tested)

2) if you use inline CSS (not exported to a css-file, but just inside the code as the default is) you already have a compressed CSS.

3) it's much easier to add the css-files to make use of a "external"-url too. Just like the images. So you can just throw the CSS files along with your static images on some other host and have the user download it from that host.
I don't remember if the current "external url"-option includes CSS files or not, because I have modified this myself, but it could be considered a standard option.

I have modified my forum in such a way that all static files like CSS, jscripts, images, etc are all loaded from another server. This help trememndously reducing the load on my main server.

[K. T. Walrus]

Good points.

1) css files are cached. If you take a look at the logfiles, you'll see that often css-files are requested, but the server gives back a "file not changed" response so it doesn't get send back anymore. If you compress it, this could throw this response out of whack and you actually have to download it again. (just a theory, not tested)

You can always control the amount of time that the CSS files are cached by putting the expiration time in the header. I'm not sure, but I think most all modern browser support this. Also, from looking around the net, it seems to me that most browsers would honor the cache expiration time and not redownload even if the file is compressed. I haven't really tested that but that would be my expectation.

2) if you use inline CSS (not exported to a css-file, but just inside the code as the default is) you already have a compressed CSS.

But, the CSS wouldn't be cached so I'd have an extra 8K download on every page for the compressed CSS instead of an occasional 44K download of the entire uncompressed CSS.

3) it's much easier to add the css-files to make use of a "external"-url too. Just like the images. So you can just throw the CSS files along with your static images on some other host and have the user download it from that host.

I don't remember if the current "external url"-option includes CSS files or not, because I have modified this myself, but it could be considered a standard option.

I have modified my forum in such a way that all static files like CSS, jscripts, images, etc are all loaded from another server. This help trememndously reducing the load on my main server.

I too have modified IPB to have all my images, scripts, CSS loaded from a separate URL (IP). At the moment, I'm still serving them on the same server, but can move them later if my server becomes overloaded (or put up a faster than Apache daemon to serve the static content even on the same server).

But, my main concern on suggesting all this is for dial up users where downloading a 44K CSS file will take a bunch of extra time that could be saved if the file were compressed. As it is now, on the first page load for a user to load my index page, the page downloads 150KB (44KB for the CSS, 72KB for the Javascript). I have too much in my CSS and Javascript I know (I incorporated a fancy dropdown JS menu system into my pages) so I'm looking for ways to cut it down too (especially the Javascript) since a 150KB initial page could take a minute or more for a dial up user to bring down before they see the entire page.

Anyway, it is just a suggestion for Matt and Brandon to consider whether they want to implement something like this in IPB.

I'll probably end up just using mod_gzip in Apache to do all my compression anyway even for CSS, but I'm still in development so I haven't bothered setting this up yet. I don't think compressing Javascript really would work in all browsers so I'm going to have to break that up and minimize it by other means.