Power JavaTechniques for Optimizing Web Site Development and Runtime Characteristics

• By Christopher A. Fregly
• October 13, 2000

WEB DEVELOPERS FACE many challenges building and maintaining high-performance, flexible, adaptable Web sites. In this article, I demonstrate how to improve Web site development and runtime characteristics through a process that encourages effective analysis and documentation. I first introduce a useful framework design and implementation to improve Web site navigation and maintenance. I then discuss how to use the framework to increase Web site flexibility by overcoming some well-known HTML and Web browser limitations. Finally, I present a few implementation tips and tricks to optimize the runtime performance of the framework participants.

The article contains examples to help you apply these valuable techniques to your own work. The examples use XML, Java, JSPs, Servlets, JavaScript, HTML, and Cascading Style Sheets (CSS).

Introducing the Web Director Framework
Let's begin this discussion with an analogy to the movie-making process (see Table 1). All movies begin with a well-defined storyboard developed by a storyboard artist. The storyboard describes the stages, actors, and scenes of the story. Similarly, all good Web sites begin with a well-defined storyboard typically documented during the inception or planning phase of software development.

Table 1. Movie analogy.
MOVIE	WEB SITE
Storyboard Artist	Analyst
Storyboard	Storyboard
Pilot	Prototype
Stage	HTML Container (Frame, Window)
Scene	HTML Document
Actor	End-User
Action	End-User Selected Action
Scriptwriter	Developer
Script	Script
Director	Web Director
Movie Premier	Web Site Premier

The next step in the movie-making process is to develop a pilot to provide an animated version of the storyboard that will convince producers to fund additional production of the movie. Similarly, the next step in the Web site development process is to create a semianimated prototype—usually a series of simple, static HTML pages—to convince venture capitalists and other potential shareholders to fund additional development of the site.

A movie pilot typically involves an initial, critical piece of the overall story and involves every component of a movie—e.g., stages, scenes within those stages, actors within the scenes, and the actions performed by those actors. A Web site prototype also displays an important piece of functionality using such interactive equivalents as HTML frames, HTML documents, end-users, and end-user actions.

Once the high-level storyboard and pilot have been approved, more detailed stages, scenes, actors, and interactions need to be defined. For example, scriptwriters define the more detailed interactions of the actors in a document called the script. This detailed analysis and design typically occur in the elaboration, or requirements-gathering phase of Web site development. In this phase, developers build on the storyboard and prototype from the inception phase to define the complete end-user navigation in a document called the script. A simple script defines navigation from one scene (Login) to the next scene (Home) based on a user-selected action (LoginAction) and the result of the action (LoginSuccess). While more complex rules typically define navigation, the example discussed in this article involves a simple storyboard and script for a simple e-commerce order-entry Web site.

While a movie actor follows the script through various scenes with the guidance of the movie director, a Web site end-user can move freely through the various HTML documents with the guidance of the Web director framework.

Our storyboard is documented using a UML state diagram (see Figure 1).

Figure 1. Storyboard using a UML state diagram.

The analyst uses a UML state diagram to break down a site into a series of abstract components (see Table 2) including scenes (states), actions, action results, and transitions (state transitions). An example of a scene is the OrderEntry scene. Each scene exposes a collection of available actions, such as SubmitOrderAction and CancelOrderAction. If SubmitOrderAction succeeds (represented by the state transition arrow labeled "SubmitOrderAction: Success"), the user is directed to the OrderAck scene. However, if SubmitOrderAction fails because of a validation or other recoverable error (represented by the state transition arrow labeled "SubmitOrderAction: RecoverableError"), the user is directed back to the OrderEntry scene. The combination of current scene, action, and action result defines a transition within our movie analogy. Each selected transition leads the user to the next appropriate scene (e.g., OrderAck). The script determines available transitions. The result of the user-selected action determines the User-selected transitions (see Figure 2).

Table 2. Glossary.
TERM	DESCRIPTION	EXAMPLES
Scene	A scene is a state within the Web site flow defined by a name, a URL of an HTML document, and a stage.	OrderEntry
Stage	A stage defines the container within which the scene is displayed.	the frame labeled "main" within the browser
Action	An action represents the user's chosen action from a particular scene. An action is generated by events such as a button click, drop-down select, radio-button select, or check-box select.	LoginAction SubmitOrderAction, CancelOrderAction
ActionResult	Every action generates an ActionResult.	Success, RecoverableError, FatalError
Transition	A transition is the combination of the current scene, the user-selected action, and the action result. Each scene leads the user to the next scene through a transition.	see Figure 2

Figure 2. Selected transitions.

The developer can now create a script based on the storyboard in Figure 2. The script describes the details of each scene, including scene name, URL of the HTML document, and available transitions. A DTD and XML version of the script is presented in Listings 1 and 2, respectively.

