Previously, I described a browser-based application that preloaded objects into hidden frames to improve application performance. These objects consisted of select boxes, images, and Java Swing applets. Once loaded, the objects would be copied from the hidden frame to a visible frame where they would behave like any other object. While the preloading did significantly improve performance, the time required to preload the objects into their own hidden frames required approximately five minutes at Ethernet speeds. At dial-up speeds, I’d have time to drive the 50 or so miles to New York to get a cup of coffee and a bagel.

Preloading objects has its merits, but this particular implementation had some major problems. So I decided to modify my approach. Instead of preloading objects, I would cache objects that were used more than once. Also, rather than have a hidden frame for each object I cached on the client-side, I would have one hidden frame with multiple inline frames associated with it. This would allow me to use the hidden frame’s document object model frames collection to see what had already been cached. For example, if the name of the hidden frame was Dwarfs, the frames collection would be top.Dwarfs.frames. To find an inline frame named Grumpy, you’d employ a JavaScript function like Listing A.

The function inlineFrame finds an existing inline frame, but what if the inline frame doesn’t exist and a null is returned? Well, if it doesn’t exist, you’ll have to create it.

At first glance, dynamically creating an inline frame seems pretty easy. It is and it isn’t. You can get started easily enough, but it takes checking the inline frame’s document.readyState to figure out when it is finished. This is where you can run into problems.

Getting started
To create the inline frame on the hidden frame, you use a client-side JavaScript document.write. Fortunately, inline frames are, from the browser’s point of view, HTML documents. This allows you to query the inline frame’s readyState to determine whether the document is complete. But continuously querying the readyState of the inline frame will only slow things down. A better way to handle it is to create a JavaScript function and use window.setTimeout to defer execution of the function. You can then check the inline frame’s readyState periodically without wasting resources on the client machine and possibly hanging the browser.

Once the inline frame’s document is complete, copying an object to the visible frame is a relatively easy task. All that is required is that the innerHTML is copied from the inline frame to the visible frame.

The setSpan script
I wrote a JavaScript function called setSpan to eliminate the drudgery of creating dynamic inline frames. It checks to determine whether an inline frame has been created and whether it’s complete. If the inline frame hasn’t been created, it will create it and wait for it to complete. Once the inline frame’s readyState is complete, setSpan will copy the innerHTML to a target and invoke an initialization routine, if provided.

For consistency’s sake, I decided to make each of the objects its own Active Server Page and put them in a folder called IFrame. In addition, also for consistency, an include exists for each of the objects to be displayed on the visible frame. This include consists of an HTML span tag and reference to setSpan, as in Listing B.

I have provided code samples that illustrate the use of the routines discussed in this article. The samples are available for download and provide a basic outline of how you can use hidden dynamic inline frames for client-side caching.

Client-side caching is by no means a panacea for all your Web development headaches. It won’t solve all the problems you face in the day-to-day struggle between the desire for speed and slick, professional looking applications. But it does offer a relatively simple way to speed up client-side performance.