Does Size Matter?

When it comes to JavaScript code size, of course it does.  Too much code leaves users waiting impatiently for JavaScript libraries to download.  Or worse, not waiting.  Even in cases where users have a warm browser cache, the overhead of loading large libraries into the JavaScript engine can slow down page view/transition times, making your web application feel less responsive.

Size is an issue for any web application framework that includes a client-side component.  ADF Faces is no exception.  In this blog entry we’ll take a look at how ADF Faces attempts to deal with its (growing) JavaScript code base.

Our initial approach to managing our JavaScript code consisted of three steps:

1. Aggregate

In ADF Faces each JavaScript “class” lives in its own file.  This simplifies the development process, making it easier to manage a large code base.  However, with over 400 JavaScript classes/files, serving each of these up in separate requests is not an option.

Fortunately, the Apache Trinidad ResourceLoader architecture comes to the rescue.  In particular, Trinidad’s AggregatingResourceLoader makes it easy to merge multiple files into a single resource at runtime.  ADF Faces uses this to merge *all* of its JavaScript code into a single library.

2. Minimize

When working with a large JavaScript code base, code maintainability is an important consideration.  Developers should be able to freely add comments/whitespace and to use descriptive variable/method names.  Of course, such verbosity is not appreciated when it comes to download size, and comments, white spaces and descriptive names are wasted on the JavaScript engine.

Again, Apache Trinidad provides a solution here.  Trinidad includes a JavaScript obfuscator that handily strips comments, whitespaces and obfuscates/minimizes local variable names.  ADF Faces integrates the Trinidad JavaScript obfuscator into its own build process.  As a result, writing comments, or whitespace, or using descriptive variable names in the ADF Faces JavaScript code base is not a crime but instead is encouraged.

3. Compress

Minimization is a good start, but not a good place to stop.  When it comes to optimizing download sizes, compression is king.  The current generation of web browsers all support gzip-compressed JavaScript payloads.  We typically use Oracle Web Cache to help with this.

This strategy seemed reasonable when it was first put it in place two and half years ago.  At that point, our minimized JavaScript code base maxed out at around 540K, which compressed down to roughly 120K.  Not exactly small, but manageable.

Of course, ADF Faces development has not stood still over the last two and a half years.  Our component set has doubled.  A range of new architectural features has been added.  As you might imagine, new components and features translates into more JavaScript code.

How much more?  As of the recent JDeveloper 11g production release, our total minimized code size is now in the vicinity 1.4M.  After compression this comes back down to 320K.

Okay, definitely not small.

What lessons can we take away here?

Well, one lesson is that compression is our friend.  JavaScript code compresses nicely – compressing can cut down the download size (and thus download time) by ~75%.  This is good.

On the flip side, a tough lesson is that client-based components/features come at a price: increased JavaScript code size.  At a certain point, the simple aggregate/minimize/compress strategy of JavaScript code management seems no longer up to the task.

What to do?  In the next entry, we’ll consider alternate strategies for managing a large JavaScript code base.