Slow speed kills

| Companies to help your speed | Add some PEP to your Web site | Review: Use only as directed | How we did it | Interactive Buyer's Guide | The promise of FineGround | Scorecard and NetResults |

When it comes to user satisfaction with Web sites, lack of speed kills. Pages that don't download quickly - some say in less than 8 seconds - result in frustrated users who leave sites, abandon shopping carts and generally take a negative experience away from their site visit.

With the new "back to business basics" trend for Web sites, serving more customers more quickly, and with less bandwidth and fewer servers, has created a new boom industry in Web site acceleration products.

Web site acceleration can be troublesome to pin down. From a user's perspective, a site is either fast or slow. Users tend not to account for the amount of bytes transmitted, hops taken, number of other users on the site, and many other factors. Time is truly of the essence for Web users.

For site managers, the components that potentially cause delays are numerous. Three major components to worry about are the server, the network and the client (see graphic above). For consumer Web sites, site managers have the most control over the server and the least over the client, with a variable amount of control over the network.

Speed and scale

Before discussing the various schemes for improving Web site speed, it is important to clear up the relationship between speed and scale. When a site has too many users, the server will become overloaded, and the site will slow.

If you add more servers and use a load balancer or clustering solution, you'll be able to scale the site, and the site's performance should return to a more acceptable level.

However, while the site may appear faster to end users when properly scaled, performance isn't necessarily improved over what it would be had capacity been planned for. But, if you manage to improve a site's performance you generally improve capacity.

When pages are served faster by limiting server workload, or avoiding the server altogether with a cache or content delivery network (CDN), the site is freed up to handle more users.

Soup-up your server

Speed obviously can be improved with faster disks and better network access setups. You can even look to specialized cards such as Akamba's Velobahn to improve server speed, or to souped-up network interface cards from Alacritech. The heart of such solutions is to relieve the Web server's CPU from dealing with network protocol processing, freeing it to concentrate on page generation and serving.

Another important server-side opportunity for site acceleration is looking at the Web server software. If you are trying to squeeze out extra server performance, check out the long-standing Web server speed-leader Zeus.

In the next few years, Web server appliances with highly optimized, embedded operating systems and servers will even give Zeus a run for its money.

Cache it if you can

Another way to squeeze more scalability and performance out of a server is to add a cache to the mix. A popular approach is to add a reverse proxy cache to a Web server to deliver pages that have already been created and only burden a server for dynamically created content.

It is easy enough to build your own cache using Squid, or you can buy one of the numerous hardware-based products, ranging from the moderately priced Sun Cobalt CacheRaQ to higher-end cache appliances from CacheFlow. Shop carefully: Many hardware caches are repackaged Linux servers running Squid software.

One downside of caches is they often do not deal with dynamically generated content very well. For truly dynamic pages, you may find pages display slower when a cache is involved. Various dynamic-content caching solutions have been proposed. (See page 56 for an in-depth look at four such solutions, and how extracting performance gains from dynamic content often require some serious work and technical know-how.)

Close in on users

Networks present serious challenges for page delivery. No hosting vendor is immune to traffic or router problems, nor will your site be close to every user unless you design it that way.

You could set up multiple servers around the world and use a global load-balancing device such as Radware's Web Server Director to route users to the closest site. Or you could employ a CDN, such as Akamai or SolidSpeed, to move site content closer to users by placing large static page objects such as images and PDF files in caches close to users.

With edge networks, the bulk of a Web page's content arrives to users quicker, and is less prone to traffic problems encountered along the way.

However, CDN services tend to be expensive and require rewriting accelerated pages to reference cached objects. The recently released Edge Side Includes (ESI) specification aims to improve the problem of authoring content for dynamic assembling and delivery using CDNs, which should help bring edge network delivery to the mainstream once network prices begin to fall.

Smaller is generally better

Compression can be used to shrink data to be delivered, thus generally speeding up a site. Traditionally, images and other binary formats have made up the bulk of Web page delivery payloads. Web developers have focused on the use of color reduction in .GIF images or adjustments in JPEG files to reduce file size. See BoxTop Software for some of the best of such tools.

Additionally, browsers are making the use of portable network graphics images a reality, although JPEG2000 seems to be some time off. Those interested in delivering extremely large image files are encouraged to avoid standard Web formats altogether and look into advanced imaging formats such as MrSid and DjVU, commercially released by LizardTech.

With the increased complexity of HTML documents and the heavy use of JavaScript, compressing pages by reducing the white space in an HTML or JavaScript document can result in significant file-size savings. Beyond such methods, browsers that support HTTP 1.1 also support GZIP file encoding, which compresses files before delivering them. Web servers, such as Microsoft's Internet Information Server 5.0, support this.

However, while common sense says that fewer bytes delivered equals a faster site, the compression/decompression time of a delivered object must be worked into the equation. Heavily compressed files may require less bandwidth but may not actually render any faster to the user.

Client override

Compression, distribution, caching and other approaches really don't matter if in the end the user doesn't see the effects. The "click-wait-consume-click" pattern employed by Web users suggests that you could take advantage of idle time to download content.

Fireclick and a few other companies have tried this approach. If you consider installing software on the client side, significant improvement might be possible as promised by technologies from vendors such as Datagistics.

Finally, the user's system can override all your hard work, and site managers don't have much control over the client's setup. Pages simply may not render quickly because of poor system setup, numerous applications running, disk fragmentation or a slow browser. Oddly, browsers are notorious speed hogs yet are rarely mentioned when discussing site speed. Try Opera Software's 5.0 browser and watch it easily outperform Internet Explorer and Netscape. With Opera, the Web might just seem faster. And for end users, Web acceleration can really be as unscientific as that.

---

RELATED LINKS