More Notes on Gzipping CSS

Published in CSS on Friday, June 11th, 2004

A different and almost cleaner way of accomplishing what the original article on gzipping your CSS set out to do.

The "official line" on this topic is being archived and updated here.

Alun Bestor mentioned in the comments of Organizing and Optimizing Your CSS - Some ideas something that, after a little testing, was worth a post of it's own.

Background information on this topic can be found in the original article, and subsequent articles [1], [2].

A more transparent gzip

With the goal of eliminating the need for placing PHP in a CSS file, Alun suggested using PHP's Zlib compression functions in combination with a little .htaccess file magic to clean things up. The following is lifted pretty much straight from his comment.

Note: Zlib support in PHP is not enabled by default, and this method assumes you keep all of your CSS files in one css-specific directory, and that PHP is installed as a module on your server.


The following code needs to be inserted into an htaccess file in the directory containing your CSS:

AddHandler application/x-httpd-php .css
php_flag zlib.output_compression On
php_value default_mimetype "text/css"

That's really about it. At this point you should, in theory, be sitting pretty, as they say. Doing it this way, you avoid having to have PHP code in your CSS file and having to name your CSS file with a PHP extension, both of which were necessary with the original method. This method is more - "Do it once, and forget about it".

But unfortunately there is a drawback.

Does it cache?

For some strange unknown reason, the method outlined above seems to prevent browsers from caching CSS files.

We tested on several local testing servers and a live server, and found that browsers consistently requested the CSS files for each page visited (and we learnt some useless yet interesting things about browsers and CSS file requests, which will be reported in a future post).

The solution

The solution, unfortunately, means sticking some PHP back into your css, more specifically the caching instructions:

$offset = 60 * 60;
$ExpStr = "Expires:" . 
gmdate("D,d M Y H:i:s",time() + $offset) . " GMT";

Pop that in the top of your CSS and 'yer laughing.


The major bonus of doing things this way is that your CSS file is delivered as a CSS file, extension and all.

If it weren't for the caching issue, this method would be sleek and simple, as you wouldn't even have to think about compressing the file, nor would you see any extra code hanging about in your CSS. If anyone can shed some light on a way around this caching problem, then please share! We're not too worried about it just yet, as we do use PHP in our CSS for other things, such as hiding longer comments in our CSS, however there will come a time when this isn't necessary, and the 'fire and forget' method would be handy.

Comments and Feedback

Why is all this necessary? I use mod_gzip for CSS compression. No extra tricks or special configuration is required. All modern browsers cope with the gzipped CSS, only NS 4 barfs - and I can\'t remember the last time I saw NS4 in my server stats.

Yeah, I know, I know... The original premise was that this is a \'poor mans mod_gzip\'. We have sites on three different hosts, and none of them offer mod_gzip, or mod_deflate.

Oh, and you\'ve just had a visit from NS4 ;-P

Your original method works fine for me, but this one fails on my live server. The stylesheet is send as text/html. AddHandler works OK, the second part doesn\'t.

He needs to add: header(\"content-type:text/css;charset=utf-8\"); to fix it.

Well that\'s bad news, Philippe!

This: php_value default_mimetype \"text/css\" is supposed to do the trick. Adding what Anne suggested to the head of your CSS file should sort that out.

Too bad though, this method could have resulted in a much cleaner method for doing this.

Robbert Broersma Sat, 12th of June, 2004

Instead of putting PHP in a CSS-file, you could use php_value auto_prepend_file /some/path/gzip-css.php in your .htaccess-file.

Nice, Robbert, I\'ll give that a try and report back. Gotta love collaboration.

Re (6): yes, adding the header as Anne suggested does indeed solve the problem. But, and however, the compression is minimal, less than 30 bytes in my test case, according to the file info given by Firefox. I can\'t override the defaults for zlib.output_compression, which is off on this server.

But I\'ll keep an eye on it, might be useful for other servers. As always, the various ways to skin a cat.

Is there any reason why to parse a stylesheet at server side?

Well, okay - I also had this idea in order to make use of some browser sniffing et al. But thanks to all those nice(?) hacks, parsing a stylesheet with PHP is very dispensable as Apache´s mod_gzip can do the same without the overhead of executing PHP.



Philippe, I\'ve seen close to 75% compression again with this method, though it was less than the original. I think something is up with your test case.. Hmm, I see you sent me an e-mail, I\'ll get back to you ;-]

Lars, this idea came about, as mentioned in comment #2, for people who don not have access to mod_gzip.

Mike, I got my own server so no problem about adding apache modules. On the other hand: Take care of some specifications in global httpd.conf which may lead to internal server errors when using your .htaccess as some directives may be set as not allowed - so this may not be the ultimate solution for everybody disregarding the hosting company.

\"The original premise was that this is a \'poor mans mod_gzip\'. We have sites on three different hosts, and none of them offer mod_gzip, or mod_deflate.

Then put pressure on the host. If that doesn\'t work, find a host who understands that his customer\'s requirements should be considered.

Okay, I know it\'s inconvenient to change hosts but, without customer pressure, hosting providers will always take the easiest option and install only the bare minimum on their servers.

Oh, and you\'ve just had a visit from NS4

Cool. Then, as my stylesheets are imported, you\'ll have been served the \"plain-Jane\" version of the website. Fully functional, accessible, but not as pretty!

So :-P right back atcha! :-)

