[Mapbender-dev] JavaScript compression

[Christoph Baudson (WhereGroup)]

Yesterday I compressed 5 files which take up most of the bandwidth

59Kb map.js
32Kb geometry.js
30Kb wz_jsgraphics.js
  7Kb map_obj.js
  6Kb point.js

totalling 131Kb of client side scripts.

Compressing with Shrinksafe resulted in a total of 66.5Kb, while JSMin
reduced the size to 74.2Kb.

Unfortunately, two issues arise with compression:

1) I encountered some evil eval code in Mapbender: there are register
functions that look like this

"functionName(parameterName)"

If we pack the files with Shrinksafe, the variable in the scope, where
the register function is evaluated

eval(mb_MapRequestSubFunctions[i]);

is no longer named "parameterName" but "_55". So JS throws an
exception like "unknown variable parameterName".

There are two possible solutions: use JSMin, or find a way to run
Shrinksafe in a way that variable names are not shortened. But then the
compression advantage of Shrinksafe compared to JSMin might vanish and
it might not make a difference which one to use.

2) Using JSMin, Firefox crashes randomly when the Firebug plugin is
enabled and "Net" is selected. I believe it is a Firebug bug. In IE
Mapbender loads without problems.


I propose we use JSMin for the upcoming release; but I would be happy to
discuss other solutions for the future.

But with about 57Kb we still have saved a considerable amount of
bandwidth.

Christoph


Christoph Baudson (WhereGroup) schrieb:
> thanks for your suggestion, Marc.
> 
> I have checked the tool and the compression rates are better than JSMin's.
> 
> While JSMin compressed my sample file (map.js, around 60K) to 70%, 
> Shrinksafe made it to around 60%. I think I will try to compress the 
> relevant files with both and want to see if there is a difference. If 
> not, then Shrinksafe is definitely a good choice.
> 
> I have also found a nice online interface at
> 
> http://alex.dojotoolkit.org/shrinksafe/
> 
> The next step would be to find an easy way of compressing all the 
> relevant files in one go, preferably via Eclipse's "Export", as Uli 
> suggested. How do we proceed? I have created a ticket at
> 
> http://trac.osgeo.org/mapbender/ticket/54
> 
> Christoph
> 
> Marc Jansen schrieb:
>> Hi list,
>>
>> I would love to see compression brought to the Javascript files and 
>> have another suggestion as for the compression tool:
>>
>> http://dojotoolkit.org/docs/shrinksafe (a nice article which shows how 
>> to use the compression tool)
>>
>> The Java-file custom_rhino.jar is used to pack Javascript. This is 
>> used within the dojotoolkit (www.dojotoolkit.org) for example. One can 
>> download the file here: 
>> http://svn.dojotoolkit.org/dojo/trunk/buildscripts/lib/custom_rhino.jar
>>
>> -- Marc
>>
>>
>>
>> Christoph Baudson (WhereGroup) schrieb:
>>> To enable Mapbender to load faster, the new release will employ 
>>> JavaScript compression.
>>>
>>> There has been a lot of discussion about this in the past; I think 
>>> packing the JS files with JSMin is the best idea:
>>>
>>> http://www.crockford.com/javascript/jsmin.html
>>>
>>> + the existing JS code must not stick to a given syntax
>>> + transparent (removes only linefeeds, whitespaces and comments)
>>> + no obfuscation
>>> 0 compared to real packers with still a good compression rate.
>>>
>>> Files that are already compressed with other packers (like jQuery) 
>>> will of course not be re-compressed.
>>>
>>> Some more questions arise:
>>>
>>> 1) Where to store the compressed/uncompressed files in the file 
>>> system. The default setting should be "compressed" IMHO. It should be 
>>> easy to switch back and forth from uncompressed to compressed.
>>>
>>> 2) Which settings? Take a look at
>>>
>>> http://fmarcia.info/jsmin/test.html
>>>
>>> You can add comments. The compressed JS files will not have a license 
>>> on top of the script, as comments are removed. Do we have to add a 
>>> license?
>>>
>>> For compression settings, I chose "conservative" for my test run; 
>>> Some scripts like jsTree.js don't use the ; to end statements, so a 
>>> linefeed mustn't be removed.
>>>
>>> Any ideas?
>>>
>>> Christoph
>>> _______________________________________________
>>> Mapbender_dev mailing list
>>> Mapbender_dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapbender_dev
>>>
>> _______________________________________________
>> Mapbender_dev mailing list
>> Mapbender_dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapbender_dev
> 
> _______________________________________________
> Mapbender_dev mailing list
> Mapbender_dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapbender_dev