Implementing the Web Director Framework
The Web director implementation is broken up into two areas: the client and the server. Let's start with the server implementation because it is needed by the client implementation. (Note: The server implementation can be used by itself.)

The core component of the server-side Web director is called NavigationFacility. This component uses the script defined earlier to guide the user through the various scenes based on user-selected actions.

NavigationFacility (see Figure 3) improves site maintenance by enforcing a centralized script. Many developers are tempted to defragment and hard-code site navigation into a collection of hidden fields throughout many pages within the site (e.g., NEXT_PAGE="Home.jsp", ERROR_PAGE="FatalError.jsp"). This complicates Web site configuration and maintenance because navigation is fixed and decentralized across multiple pages and tiers. As the Web site navigation evolves, a Web-director-enabled site requires modifications to the central script rather than to many pages throughout the site—reducing the potential for navigational errors. More advanced implementations of NavigationFacility would allow the script to refresh itself at runtime when changes are made, without having to restart the server. This is sometimes called a hot deploy.

Figure 3. NavigationFacility class diagram.

The implementation should ensure that only one copy of the script is loaded into each server's memory, because scripts can grow very large in size.

Servlets are the next key component of the server-side Web director framework. The responsibilities of the servlet layer include adapting the HTML form data to the domain model, calling appropriate business process methods, populating the HttpSession if necessary, and using the NavigationFacility to redirect the user to the next scene.

When developing such servlets, a good practice is to define cohesive and decoupled servlets that are responsible for related business process methods. These methods ultimately correspond to the available actions of the scenes. The OrderEntryServlet, for example, exposes the submitOrder() and cancelOrder() methods that correspond to the SubmitOrderAction and CancelOrderAction actions of the OrderEntry scene.

Figure 4 uses a UML sequence diagram to describe the scene transition flow of a "submit order" button click through the server-side Web director framework. The OrderEntryServlet first creates an Order object from the HTML form data using the createOrderFromHTMLForm() method. Next, the submitOrder() business is called based on the value of the "navAction" hidden field—set by the SubmitOrder button click in the OrderEntry HTML form (see Listing 3). The result of this business method invocation, a submitted order, is then placed into the session to be used by the next scene. Finally, the servlet uses NavigationFacility (and the script) to redirect the user to the OrderAck scene (see Listing 4). This process is known as selecting a transition.

Figure 4. Selecting a transition.

Overcoming HTML and Browser Limitations
Using the Web director framework, a Web developer can overcome some annoying limitations in the latest browser, HTML, and JavaScript specifications and implementations. These limitations reduce flexibility and performance of the Web site. I discuss two of these limitations next, along with the solution offered by the Web director framework.

The first is called the "Asynchronous form.submit()" problem. This exists because the form.submit() JavaScript method call is asynchronous and does not support a return value or other notification of method completion. This forces the scene developer to poll for completion or assume completion after a given amount of time. However, these are inefficient solutions, because end-users of varying connection speeds are interacting with the Web site—making it impossible for the scene developer to guess the completion time.

The second limitation is called the "Predetermined TARGET Window" problem. This is a limitation in flexibility because an HTML form requires that you define the TARGET window of your form ACTION before the action result is determined and your next scene is chosen. This forces the developer to work within the same window regardless of the outcome of the transition selection. For instance, the script may dictate that if the SubmitOrderAction is successful, the next scene, OrderAck, is displayed in the "top" frame. However, if the action fails, the next scene, OrderEntry, is displayed in another stage—the "top.main" frame. Without a work-around, this is not possible, because the TARGET is determined by the HTML form before the next transition is known.

To overcome these limitations using the Web director framework, I introduce a level of indirection in the browser using an invisible, hidden "buffer" frame of width or height equal to 0 (see Listing 5).

The next step is to introduce a helper JSP called WebDirectorHelper.jsp to be used within the hidden buffer frame. Instead of redirecting directly to the next scene, a servlet can redirect to the WebDirectorHelper.jsp via the invisible buffer frame (FORM TARGET="buffer"). This makes room for additional client-side processing into the form.submit() workflow (after control returns to the browser) and increases flexibility. A clever JavaScript developer can insert a notification that resolves the "Asynchronous form.submit()" problem.

The WebDirectorHelper.jsp and invisible buffer frame combination solves the "Predetermined TARGET Window" problem as well by deferring the choice of the next stage until after the next scene is known and control returns back to the browser.

The implementation of the WebDirectorHelper is straightforward and lightweight to minimize overhead of this technique (see Listing 6). Note: This implementation assumes that the stage names are valid frames within the browser.

The following changes need to occur to the implementation presented earlier to enable these flexibility enhancements:

1. Change the TARGET of all form ACTIONs to the buffer frame (see Listing 7).
2. Change the sendRedirect() destination within the servlet to be the WebDirectorHelper.jsp (see Listing 8).

