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.

3 Responses to “Does Size Matter?”

  1. Almost Getting To The Point « Andy Schwartz’s Weblog Says:

    […] Andy Schwartz’s Weblog Just another weblog « Does Size Matter? […]

  2. Daan Horn Says:


    I’m trying to find out how to get the frontpage, of a web application that we are developing, as small as possible. Apart from just using the obfuscator and compression, I would like to use javascript library partioning as well.

    After reading the article, I have two questions left:
    1. Is it possible to have the javascript library partition configuration only affect the frontpage? Meaning that only the necessary partitions are loaded on the frontpage and that all the rest will be loaded on the other pages (where javascript size is less important).
    2. You claim that ADF Faces has his own set of “javascript features” configured. Where do I find this configuration, or more about this?

    Daan Horn

  3. Daan Horn Says:

    Ok, I found there’s an undocumented web.xml parameter flag:

    This will get just the JavaScript files for the components that are used on the page. When going to another page with another component, the JavaScript that’s needed for that file will be loaded.

    Placing a adf-js-partitions.xml file in the WEB-INF folder, seems to ensures that the needed partition JavaScripts are loaded instead of just the component JavaScript.

    Daan Horn

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: