Time to tweak your javascript bloat

Lets take a look at a couple of js based clients out there and see some of the easy ways I use to trim the suckers down.

Ka-Map ~10 scripts total: 130kb
Arcims4 html viewer ~17 scripts, total: 291kb

1. Trimming

The Kamap devs have already included by default, a way to “compress” the javascript on the fly by removing newlines, comments by calling getcjs.php. Its a good start and easy to implement on any js app, not just ka-map and can be done similarly in another language. See brainjar.com for a static javascript implementation

//Snip $aSearch = array('///.*/', // c++ style comments - //something  '//*.**//sU', // c style comments - /* something */ '/s{2,}/s', //2 or more spaces down to one space '/n/', //newlines removed '/s=/', //space = '/=s/', // = space );  $aReplace = array( '', '', ' ', '', '=', '=',);  //remove c++ comments $szContents = preg_replace( $aSearch, $aReplace, $szContents ); ?>

Most trimming systems such as cjs.php create a new compressed file, not touching the original. This allows all the legible formatting and comments to remain in the source, but then be stripped out for use in production. This can cause some management issues, as once you trim the js, theres no way to rebuild the original source should it be lost.

2. Use JS declarations wisely

Contrary to what alot of people think, use of JS includes in the head of a webpage will affect the load time of the body. The body will simply not be rendered until the JS has been downloaded. See the problem now?

Furthermore, each individual JS document adds an increased overhead on the webserver as each definition is an additional HTTP request to the server.

Thats not to say the best thing is to dump all the code into one file though. Ideally, the best way to optimise the load is to only include the code that will be needed at a particular section and try to ensure the client caches the javascript where applicable. Its a big balancing act indeed

Recommended reading: peachpit.com article

3. GZIP encoding

If there is one thing people should enable, its gzip. All major webservers have some support for GZIP or a variation of it (eg. mod_gzip for Apache 1.x or mod_deflate for Apache 2.x). I wont bore you with details because thats all readily available at sites like webperformance.org or websiteoptimization.com. Think of it like stuffing all your js, html and CSS into a zip file … sending it to the client, and the client decompressing and viewing the contents all on the fly. Its common to save upward of 60% in filesize vs. the uncompressed source. Very big savings when you look at it in terms of download time (and bandwidth),

App Original Time (56k) CJS Time (56k) GZIP Time (56k)
Kamap 130kb 18secs 81.3kb 11secs 23.05kb 3secs
Arcims 291kb 42secs 205kb 29secs 56.55kb 8secs

Huge savings across the board.

GZIP is by far the easiest, cleanest way to noticably improve the end user’s load time, particularly on a low bandwidth connection. Unfortunately it doesnt seem to be used much on heavy javascript-centric web GIS systems. Whether or not that is due to insufficient access to the webserver or simply not knowing, there is no excuse for expecting clients to download ~300kb of javascript just so you can show that super-cool rubberbanding, aspect snapping zoom tool.

Thoughts / comments ?