The interaction between the client and server Web director framework components is clear to the developer once the framework is in place (see Figure 5).

Figure 5. Selecting a transition using WebDirectorHelper.

Runtime Performance Optimizations
While the previous sections described techniques to improve navigation, maintenance, and flexibility, this section describes two implementation techniques to directly improve the performance of a Web site by reducing the size and improving the download time of the scenes participating in the framework. (Note: These techniques can be used outside of the Web director framework as well.) The first is a simple, highly effective JavaScript performance trick. The second, more elegant technique emphasizes the performance improvements realized when using CSS.

Performance has always been a serious challenge, particularly in the area of downloading large HTML files over slow connections (<=56 k).="" there="" are="" a="" limited="" number="" of="" effective="" html="" optimization="" techniques="" that="" reduce="" the="" size="" of="" the="" html="" document="" and="" improve="" download="" time="" and="" response="" time="" of="" a="" web="" site.="" the="" network="" bandwidth="" between="" the="" client="" and="" server="" limits="" the="" performance="" of="" a="" web="" site,="" particularly="" when="" downloading="" large="" html="" files.="" in="" addition,="" the="" processor="" speed="" of="" the="" client="" machine="" limits="" the="" performance="" of="" rendering="" the="" html="">

As developers, we can only control the size of the HTML that is downloaded through the network and the amount of client-side scripting that executes in the client browser. By reducing the size of the HTML, we directly improve the response time of the application.

The idea is to take large amounts of similarly formatted data (e.g., large tables) and place the common, repeated HTML code into a reusable JavaScript function within the page. Essentially, we are "factoring out" the common code and pushing it into a JavaScript function with formal parameters that represent the dynamic data. Typically, the best candidates for this type of optimization are large sets of data contained in HTML tables, such as product catalogs, shopping carts, and purchase orders—all common among e-commerce Web sites.

Consider a 1,000-line table of products being offered in the OrderEntry scene of our e-commerce Web site. The table repeats a lot of data, including the tag and its many attributes—color, font, etc. When downloading an HTML table with a list of 1,000 items, saving just one character per item reduces the size of the HTML by approximately 1 K. Listing 9 and 10, respectively, show the before and after optimized HTML.

Note the use of the JavaScript function, loadRow(). As you can see, factoring out the common static HTML produces a much smaller HTML file than the original, nonoptimized HTML (665 K vs. 62 K = 90% reduction in HTML size).

Because more processing is required on the client-side, this technique requires a fairly powerful client machine to effectively improve performance. In addition, some browsers display a "Potentially Rogue JavaScript" warning message when the same JavaScript function is repeated more than an acceptable amount (acceptable amount is defined by the browser and not easily configurable in today's browser implementations). Another drawback of applying this technique is that the optimized HTML is almost always more difficult to read and maintain.

A cleaner, more maintainable, more acceptable way to reduce the size of an HTML scene is to use CSS to factor out the common code. The idea is to define "classes" with the common code in a separate style sheet document. The large table would then assign these classes to the and tags of your table—effectively factoring out the repeated, common HTML similar to the inelegant JavaScript technique presented in Listing 10.

CSS was originally designed to improve site consistency and maintenance by separating the data from the presentation. In addition, CSS can improve the performance of your Web site, as many pages reuse the instance of the style class loaded once in the browser.

Listing 11 shows the CSS-optimized table. Listing 12 shows the style sheet maintained in a separate file.

Although this method is not as optimal (665 K vs. 236 K = 65% reduction in HTML size), this is the preferred optimization technique because the resulting HTML is cleaner and more maintainable. The only limitation is that your browser must support the CSS Level-1 specification. Another option is to apply the JavaScript technique to the CSS technique to optimize the HTML even further.

The combination of XML and CSS is even more flexible, maintainable, and optimal than the HTML and CSS technique. Consider a Web page that is purely XML tags and data combined with a style sheet to format the data into a table (available only in a CSS Level-2 table formatting compatible browser).

The ultimate combination in terms of maintenance and flexibility is XML and XSL. XSL does not need to maintain HTML backward compatibility. At press time, neither Internet Explorer nor Netscape Navigator supports XSL natively.

Summary
I made the analogy between movie making and Web site development to overcome the challenges of building and maintaining high-performance, flexible, adaptable Web sites. Next, I built on that analogy by introducing a useful Web director framework to improve Web site navigation and maintenance. By overcoming some well-known HTML and Web browser limitations, I increased the flexibility of our order entry Web site. Finally, I demonstrated some implementation tips and tricks to improve the runtime performance of our Web site—the happiest ending a user could ask for.

The techniques presented here represent a typical example of the best practices continually developed at Bauhaus Technologies. For more information regarding these and other best practices, contact [email protected].