Recently I gave a presentation to colleagues on Jawr and the general merits of Javascript/CSS minification. Most of the material was pilfered from the official Jawr site but it may be easier to digest for those of us with shorter attention spans.
So, first an introduction:
Jawr

“Jawr is a tunable packaging solution for Javascript and CSS which allows for rapid development of resources in separate module files. Developers can work with a large set of split javascript files in development mode, then Jawr bundles all together into one or several files in a configurable way.”
And why should we care about any of this? Before answering this question, let's step back for a moment and discuss an important concept in web application development:
Minification
Minification (n), also called minimization, or minimisation (for those who speake the Queen's English): the process of removing all unnecessary characters from code without altering its functionality. This typically includes all non-critical whitespace and newlines that are not included in string literals and most comments.
Verb form: minify.
Why minify (and bundle)?
• Improves load times for the client
• Less data being transmitted by the server
How?
• Minification reduces the size of HTTP responses.
Why should we be sending unnecessary data? The spaces, tabs, and newlines are valuable only in development so we should keep them to ourselves.
• Bundling reduces the number of HTTP requests.
The HTTP protocol is fairly inefficient when it comes to retrieving lots of files. First a TCP connection must be established. This requires a three-way handshake. The client sends a connection request, the server responds, and then the client acknowledges the response.
Now the client sends the HTTP request itself. HTTP, Hypertext Transfer Protocol, is, as the name indicates, a text based protocol with all information being sent as human readable text. This means that the speed, small size, and efficiency of a rigid bit and byte based based protocol are sacrificed in favor of versatility and comprehensibility.
I'm not going to get into the details of the TCP/IP stack and talk about maximum transmission units or fragmentation but, for those of you unfamiliar with the specifics, I'll just stress that there's even more overhead in the transmission of these bloated requests and responses in addition to the initial handshake and large, text -based headers.
The response, with a larger set of headers, comes back from the server and, if this is an HTML document, the client begins sending requests for the other documents referenced therein. This includes scripts, style sheets, and pictures. All browsers have a limit on the number of concurrent connections allowed to a single domain per page and for a while this was a whopping 2 (this is still effectively the case for IE). Additionally, unless the Keep Alive flag is set, each request requires a new TCP connection to be negotiated.
Multiple script files, which halt the execution of the page due to the assumed requirement that they be loaded and executed in order, will make initial page load times uncomfortably long unless the files are cached. Therefore, reducing the number of files that need to be downloaded means fewer HTTP requests resulting in faster load times.
And why should we care about load times?
• Web applications and the culture of instant gratification
If we, as web application developers, truly want to compete with desktop applications then we strive to match their responsiveness. This is why the whole AJAX paradigm has become such a phenomenon (and poorly misused buzzword) over these past four years. When we perform an action within the context of a web page, we don't want to wait ages while the screen reloads. Even in cases where a full page transition is necessary, slow load times can mean the death of a project where alternatives are available.
• Mobile browsers
My iPhone is faster and has more storage space than the iMac I bought back in 1999 and a much better downstream than the 56K modem bundled within. It weighs as much as my wallet and enables me to check my email from places where laptops are socially forbidden. Mobile browsing is becoming ever more prevalent and it would be a serious mistake on the part of any web application developer to neglect making optimizations for their sake.
• Some people still use dial-up
…and some people still use AOL… and a lot of people still use IE. Strange, I know, particularly the last point, but whatever the reason for the circumstances may be, they may not have a choice but we certainly do have the choice to optimize.
So why don't we just use one big script file and one big style file?
• Development is much more efficient when using multiple, logically separated files and good organization is integral to good programming.
Editing or debugging large script files is a nightmare. Editing or debugging large, minified script files is impossible.
• Some components need to be included on every page whereas other components or groups of components need to be included in particular sections of the site.
Optimization doesn't mean simply getting rid of meaningless text, it also means excluding useless code. If I have an admin section of a site and a client section of a site, there is no need whatsoever for scripts specific to the admin to be sent to the client and vice-versa. In the case of styles, there could be CSS conflicts between these two sections so we certainly wouldn't want to bundle section specific stylesheets together.
Other options
• YUI compressor (no grouping) (http://developer.yahoo.com/yui/compressor/) Java app, minify and compress.
• Minify (PHP) http://code.google.com/p/minify/
Jawr
• Minifies
• Munges
• Bundles
• Compresses
• Enforces Caching
• Does all this on demand
• Has debug and production modes
• Built in JSP tag library for including the scripts and styles
Additionally
• Free and open source
• Easy to set up
• Easy to configure
• Plays nice with others (Spring MVC, JSF/Facelets, Grails, pure HTML)
Setup (web.xml)

Setup (jawr.properties)

Setup (JSP)

Result (debug)

Result (production)

File Sizes
16532 autocomplete.js
1176 binder.js
367 console-noop.js
1617 effects-ext.js
38986 effects.js
1543 form-highlighter.js
11809 global.js
822 modalbox-ext.js
22778 modalbox.js
2625 prototype-ext.js
124000 prototype.js
All files
244 KB
core.js (minified and bundled)
156 KB
core.js (minified, bundled, and gzipped)
40 KB
Load times (in debug mode)

Load times (in production mode)

Load times (with caching)
