Wow. Very nice post :).

Great article - can you explain how you pre-compress a gzipped file? I have only seen how to do it with an apache mod or through PHP, etc.

That's amazingly cool. It's great people still do things just to be helpful, not for money and the like.

Good job.

For this example I used the gzip ANT task in our build system. You could also use the gzip command found on most Unix type OS's.

JC: Use mod_deflate.

God Bless ya!

Wow... Great stuff!

Woah. Sweet stuff!

is it possible to send gzipped version only if the browser supports it? (Preferrably a prebuilt gzipped version)

I also thought about gzip'ing CSS and Javascript files, but how do you handle these problems:

Internet Explorer May Lose the First 2,048 Bytes of Data That Are Sent Back from a Web Server That Uses HTTP Compression
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q313712
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496

This looks like a serious road block.

Also, Mozilla and IE will only decompress files, if they have allowed compression (configurable by the user in Mozilla at least). So you cannot just unconditionally deliver gzip'ed content.

Also, I have read about older (not specified which) IE versions that will fire window.onload after script tags in have loaded their source, but before the source was decompressed and parsed.

Looks like Zimbra takes the "oh well, works for >99% of the users", it seams. Not that this is not unreasonable.

Also, there is a note on the Zimbra login page about caching problems with IE. Does the problem occur only with compression, or also without?

Zimbra is a great app, we use it, Digg is a great social news site. Glad to see two of my favourite things combined into something better! ;-)

@zanzina,@Martin

Yes we package and ship both a gzip precompressed file and a jsminified file (non-gzip). At run time we look at the browser headers(Accept) and to determine if they support gzip. So we handle the case where a browser doesn't support gzip or has it disabled. From our testing this seems to cover the problem certain IE(6.0 SP1) browsers have.

The IE cache problem is different. This is where the IE browser cache gets damaged/corrupted and will cause every image, script, etc to be read from the server each time. The fix here is to simply clear your cache.

Duh... Tree, Forest and stuff. Of cause one can generate different and tags dependent on the client... Thanks for the slap :-)

But how about the problem described in the two knowledge base articles? It cannot be detected, so there is nothing one can do about it.What does Zimbra do about this?

I guess it depends on your assessment of the risk if you do not deliver compressed files to IE at all (or rely no user agent sniffing to deliver compressed files to IE6 SP1 and up only) or if you risk the breakage.

From our testing it doesn't always cause a problem. In fact we spent the better part of last week working with IE 6.0 SP1 around this issue and an unrelated problem with image caching. The hotfix[1] for this bug has been out since 2003, and there are so many other ways to get the fix (XP SP2, IE SP2, etc) that we still send gzip content to IE if it claims to support it. We also have a URL flag ?gzip=false where user's can disable gzip if they are unable to apply the hotfix, or get the fix via one of the many service packs.

[1] http://www.microsoft.com/downloads/details.aspx?familyid=A4EA08F9-BCCA-4CFF-AE0B-3F0FD945F586&displaylang=en

Very interesting. I am trying this out myself and while I have compressed our css file using gzip, any attempt to load it does not seem to work.

Do we need to edit mime types on the server etc to enable this ?

Many Thanks

Yes, you'll need to set the correct content-type headers. We use a ServletFilter but this could also be done with mime extension mapping.

How can you have a 300% reduction in size? If you have a 100% reduction, is the size not gone? Are we talking some kind of negative dimensional incursion where the size moves to an alternate dimension, and then increases 300%?

I would be very interested in seeing some sample code on how exactly you determine whether or not to send the GZIPped content, this would be very much appreciated.

@anonymous - Think about it in reverse. It's just a way of saying 3-4 times smaller.

@bartb - This code is available in our CVS. For more code related questions please join our forums.

http://www.zimbra.com/forums

Very nice article. Funny, I called with someone at Zimbra today as I'm looking at getting a new mailserver for work. This blog and the way the guy was speaking on the phone shows a very passionate company. something sadly lacking in the corporate world.

Hi Kevin,
Nice blog. I've written something similar.
http://www.peterbe.com/plog/gzip-and-slimmer-optimization

Combining the .js files into one will be my next challange.

hi guys,
well this is all true and we are basically doing the same thing!

im also using
http://developer.mabwebdesign.com/cssoptimizer/compress.html for css

and
http://alex.dojotoolkit.org/shrinksafe/ for js.

also gzip in web server.

now, i would like to hear what do you guys do with "heavy" ajax call, do you have a recommended method fo "shrinking" the content that is sent to server ?

Yeah, anonymous is right on the reduction stuff. You can't say something gives you a 20% reduction, meaning it's 80% of its original size and then say something else gives it more than 100% reduction. With your 300-400% reduction logic, a reduction less than 100% would have to mean the file actually got larger.

You can say the original is 300% to 400% larger than the compressed version, but greater than 100% reduction makes no sense.

AJAX, by now always the best!!! thanks for post. ;)

thanks for post :) very useful

Thank you,
AJAX, by now always the best!

Very nice article. Funny, I called with someone at Zimbra today as I'm looking at getting a new mailserver for work

Zimbra Downloads