Despite optimistic predictions about ubiquitous broadband Internet access, a huge percentage of Internet users still access your Web site at a pathetic 56Kbps. In fact, I'd wager that nearly 50 percent of the user population visits sites at substantially less-than-snappy DSL or cable-modem speeds. In the late 1990s, the erstwhile Zona Research published an oft-quoted study that showed that most users will leave a Web site if their requests aren't satisfied within 8 seconds. That might seem like a long time, but you'd probably be surprised at how many sites fail to fulfill that expectation. To make sure your site isn't one of them, you need to understand the page-design factors that affect performance, develop techniques to improve your site's performance, and regularly monitor and measure that performance.
How Site Design Affects Performance
End-to-end Web site performance is a function of several factors besides how a page is designed. For example, if a typical multi-tiered application infrastructure sits behind your Web servers, the time required for something to appear on the user's desktop will be the sum of the times that each tier (e.g., application server, database) takes to satisfy its portion of the user's request. Most multi-tiered Web applications are composed of many different third-party products (e.g., business logic based on Java 2 Enterprise Edition—J2EE—servers, Active Server Pages—ASP, or Microsoft SQL Server or Oracle databases), but tuning response time for application-server and database tiers is outside the scope of this article. I concentrate on the things you can do in the "presentation" tier (i.e., designing the pages that users see in their Web browsers) to ensure that, as long as the rest of your application is humming, users will have a good experience.
Web pages that contain a lot of objects (e.g., .gif files, frames, style sheets) are slower to display than those with fewer objects. Add Secure Sockets Layer (SSL) and its handshaking process to the mix, and you further increase both the time pages take to download and the processing horsepower needed to serve those pages. In particular, pages with frames are quite slow because the browser treats each frame as a different object that requires a new connection. If you're building a page with performance in mind, less is more: The fewer objects on a page, the quicker that page will arrive at the user's desktop. Fewer objects correspond to fewer TCP connections that the browser must create and maintain. When you can, combine multiple objects that are spatially close together on a Web page into one image file.
Object size also can affect performance. TCP/IP packets typically hold 1460 bytes of data in addition to the packet header. So, if a .gif file on your page is 1461 bytes in size, an extra round-trip between the browser and your Web server is required to bring down that extra byte. To minimize round-trips between your Web server and the user's browser, try to limit the size of objects to multiples of 1460 bytes or combine small objects into one object that doesn't exceed that size.
Another aspect of page and site design that affects performance is whether your pages are static or dynamic and whether static objects and pages are set to expire immediately or after an interval. Modern e-commerce sites are serving up increasing percentages of dynamic content. From a user's perspective, having a lot of dynamic content is good. However, from a performance perspective, dynamic content presents some challenges. A benefit of static HTML content is that you can cache it at various points between your Web infrastructure and clients. Reverse proxies, forward proxies, and browser caches can typically handle caching of static content. When a page is cached, clients don't have to get the page from the Web server each time they request it, so pages appear quickly. However, because dynamic content is just that—dynamic—it doesn't benefit from caching unless you use a product such as FineGround Networks' FineGround Condenser Acceleration Suite 4.0, which uses a caching approach to speed dynamic-content delivery (I discuss FineGround Condenser Acceleration Suite later). However, you can use some techniques and third-party products, which I also discuss later, to optimize delivery of dynamic content. If your dynamic site's performance is suffering, you should consider one of those approaches.
Everything I've mentioned so far illustrates the tension between building rich Web content designed to attract viewers and presenting that content speedily to users who visit your site through "bandwidth-challenged" connections. Let's look at some techniques you can use to optimize Web page delivery over slow connections.
Using Compression
One easy solution for speeding delivery of static HTML content won't cost you a dime, yet you might not know about it. Gzip is a standards-based compression protocol that most Web servers (including IIS, Apache, and Sun Microsystems' Sun ONE Web Server—formerly iPlanet Web Server, Enterprise Edition) support. Gzip lets you send compressed static .html files to the browser, which automatically expands and renders them. Both Microsoft Internet Explorer (IE) and Netscape browsers support gzip decompression natively (for gzip compression to be recognized, IE requires that you enable HTTP 1.1).
Enabling gzip compression of static HTML files and dynamic ASP-based applications in IIS 5.0 is straightforward. On your Windows 2000 server, click Start, Programs, Administrative Tools, then select the Microsoft Management Console (MMC) Internet Services Manager snap-in. Within the snap-in, right-click the server's name and select Properties. In the Master Properties dialog box, select WWW Service, click Edit, then choose the Service tab. As Figure 1 shows, the HTTP Compression section lets you enable and disable compression for both static and dynamic pages (i.e., .asp files).