Cool. Then, as my stylesheets are imported, you\'ll have been served the \"plain-Jane\" version of the website. Fully functional, accessible, but not as pretty!

You can configure mod_gzip to send gzipped contents only if protocol is HTTP 1.1 - Besides of NS4 every modern browser uses HTTP 1.1 and so gets gzipped contents. NS4 does not - and can handle the unzipped stylesheet.

Yeah, I saw your website in the buff, so to speak, DarkBlue ;-]

I plan on talking to our main host about this, hopefully we can have mod_gzip enabled. Changing hosts is out of the question, we\'ve recently just done this...

I can\'t understand why any host wouldn\'t use mod_gzip by default. It saves a huge amount of bandwidth (I serve only 50% of the volume of data I generate). It doesn\'t break anything (non-gzip browsers get regular, uncompressed service) and it\'s processor usage is negligible (there\'s no recordable impact on my server when mod_gzip is enabled).

Insist on it Mike. Threaten to leave, even if you\'re not prepared to do so.

Threaten to leave, even if you\'re not prepared to do so.

I always forget about bluffing. For what it\'s worth, our last hosts, though admittedly a little paranoid, mentioned that there was a security issue to do with temp file storage or something. I\'m not sure what it was though.

They are wrong. mod_gzip can be configured to store its temp files anywhere - outside of the web-server file-system for example!

All the same. Changing hosts over something this minor (which it is, bandwidth-saving or no) is silly. mod_gzip is just great for those who can get it, but it\'s always good to have alternatives when you don\'t.

This is great - I've been looking for an easy way to do this. Forget multiple css files! woot... thanks 5411 !

Editor's note: This post was moved from The Definitive Post on Gzipping your CSS where comments were supposed to be closed to the public

Home » Blog » Web Development » CSS

Check out the blog categories for older content

The latest from my personal website,

SiteUptime Web Site Monitoring Service

Sitepoint's web devlopment books have helped me out on many occasions both for finding a quick solution to a problem but also to level out my knowlegde in weaker areas (JavaScript, I'm looking at you!). I am recommending the following titles from my bookshelf:

The Principles Of Successful Freelancing

I started freelancing by diving in head first and getting on with it. Many years and a lot of experience later I was still able to take away some gems from this book, and there are plenty I wish I had thought of beforehand. If you are new to freelancing and have a lot of questions (or maybe don't know what questions to ask!) do yourself a favor and at least check out the sample chapters.

The Art & Science Of JavaScript

The author line-up for this book says it all. 7 excellent developers show you how to get your JavaScript coding up to speed with 7 chapters of great theory, code and examples. Metaprogramming with JavaScript (chapter 5 from Dan Webb) really helped me iron out some things I was missing about JavaScript. That said each chapter really helped me to develop my JavaScript skills beyond simple Ajax calls and html insertion with libs like JQuery.

The PHP Anthology: 101 Essential Tips, Tricks & Hacks

Like the other books listed here, this provides a great reference for the PHP developer looking to have the right answers from the right people at their fingertips. I tend to pull this off the shelf when I need to delve into new territory and usually find a workable solution to keep development moving. This only needs to happen once and you recoup the price of the book in time saved from having to develop the solution or find the right pattern for getting the job done..