As well as moving data from the server to the client during browsing, we also have to send other files. In particular graphics can make an application appear to respond slowly, and this can give a poor impression of our site and our products. While you can't speed up the users connection, you can use the time that they spend reading a page to advantage.
One way is to make sure that graphics are cached early on, and this is what we do in our Wrox Car Co Web application. As the user is reading the introductory page, with its animated titles and list of models, we are downloading and caching the larger graphics required for the car details pages. Unfortunately, how successfully we can do this, and therefore reduce the number of connections required in other ways, depends on the client browser's capabilities.
To reduce client connections as far as possible means making maximum use of the client browser's features. This means that you need to decide early on which browsers you are going to support. Until there is a more universal level of compatibility between different versions this is not an easy task.
For example consider how we might go about changing the color of an image, like we do with the car images in our application. The universal approach would be to have a graphic in each color for each car. However this means that we have to load around ten times as many graphics if the user chooses to see all the colors. Besides, except in the latest browsers, we can't change a graphic without reloading the page—so even more server connections are required.
In Internet Explorer 4 and higher, we can use color light filters to change the image color, but these are not ideal as, without a lot of image-specific coding, they tend to affect the whole image. The way we've chosen to do it is perhaps the simplest of all. We make the 'colored area' of the car transparent in the image (a standard 256 color GIF file), place it in a table cell, and change the background color of the cell on demand. This is fast, looks acceptable, and requires no server interaction. With more professionally designed graphics it would, of course, look even better.
If we are going to cache the data about the cars and colors locally on the client, we have to have a way of creating the pages dynamically in line with this data—and without connecting to the server each time. This can be done easily using client-side scripting, probably with JavaScript or VBScript. This means that we need a browser that supports scripting and provides a relatively standard object model to script to.
Finally, we wanted to provide features that make the user experience more intuitive—by indicating which model was selected with a different color title, and by changing the text content of parts of a page as they worked with that page. Again we could easily do this with ASP and a round trip to the server, but we're looking to decrease the number of client connections, not increase them. The answer is Dynamic HTML, which is supported from version 4 in both mainline browsers from Netscape and Microsoft.
This book isn't designed to be a discussion of browser compatibility, and we'll take this subject no further here. If you want to know more about this topic look out for other Wrox Press books such as Instant HTML 4.0 Programmers Reference (ISBN 1-861001-56-8); and Instant Dynamic HTML Programmers Reference which is available in two editions—for Netscape Navigator (ISBN 1-861001-19-3) and Microsoft Internet Explorer (ISBN 1-861000-68-5).
At the end of the day, we chose to build our application to run on Internet Explorer 4/5. That's not to say that we couldn't have done the same with Navigator 4 or 5, which also support client-side scripting and a version of Dynamic HTML. What would be considerably more difficult, though by no means impossible, would be to build it in such a way that it ran on any modern browser. This is where you need to consider your target market, and the way your application will be implemented.
We're not proud of our choice to support only one browser, but this book (and this chapter) is about implementing and interfacing with back-end services rather than which browser we actually end up supporting. You'll have to make the difficult choices yourself, balancing features and benefits in line with the intended market for your own applications. The techniques we used can be modified to suit your choice of browser, or extended to offer more cross-browser support as required.