Modularized Sites Load Faster!

• Tweet
• Pin It

Most websites load more quickly when they are broken into smaller “pieces” (i.e., “modularized). While the idea seems obvious enough, it’s still worth mentioning, and good explanations are always worthwhile! What’s less obvious is that, once you’ve started along that road, issues of coordination take precedent; and, whether the site developer is a seasoned professional or a relative newbie, they’d do well to recognize these issues up front.

That said, this article hopes to accomplish three things: first, to underscore the value of modularization. Second, to clarify some of its important, though previously underreported, repercussions. Finally, to offer remedy to these repercussions by explaining how the task of coordination can be accomplished systematically.

References are here made to a website I designed for others and to a bulleted check list of questions that website developers (particularly those hoping to decrease load times) should consider before they break up their websites into little bitty pieces.

Modularization case study:

I had previously broken up a few sections of one of my favorite Flash websites into smaller swf’s and loaded them into different levels of the main movie. In fact, it seemed pretty natural for things like MP3/ music selectors, clocks, and such. And, quiet as it’s kept, I’d grown accustomed to the inordinate size that my main movie had taken. So, when I came across a recent SitePoint article on modularizing the main movie (otherwise known as placing it on a diet; see Angeletti), I studied it with great interest.

And indeed, it worked! In fact, it worked so seamlessly, I went through the entire website and dismantled/ modularized 6-8 additional sections! Great, I thought! Now, the main movie was much smaller in size at least after deleting all remaining unused items from its library. With that, I noticed it took less time to load and that I could more easily isolate any remaining areas of concern. Unexpectedly, by breaking up the main movie into smaller pieces, it became easier to identify those sections of the website that could be re-used!

For instance, when my favorite website initially loads, a set of doors open, revealing an image centered on the screen, sitting right above four main navigational buttons. Before modularization, this door-opening routine would occur only once when the website was initially loaded. So, this was the first thing I modularized. After doing so, it became obvious to me that I could re-use or coordinate the door-opening routine to execute every time my users would click one of the main navigation buttons! All I had to do was call the door-opening routine from inside each one of the buttons. Simple!

What I had not yet realized was that the task of coordination would eventually become anything but simple. Try coordinating anywhere from 25-50 different sub-movies so that they interact as users expect both with the main movie and with one another! Let me tell you, it can get a little unwieldy!

Just how unwieldy?

Well, let me just say that, despite its obvious benefits, modularization raises important questions of coordination (which, in turn, raise questions of time and effort e.g., how much time do you have and how much effort are you willing to expend). However, the first question asks: how much modularization is enough, and how much is too much? Is there a point of optimality? Consider the following.

You’ve got four navigational buttons, all programmed into your main .swf, all associated with different sub-menus/ selections, and as well, with different background images (see Image 1). Modularize these four buttons into four smaller, faster-loading .swf’s and you’ve got problems. Check this:

 the sub-menu selections and/ or background image for the first button need to be turned off when any other main navigational buttons is selected;

 the same for the second button its related information needs to be turned on; and, while all of this is happening,

 the first button is not supposed to disappear or become inoperative.

 the background music should not be affected by the button selection, but the images of musicians that appear when the music begins should disappear when certain buttons (but not all) are selected.

For a seasoned Flash designer/ developer, none of this is particularly disturbing; everything is as it should be. But for the rest of us, aspiring to become a seasoned Flash something or another, this all comes from out of the blue.

It means we need to program each one of the navigational buttons to issue a series of commands that will make certain characteristics of the remaining buttons roll-up, slide out, or otherwise disappear to allow the other buttons to display their information without interfering with one another. In plain English, the buttons need to evaluate and interact with their environment before they execute.

This, then, raises a second question which asks: how do I get the smaller .swf’s to give and receive commands to one another, and as well, to/ from the main movie? For the sake of brevity, I will not attempt to answer this question here, but if you’re interested, you can contact me personally (Steven A. Maclin), and I promise to provide a fuller explanation.