P.mapper JS compression

by filed under JavaScript, WebGis.

This short note describe a technique to compress JavaScript files in p.mapper WebGIS.
Compressing JS files can speed significantly up loading times in this popular WebGIS client application.

I would like to share some thought about p.mapper loading time, I feel that having many uncompressed js files push up loading time significantly due to two main reasons:
  1. file size (188KB uncompressed)
  2. number of requests
Point 2 is browser dependant but AFAIK most browsers typically can handle no more than 2 (IE) http requests simultaneously. I’ve come up with a solution that I’m using in many projects (mainly ajax) and tests in pmapper give good results. This is what I’ve done: cd javascript for i in $(ls *.js); do mv $i $i.src; done for i in $(ls *.js.src); do jsjavacompress.sh $i >> pm.js ; done This produces a single 95KB pm.js file that is loaded at startup. additionally gzip gives a 27KB file. So we can go from 20 files 188KB to one file 27KB compressed and gzipped. cat jsjavacompress.sh java -jar custom_rhino.jar -c $1 2>&1 You can download custom_rhino.jar from here The same could be done in jquery directory. Some measurements on javascript/ : uncompressed: 179 KB, 19 files compressed with jsjavacompress.sh: 85 KB, 1 file (24 KB gzipped) compressed with compress_js.php (without licences): 91 KB, 1 file (24 KB gzipped) compressed with jsmin.php : 91 KB, 1 file (24 KB gzipped) compressed with jspack.php : 69 KB, 1 file (28 KB gzipped) References: jsmin: PHP adaptation of JSMin, published by Douglas Crockford as jsmin.c, also based on its Java translation by John Reilly. jspack: This is the php version of the Dean Edwards JavaScript ‘s Packer So jspack appears the most efficient so far but only when gzip compression is not enabled, all other soutions are equivalent and are slightly smaller when gzipped. The only real advantage I see in the java solution is that it is a “semantic” parser since it uses a real javascript engine (RHINO) and hence it does always produce valid js code. The same is not true for the other solutions, if we have a missing “;” or other oddiness in source js code, they will produce invalid code.