home / documentation / setup / the space optimized code set

The Space Optimized Code Set

On the Web, the number of bytes a user downloads to their browser can have a significant impact on the overall performance--especially the perceived performance--of the Web site as a whole. This can be especially true with the first few pages downloaded from your site, which of course form the user's critical "first impression."

Versions of HM prior to 5.1 offered you no choice; the user must download the full-length HierMenus script when viewing an HM enabled page. Of course, once the user downloaded the script it was typically cached in their browser and subsequent "download" times for the same script aren't a factor. Caching is generally not available, however, for the first hit to an HM site; and of course it's possible the user is running with caching disabled in their browser for some other reason. While the script is divided by browser (separate versions of the script are downloaded to Netscape 4, IE 4, Opera, and DOM-Enabled browsers) the continuous adding of new features to the script over the years has necessitated an increase in script size. Additionally, our developer-friendly "verbose" coding style, which seeks to use descriptive variable and function names such as ScrollImageBackground and HM_f_DocumentCheck as well as ample white space for both indenting and spacing code segments and functions, adds to the overall space utilization of the script.

Beginning with version 5.1 of HM, we offer both the standard full length verbose HM code set and a shorter, space optimized HM code set that requires only about 40% of the bytes as the full length version. A smaller code set means less bytes need to be delivered to the browser, and therefore the user can get the content of the page faster than they would with the full sized code set.

For those unfamiliar with the concept of "space optimization," a quick crash course and example should serve to illustrate the technique. Most code, including JavaScript, is written by developers such that it can be readily examined and utilized by other developers. Thus, a typical function (and an example of a function in our verbose HM Code set) might look this:

function HM_f_HideParents() {
	var TempMenu=this;
	while(TempMenu.ParentMenu) {
		TempMenu.showIt(false);
		TempMenu.IsOn=false;
		TempMenu.ParentMenu.IsOn=false;
		TempMenu.ParentMenu.HasChildVisible=false;
		var ParentMenu=TempMenu.ParentMenu;
// 6.0
		TempMenu.ParentMenu=null;
		TempMenu.ParentItem=null;
		TempMenu=ParentMenu;
	}
	TempMenu.hideTop(true);
}

