Honey, I shrunk my own bits - Using EGL Rich UI to compress EGL Rich UI
ChrisLaffra 060000KCEQ Comments (4) Visits (3877)
Web2.0 applications have a tendency to move presentation and business logic from the server to the browser. At some point, someone has to pay a price for moving all that code around. Browsers are good at caching HTML, CSS, and image files, but many round trip connections or large files will make an application load slowly, especially the first time someone visits it.
Of course, as that single file gets larger, so does the time it takes to download that one big file. This is where we get to the topic of this blog: compression.
To write a compressor for Rich UI application, I designed an EGL Services project that is deployed on TomCat, and that runs the Yahoo UI Compressor on the request being sent to it. Here is the Service Definition:
By right-clicking on the EGL file that contains the service definition, I quickly generated an interface for invoking the service (this one is so simple, I could have done it by hand, of course). This is what the interface looks like:
This service can be invoked like this from Rich UI:
The response handler for this REST service looks like this:
Notice the use of Google charts to show the compression rate.
To put it all together, I wrote a RUIHandler that defines a button to start the compression, show some progress UI, and finally shows the compressed end result in a TextArea. Because the YUI compressor also support compression of CSS, I added that in the same swoop.
As you can see, you can ask the document for all its children and inspect what's inside them.
My final compressor is a bit more complicated than shown above, as I call the services to compress all the scripts and CSS fragments in parallel, and they come back in random order. So, I have some bookkeeping in place to collect the final results in the right spot when they arrive back to me. For a typical RUI application, 50 elements are compressed using a service call, all in about 7 seconds on my T60p laptop.
Now, for the final result.... The file becomes about 50% smaller. This means your application will download twice as fast. However, I have personally found that on a device like an iPhone the download time improves even more that that. I think there is a critical barrier around 400K to 500K. Once a file gets larger than that, the download times grows non-linearly, that is what it looks to me. Anyway, the Web20 Expo Scheduler (with all its session contents and images) downloads in about 4s onto my iPhone when compressed with the tool described in this blog. This is the same time CNN takes. That's pretty good.
The total size for the scheduler is 293K. This includes all of the Rich UI runtime, and the entire application with all its data. Again, for comparison, when tested while I wrote this blog, CNN.com requires 153 roundtrips, at a total of 768K. A prominent image of President Obama weighed in at 58K. So an entire Rich UI application can be as small as 5 Presidents.
Follow these simple steps: