It would be nice if all the Javascript which was included on pages was be compressed.

This look like a cool way to do it

http://ajaxian.com/archives/jscsscomp-javascript-and-css-files-compressor

There's a much easier way that isn't the CPU overhead of using PHP.

http://httpd.apache.org/docs/2.0/mod/mod_deflate.html

Every CSS, Javascript, HTML or plain text file in general, is already being compressed on this server.

We've used that technique for about 3-4 years now :)

You can tese this with:

http://www.silverstripe.com/ssopen/javascript/prototype.js

Original Size: 46 K
Gzipped Size: 10 K
Data Savings: 78.26%

Without having mod_deflate on, we wouldn't permit us to use such large JS files :)

http://www.whatsmyip.org/mod_gzip_test/?url=aHR0cDovL3d3dy5zaWx2ZXJzdHJpcGUuY29tL3Nzb3Blbi9qYXZhc2NyaXB0L3Byb3RvdHlwZS5qcw==

but still, that's only on our silverstripe-servers - providing a precompressed prototype/scriptaculous that loads fast even without mod_gzip might be a good default option. another thought i was pondering for a while is having more granular css-includes for form-fields, which are automatically composed into one file on the serverside (to avoid the HTTP-overhead). currently we have all kinds of styling in cms_right.ss, which should actually go into sapphire/forms.

That's something that I've pondered too, Ingo. The issue is that if you have slightly different includes on each page of your site, you're going to need to have a separate CSS download for each page - which is even worse.

Ideally, you want to "chunk" the output into logical groupings of CSS content, however, such an algorithm would take some thought.

A simple way would be to give each CSS file a tag (such as form, cms, homepage, etc), and group CSS includes according to their tag. It's unclear, however, as to whether this would actually provide any benefit.

siggy,
the differences between compressed js via mod_gzip and a script packer have been show to be negligible, being as they use similar algorithms

as ingo mentioned though, that is up to the user if they install ss themselves
i agree that it would behoove ss to distribute compressed js files

that said, while the method that tim mentioned is a neat trick, i dont see a disadvantage to just distributing the compressed files as opposed to doing it on the fly

Yeah distributing precompressed files is a good idea :)

There are a few good articles I've read on this recently -

The Google project looks like a god way to go

http://code.google.com/p/minify/
http://www.thinkvitamin.com/features/webapps/serving-javascript-fast
http://rakaz.nl/item/make_your_pages_load_faster_by_combining_and_compressing_javascript_and_css_files

Hi

This is interesting too.

adding this in .htaccess you can use modrewrite to automaticaly get the compresed js if your browser can handle it.

<FilesMatch “\\.js.gz$”>
ForceType text/javascript
Header set Content-Encoding: gzip
</FilesMatch>
<FilesMatch “\\.js$”>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !”.*Safari.*”
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule (.*)\.js$ $1\.js.gz [L]
ForceType text/javascript
</FilesMatch>

See:
http://joseph.randomnetworks.com/archives/2006/07/13/compressed-javascript/

Right now im using this other solution:

http://rakaz.nl/item/make_your_pages_load_faster_by_combining_and_compressing_javascript_and_css_files

Is a good one but i use it to precompress the frontend javascript only.
To precompress the cms js files i have to edit some silverstripe code.