This is part 7 of a multiple part series on web performance improvements. The first Introductory blog can be found here. In previous part we discussed the negative impact of redirects in web application performance. In this part we will discuss how reducing the number of HTTP requests between client and server will help improve the performance.

Whenever user requests any webpage there are a number of trips between client browser and server to get required HTML data and components which are required to render the page. For example in figure below there are a no of calls based on the no of components required for the page. In most of the sites only 10-20% of average time is spent on retrieving the requested HTML document. The remaining 80–90% of the time is spent making HTTP requests for all the components like images, scripts, style-sheets, Flash etc which are referenced in the HTML document.

There is a separate call for each image, CSS, .js or any other file. Due to this there are many round trips from browser to server which increases the page rendering time. Thus, a simple way to improve response time is to reduce the number of components, which will reduce the number of HTTP requests.

What we can do to reduce calls to server

Writing code to reduce get page HTML is key. Techniques like image maps, CSS sprites, inline images, and combined scripts and style-sheets helps us reducing the no of HTTP requests.

1. Use Image Maps whenever possible

In many sites images are effectively used as a medium of communication. Even the hyperlinks, buttons, navigation bar all the composed of images. Then have become integral part of any modern day website. In its simplest form, a hyperlink associates the destination URL with some text. A prettier alternative is to associate the hyperlink with an image. Let’s take an example of following navigation bar. Suppose the navigation bar is formed of 5 different images as shown below.

When the page is rendered there will be 5 calls (1 for each image) to the server, which will hurt the performance of the website. If you use multiple hyperlinked images in this way, image maps may be a way to reduce the number of HTTP requests without changing the page’s look and feel. An image map allows you to associate multiple URLs with a single image. The destination URL is chosen based on where the user clicks on the image. The HTML for converting the navigation bar in above figure to an image map shows how the MAP tag is used:

<img usemap=”#map1″ border=0 src=”/images/imagemap.gif”>
<map name=”map1″>
<area shape=”rect” coords=”0,0,25,25″ href=”home.html” title=”Home”>
<area shape=”rect” coords=”30,0,60,25″ href=”gifts.html” title=”Gifts”>
<area shape=”rect” coords=”69,0,101,25″ href=”cart.html” title=”Cart”>
<area shape=”rect” coords=”100,0,131,25″ href=”settings.html” title=”Settings”>
<area shape=”rect” coords=”136,0,167,25″ href=”help.html” title=”Help”>
</map>

Limitations

• Defining the area coordinates of the image map, is tedious and error-prone
• It is next to impossible for any shape other than rectangles to exact define co-ordinates.
• Creating image maps via DHTML won’t work in Internet Explorer.

Though there are some limitations of using image maps but if multiple images are used in a navigation-bar or other hyperlinks, switching to an image map is an easy way to speed up the page.

2. Use CSS Sprites

CSS sprites are alternative to image maps, which combines images. They’re much more flexible then image maps. In CSS sprites, multiple images are combined into a single image.

Let’s take the previous example with CSS sprites. The five links are contained in a DIV named navbar. Each link is wrapped around a SPAN that uses a single background image, backgroundbg.gif, as defined in the #navbar span rule. Each SPAN has a different class that specifies the offset into the CSS sprite using the background position property:

#navbar span {
width:31px;
height:31px;
display:inline;
float:left;
background-image:url(/images/ backgroundbg.gif);
}
.home { background-position:0 0; margin-right:4px; margin-left: 4px;}
.gifts { background-position:-32px 0; margin-right:4px;}
.cart { background-position:-64px 0; margin-right:4px;}
.settings { background-position:-96px 0; margin-right:4px;}
.help { background-position:-128px 0; margin-right:0px;}

• In case of image map the images must be contiguous, but this rule doesn’t apply to CSS sprites.
• They reduce HTTP requests by combining images and are more flexible than image maps.
• Added benefit is reduced download size. In general people will think the combined image will be larger than the sum of the separate images because of the combined image has additional area used for spacing. In fact, the combined image tends to be smaller than the sum of the separate images as a result of reducing the amount of image overhead color tables, formatting information, etc.

If there are a lot of images in any web page for backgrounds, buttons, navigation-bars, links, etc., CSS sprites are an elegant solution that results in clean markup, fewer images to deal with, and faster response times.

3. Combine scripts and style-sheet (whenever possible)

A site without java-script!!! This thought itself is scaring in today’s website world. Java-script and CSS are integral part of website development and one can not imagine a beautiful site without them. Developers need to choose whether to “inline” their JavaScript and CSS or include it from external script and style-sheet files. In general, using external scripts and style-sheets is better for performance. However, if we follow the recommended code modularize approach by breaking it into many small files; it will decrease performance because each file results in an additional HTTP request.

So to increase performance, if possible, multiple scripts should be combined into a single script, and multiple style-sheets should be combined into a single style-sheet. In the ideal situation, there would be no more than one script and one style-sheet in each page.

For developers who have been trained to write modular code whether in JavaScript or some other programming language, this suggestion of combining everything into a single file seems like a step backward, and indeed it would be bad in your development environment to combine all your JavaScript into a single file. One page might need script1, script2, and script3, while another page needs script1, script3 and script4. The solution is to follow the model of compiled languages and keep the JavaScript modular while putting in place a build process for generating a target file from a set of specified modules.

It’s easy to imagine a build process that includes combining scripts and style-sheets simply concatenate the appropriate files into a single file. Combining files is easy. The difficult part can be the growth in the number of combinations. If you have a lot of pages with different module requirements, the number of combinations can be large.