Comments on: Compression, Caching, for faster load times

By: Frederick Townes

Frederick Townes — Fri, 22 Dec 2006 13:52:09 +0000

I’m curious if anyone provided/found any documentation they could share on the relationship between compression rate and load time as well as the point of no return that Jesse was talking about. I wonder if port80software has anything to say about these subtle, yet relevant issues.

By: Joeri

Joeri — Tue, 05 Dec 2006 12:31:08 +0000

It would be nice to see a benchmark of loading time versus compression rate. Gzip has different compression settings, and compression time varies a lot depending on the setting. I’ve used it successfully in the past when sending large datasets to the client (flash application loading multi-megabyte XML files which couldn’t be shrunk down), but I just picked the compression level that offered the best trade-off between filesize and compression time, instead of the one that produced the quickest load.

By: negate.net » apache mod_deflate reduces bandwidth usage by 27% on SuperMotors.net

Tue, 05 Dec 2006 01:07:50 +0000

[...] 12/4/06 Edit: Ajaxian has an article on gzip compression with some user responses. Interesting insights (in the comments section) on the law of diminishing returns with gzip compression used on ajax-enabled pages.Â [...]

By: Jesse Kuhnert

Jesse Kuhnert — Mon, 04 Dec 2006 19:55:19 +0000

If you are really itching to squeeze as much compression out of it as possible, there’s an undocumented (simply because I’m not sure if everyone might like it) feature of the dojo compressor where you run your build as you normally would be add “gen-strip-docs” to the list of tasks to execute. The savings vary depending on the size of the dojo.js file being compressed. (and the questionable reason why it’s not documented is because of what it does to compress all of the dojo related js files found in your release directory.)

By: Patrick Fitzgerald

Patrick Fitzgerald — Mon, 04 Dec 2006 19:17:12 +0000

Be careful when packing to remove line breaks – if you are missing a semi-colon then your javascript might not be valid after removing the line breaks. Of course using JSlint should detect missing semi-colons. Perhaps packer should have an option to remove comments and whitespace but leave in the line breaks.

By: Jesse Kuhnert

Jesse Kuhnert — Mon, 04 Dec 2006 16:02:49 +0000

I’ve only done some limited “eyeball” testing using fiddler to time response times using/not using gzip compression. (didn’t have the new firebug version at the time)

The performance differences were extremely slim for smaller dynamic responses, but still just a few ms faster than non compressed versions.

It would be good to get a more definitive set of tests to be sure everything is working as efficiently as possible though. (the css/javascript/etc file based compressions I do get cached in-memory until the files change on disk so that particular aspect of things hasn’t had any porblems wrt performance in cpu cycles )