Introduce Javascript compression

I haven't had time to look through the old issue to read all of the previous discussion yet.

I wanted to note on the 3rd option (maintain 2 versions in CVS), that as soon as we introduce this, and rely on humans to do that work, we'll inevitably have some sort of synchronization problem. One or the other file will fail to get updated, and we'll get unusual results.

This may or may not be a stupid question to you, but which modern browser does *not* support GZIPped JS/CSS files these days?

I'm not sure how relevant it is now, but at http://perishablepress.com/press/2007/04/24/compressed-javascript-compre..., they mention that Opera does not cache compressed content. This is from 24-Apr-2007.

In java based projects I have had success using the DOJO shrinksafe program on javascript files. Shrinksafe works because it really understands javascript; being based on the rhino javascript interpreter. See http://dojotoolkit.org/docs/shrinksafe and download it from http://svn.dojotoolkit.org/dojo/trunk/buildscripts/lib/custom_rhino.jar .

Running it is easy (be sure your classpath is setup):

java -jar custom_rhino.jar -c infile.js > outfile.js 2>&1

For those who don't want to download and run the custon_rhino.jar shrinksafe java jar, the DOJO project provides a web page base service to upload, shrink and return javascript files, see http://shrinksafe.dojotoolkit.org/ .

subscribing

@sasconsul: in my experience, both Dojo Shrinksafe and the YUI compressor give excellent results – thanks to them both being based on the Rhino JS engine. Unfortunately, we can't rely on every Drupal user having java support on their machine. Nor can we afford to use a public web service to compress them. I think we should try to mimic them in PHP as good as possible? i.e. use YUI compressor/Dojo Shrinksafe as "the" example implementation: only remove/compress what they compress.

One thing that I like very much about Dojo Shrinksafe is that it never changes a public variable or function. That allows you to track problems in JS code much faster, even when your code is compressed.

While I haven't tested this, JSMIN – also available in a PHP version, seems to be much more careful in its compression algorithm - which is actually barely more than whitespace removal. This may be our best option.

This may or may not be a stupid question to you, but which modern browser does *not* support GZIPped JS/CSS files these days?

I doubt there are any but you have to respect the accept-encoding header. Sometimes the UA expects gzip, sometimes it might not.

Couldn't consolidating and zipping be considered a form of caching? I don't understand caching in Drupal completely but if the Javascript files that are to be served were stuck together in one big file then gzipped on the server then that could be kept in a cache folder (along with an uncompressed version of the same thing). The accept-encoding header could be checked and that would decide which of the gzipped or non-compressed javascript files were served.

Compression by removing whitespace and whatnot probably doesn't make much difference when the file is zipped because of the way the zip algorithm works. Stripping comments would make a difference for files with a lot of comments. If anyone knows differently from experience please correct me. I'll be looking at shrinksafe to see what more's out there.

Hope to see this feature available but I don't know enough to implement it on my own.

JSMin + Gzipping is better than packing, as it achieve the same compression ratio, but there's a performance penalty for evaluating packed JS. See : http://www.julienlecomte.net/blog/2007/08/13/ . Also, Jquery offers the minified + gzipped form of its library first, and offers the packed one with the comment 'for those who cannot gzip their javascript'.

So my vote goes to JSMin + gzipping.

I'd love to have the minified jQuery bundled with Drupal instead of packed. In addition to packed javascript being slower to execute on the client and larger than gzipped minified javascript, there is a case where the packed jQuery causes probems; it breaks ActiveX control activation in Internet Explorer (see http://dev.jquery.com/ticket/930), and minified jQuery must be used instead.

Hello, here's a backported version of jsmin-1.1.1.php for PHP4. I just started to use it here (running D5).

In case of parsing errors, instead of throwing exceptions, it returns input as-is.

Hope that helps

Could we also work to including less CSS/JS files too?

Subscribing...... Related to #251578: More flexible js/css ordering and an alter operation. Since Drupal 7 will be PHP 5 only, I see no reason to backport the compressor to PHP4.

Folks,

Has anyone looked into using Minify, http://code.google.com/p/minify/ ?
To quote its blurb: "Minify is a PHP5 app that can combine multiple CSS or Javascript files, compress their contents"

It looks promising.

Stuart

Dean Edwards Packer has a near perfect PHP port. This is what was used to pack jQuery Forms Plugin 2.16 for core.... Unfortunately, it's licensed under the LGPL.

Humm, what license does the drupal project see as acceptable?

The license for Minfy is simple: http://code.google.com/p/minify/source/browse/trunk/LICENSE.txt

Stuart

The Drupal CVS only accepts code under the GPL2. There are exceptions though. jQuery, for example, is dual licensed under both the MIT and GPL licenses. For more information about it, visit http://drupal.org/licensing/faq .

#352951: Make JS & CSS Preprocessing Pluggable

This may be a good alternative to just JSMIN: JSMIN+. It's been written by the developers of tweakers.net, the largest tech site in the Belgium/Netherlands/Luxemburg region, which has many millions of pageviews per month.

One of their criteria was:

It should be able to handle our javascript files.
That seems a no-brainer, but most minifiers actually force you to cohere to a very strict syntax. That means: no omission of semicolons that are otherwise optional, always using curly braces for if-else statements and always explicitly use parentheses when combining pre- or postfix increments in expressions. We felt this requirement was way too restrictive, and this criterium actually eliminated all tools that were based on Douglas Crockford's JSMin.

Since that was one of the main concerns that prevented this patch from getting in (IIRC), it seems like a viable alternative. The fact that it's already being used by a high profile web site should give some credit towards its reliability.

Hey Wim, I stuck up an issue in JavaScript Aggregator for JSMin+. Sounds like a great candidate.

Add tag.

Sorry guys, it seems that #119441: Compress JS aggregation is older, so marking this as a duplicate.