Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.


Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, biapar, Willr, Ingo, simon_w

JavaScript compressor


8 Posts   2586 Views


27 April 2007 at 5:37pm (Last edited: 27 April 2007 5:52pm), Core Development Team, 201 Posts

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


27 April 2007 at 10:43pm (Last edited: 27 April 2007 10:50pm), Forum Moderator, 628 Posts

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

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:

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 :)


28 April 2007 at 2:05am Forum Moderator, 801 Posts

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, which should actually go into sapphire/forms.


28 April 2007 at 12:53pm Administrator, 685 Posts

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.


8 May 2007 at 6:27pm Google Summer of Code Hacker, 39 Posts

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


16 May 2007 at 10:05am Forum Moderator, 628 Posts

Yeah distributing precompressed files is a good idea :)


3 June 2007 at 7:32pm Core Development Team, 201 Posts

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

The Google project looks like a god way to go


7 June 2007 at 1:23am (Last edited: 7 June 2007 11:29pm), Community Member, 41 Posts


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 “\\.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


Right now im using this other solution:

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.