This method purposely makes use of longer, descriptive variable and property names, such as "TempMenu" and "ParentMenu"; white space for both the indenting/grouping of commands and the line breaks between them; and special "comment" lines (// 6.0) which serve no purpose to the code but merely note something of importance to the developers themselves. However, the verbose nature of this function is completely irrelevant to JavaScript processors (i.e., primarily Web browsers). Browsers don't care how nice the code looks; they care only that the code itself conforms to the syntactical rules of the language. Thus, the above JavaScript function could be reduced to the following. This is the same function as above, as it appears in our space optimized HM version (some line wrapping was added here for clarity):

function HWr(){var eh=this;while(eh.er){
eh.HXb(false);eh.nd=false;eh.er.nd=false;eh.er.nl=false;
var er=eh.er;eh.er=null;eh.kk=null;eh=er;}eh.HXe(true);}

As you can see, the second function is much more difficult to read than the first, which is why many developers avoid this type of coding (and rightly so, since the next developer who must maintain the code will have great difficulty in deciphering the second function). However, it's a much smaller download, and for the reasons we discussed above, the size reduction, in some scenarios, will outweigh the developmental considerations. This argument is admittedly somewhat unique to JavaScript coding, where the size of the resulting code has a direct impact on the overall download time of the site it appears on.

Which code set you deploy on your own site is entirely up to you--the HM distribution package includes both the standard verbose code, as well as the space optimized code. And the good news is that the Web browser will happily execute both of the above functions equally well. We suspect that intranet users (where download times aren't a major factor) and developers who like to tinker with the HM code will continue to work with and deploy the verbose code, while Webmasters of public Web sites and those who typically use the code as is (without modification) will use the optimized code set.

Deploying the Optimized Code Set

When configuring the space optimized version of HM to be used on your site you should make your global variable parameter configurations (see the latter portion of step 1 in our general setup instructions if you are unfamiliar with the global variables) in the HM_Loader.js file that is located in the optimized directory of your .ZIP file, and not in the HM_Loader.js file located in the verbose directory of the .ZIP file. In this way, you'll avoid potential problems with the HM_f_CenterMenu and other custom functions, which rely on the optimized variable names and are therefore not interchangeable. The space optimized version of HM will, however, continue to recognize the verbose versions of the menu configuration parameters, so you can continue, for example, to specify your font-sizes with FontSize or your scrolling menu preferences with ScrollOver in your configuration file whether the verbose or optimized script versions are deployed.

Once your global variables are set in the space optimized version of HM_Loader.js, you simply upload it and the remaining space optimized scripts--found in the optimized directory of the .ZIP distribution file--to the Web site directory where you intend to store your HM scripts and you're done. Alternately, if you want to be able to switch back and forth in your pages between the verbose and optimized code sets, you could deploy both sets of scripts to your site (both in their own special subdirectories, such as verbose and optimized as in the original .ZIP file) and then simply point to the proper code set when calling the HM_Loader.js in your pages (this is covered in step 3 of our setup instructions):

<script language="JavaScript1.2"
   src="/hm/scripts/optimized/HM_Loader.js"
   type='text/javascript'></script>

Within the HM_Loader.js file, of course, be sure to set the HM_ScriptDir variable as appropriate. Perhaps something like this, for example:

HM_ScriptDir = "/hm/scripts/optimized/";

Developer's Considerations

If you're one of the brave few who has decided to deploy the optimized code set and you've installed your own customizations to the HM scripts, then you'll need to re-apply those customizations to the optimized scripts before installation. This is not the simplest of tasks, since the optimized code set is not intended to be human-legible; but it can be done and here we provide a few pointers as to how to go about applying the changes. Also bear in mind that any code that you've written that relies on internal variables within the HM scripts will need to be adjusted--since it's more than likely that the variable names you're relying on are not valid within the optimized HM scripts.

The good news is that the optimized code set is, for the most part, not actually new logic but rather simply lighter code. Thus, when searching for the spot to effect changes in the optimized code set, you'll find it's laid out in the same order and employs the same logic as in the full length verbose code. Thus, the changes you make in the optimized code will be logically the same as they would be in the verbose code; they'll just utilize the shorter function and variable names.

There is only one exception to this rule that you need to be aware of.

The optimized code set contains an object called HM_o_OptParameterNames that is populated with valid information (the same object exists in the verbose code set; it's just blank). It is this object that contains the "translation table," if you will, for the optimized parameter names, allowing the optimized code set to work properly with verbose configuration files.

When applying your new code to the optimized code set, you'll probably need to cross-reference the "verbose" function and variable names with the "optimized" versions. Such a cross-reference is provided via the link below, which is valid only for the version 6 HierMenus code (and which opens in a new window). For a version of the translation table that is valid in HierMenus version 5, see the original release notes for HierMenus 5.1.

Verbose vs. Optimized Cross Reference

Using the above cross-reference, for example, you can see that where the verbose scripts refer to the MenusToBuild array, the optimized versions will use po instead. And if the verbose scripts call the HM_f_MenuOver() function, the optimized scripts will simply call HWf().

Technical Considerations

Finally, a few quick notes about the optimization process itself that may be of interest to you.

As mentioned previously, the space optimized versions of the HM code are--for the most part--logically identical to the verbose versions, which means that the space optimized versions of the code offer no performance improvement over the full length versions (other than the obvious reduction in download times). The byte reductions in the optimized code come entirely from:

1. Removal of comments
2. Removal of most unneeded white space (including many line breaks)
3. Shortening of variable and function names

This last point requires some further discussion. In shortening our variable and function names we've tried to ensure that the new names will not collide with existing scripts on your page by prefixing all global variables and functions with the letter "H." This makes the optimized scripts slightly longer than they theoretically need to be, but we felt this would--at least in general--be much safer than assigning 1 character global variables or functions. The very fact that we're now using short, non-descriptive variable names, however, raises the possibility that we've chosen a variable name that is identical to a variable name that you're using in another script on your pages. You may, therefore, need to review your additional JavaScripts and/or test them against the optimized code before you settle on deploying it. Of course, you can always change the variable names either in the HM script or your additional scripts as necessary to avoid the collisions.

Developers who are interested in pursuing the topic of Web site optimization are encouraged to check out WebRef Founder Andy King's site WebSiteOptimization.com, which is devoted to his Web Site Optimization service, optimization related topics and headlines, and his book "Speed Up Your Site: Web Site Optimization."