Caution: Speed ZoneSkip other details (including permanent urls, DOI, citation information)
This work is protected by copyright and may be linked to without seeking permission. Permission must be received for subsequent distribution in print or electronically. Please contact email@example.com for more information. :
For more information, read Michigan Publishing's access and usage policy.
The thrill is gone.
A few years back, we didn't mind waiting 30 seconds or a minute as text and images on the Web cascaded into our browsers from some distant source. But that was then. Now, the novelty has worn off, and when we use the Web, we have a purpose — and we want to get what we need quickly.
Unfortunately, some site designers pay little attention to page-loading times. For example: A colleague recently praised the page put up by the Art Department at my university. When I called it up, however, my first impression was hardly positive. The only thing that struck me was how long it took to load. In subsequent trials over the course of a few days — and with the assistance of colleagues from 30 to 3,000 miles away — the page took from a minute and 40 seconds to two minutes and 37 seconds to load over 28.8 kbps modems. Those times simply are not going to attract many visitors, especially the channel-surfing teens and 20-somethings who would seem to be the target audience for the site.
With ever-increasing competition for a visitor's time, Web publishers need to pay attention to how quickly their pages appear on visitors' screens. Jakob Nielsen, Sun Microsystem's chief Web usability expert, reports that "Research on a wide variety of hypertext systems has shown that users need response times of less than one second when moving from one page to another if they are to navigate freely through an information space." Nielsen acknowledges that the days of Web pages routinely loading in under a second lie far in the future, but in the meantime he suggests that a realistic goal is "to get pages to users in no more than ten seconds, since that's the limit of people's ability to keep their attention focused while waiting." 
Even if the Art Department page loaded in a few seconds, chances are that at least some visitors would be disappointed because there's no content on the page. The page is merely a list of links and a graphic. To access content requires that the visitor wait for another page to load. Fred Sotherland, senior vice president of creative services for C|NET, interviewed in Interactivity magazine, stressed the importance of combining rapid loading times and useful content: "There's got to be a balance between loading speed and consumer value. To present editorial content in an aesthetically pleasing way and to still be fast-loading is an enormously difficult challenge."
Speeding down the information highway
Difficult doesn't mean impossible, though, and Web publishers have a bag of tricks to speed up the loading times:
Keep file sizes as small as possible: It's better to have small graphics and a fast-loading page than large graphics and a slow-loading page. C|NET is striving to keep the total weight of all graphics on a page under 15 kilobytes. If you have graphics that you just have to show off in a large size, include a small thumbnail version on your page with a link that interested visitors can click to view a larger image.
One way to reduce the size of graphics is by limiting the number of colors in GIF files. Programs like Equilibrium's DeBabelizer can remap images from 256 colors down to substantially smaller numbers. The result is files half the size of the originals — or even smaller — with little or no loss in quality.
Use splash pages: A splash page is one that typically has only graphical content. It flashes a logo or other image to the visitor, then automatically — or after the viewer clicks on the page — cycles to another page. By separating the graphics from text, both pages can load quickly. Ferrari uses a splash page effectively on its Web site.
Use progressive GIFs and JPEGs: They provide another way to get a larger image up on a visitor's screen quickly. The images load in several passes, with different portions of the images filled in on each pass. They can be created in popular image-editing programs. I've used a progressive GIF to load the image on my home page.
Use the same images on each page: You can speed up loading of pages after the first if you use the same images on each page. That way, visitors' computers don't have to request new images for each page; the images are called up from the cache on their own computers.
Make graphics, sounds and videos optional: In a recent thread about online storytelling on the online-news discussion list (formerly located at http://clio.lyris.net/cgi-bin/lyris.pl?enter=online-news&text_mode=0), sentiments ran high that while multimedia elements are among the great potential benefits of the Web, no one wants to have to wait while a video or audio clip downloads. It's best to let visitors pick and choose what they want, thereby speeding up initial download time for everyone.
Break big graphics into little ones: That one's debatable. Some publishers use HTML tables to reduce the waiting time for large images. Large graphics are diced into several smaller pieces that can be downloaded simultaneously. Fox Interactive (formerly located at http://www.foxinterative.com/foxinteractive.shtml) — the Fox Network's interactive division — uses that trick. The trick might not always pay off, though. Graphics broken up into several pieces require several requests from the server, which may result in no net gain in loading time.
Use horizontal rather than vertical tables for page layout: Vertical tables — those used most often for full page layout — tend to slow things down:
A browser reads an HTML file from top to bottom, and before displaying anything, it must first figure out where to put it. Which is to say, it must parse a sufficient amount of code to block out the necessary window area. This means parsing until it gets to a horizontal break — of which there are none in tables with long vertical rows ... Also, Netscape [Navigator] tends to read entire tables in a block, juggling lots of variables at once, which inevitably leads to sluggish output.
One solution is to design the page as a series of shallow horizontal tables. Horizontal tables also address the need to get content to the visitor quickly, letting the browser fill out the top of the screen immediately, even if other parts of the page show up a little more slowly. That type of design was used in the makeover of SEARCH.COM.
Preload graphics: If your site includes a series of pages that are likely to be visited sequentially, you can speed up the loading of pages after the first by having graphics preloaded. To do that, at the bottom of the first page you include the HTML code for an image that will appear on the second page. The trick is to use a width and height of 1, so the image doesn't appear on the first page, but is already in the cache when your visitor heads for the second page. The code is simple: <IMG SRC="whatever.gif" HEIGHT=1 WIDTH=1>.
Specify width and height of all images: Don't forget to specify the width and height of other graphics, too. Some browsers will not display a page until every element is loaded unless those dimensions are specified. Specifying the height and width helps the page come up much more quickly, with empty boxes waiting for late-arriving graphics. And don't forget the ALT tags, to give visitors an idea of what's coming their way.
A Makeover for the Art Department
I thought it only fair that I apply those principles to the Art Department Web page that I criticized earlier in this column to see how much difference those tricks can make. The goal was to produce a virtually identical page that loads much more quickly.
The first thing I did was run the animated graphic at the top of the page through DeBabelizer. The program was able to reduce the number of colors from 256 to 16 with minimal loss of image quality; in addition, it noticed that four of the 18 cells in the animation were identical and automatically deleted three of them. The net result was a reduction from 272k to 112k — not within C|NET's standards, but a big change for the better.
The text on the original page was handled by four GIFs. Reducing those graphics from 32 colors to only four made no difference in appearance, and knocked about a third off their weight. But there really isn't any need to use graphics for the text, especially when doing so requires four requests from the server. So I recoded the page to duplicate the text effects as closely as possible using pure HTML, with the help of a one-pixel by one-pixel clear GIF for spacing. (Preserving the text size required either that my makeover would need a wider browser window or that I would have to make the graphic smaller. Because I didn't have access to the original graphic, I chose the former route. Using the <TT> tag would have made the type appear even more like the original, but I couldn't get the spacing to work well with it.)
"Neither of my makeovers addresses the lack of content on the page."
The resulting page loads much more rapidly, taking 20 to 50 seconds in most of my transcontinental trials — although one 8:45 a.m. trial took a whopping minute and 45 seconds to reach a nearby PC.
I also did a second makeover to see how quickly I could get the page to load. On that one, I decided to break apart the banner and the animated text, using only the final cell of the original banner (less than 8.5k) on the main page. If desired, the animation could be added on a splash page that cycles to the main page. In addition, I broke the main page into two small horizontal tables rather than one deep vertical one. With a clean modem connection, this page loads in one to five seconds (worst case was 20 seconds).
Neither of my makeovers addresses the lack of content on the page, but with the reduced loading times, visitors shouldn't mind having to wait for a second page to load.
As Jakob Nielsen notes, "webpages have to be designed with speed in mind. In fact, speed must be the overriding design criterion." No matter how good your content, if it doesn't blaze onto your visitors' screens, they may never see it. In the world of Web publishing, "Better late than never" just doesn't apply.
Thom Lieb is an associate professor of journalism and new media at Towson University in Baltimore. Among his courses is Writing for the Web. He is the author of Editing for Clear Communication and has written and edited for magazines, newspapers, newsletters and online publication. He holds a Ph.D. in Public Communication from the University of Maryland at College Park and a master's of science in Magazine Journalism from Syracuse University.
1. Jakob Nielsen, "The Need for Speed," http://www.useit.com/alertbox/9703a.html 1 March 1997.
Links from this article
Towson University Art Department Web Site (http://www.towson.edu/art/).
Thom Lieb's Home Page (http://www.towson.edu/~lieb/).
Online-news discussion list (http://clio.lyris.net/cgi-bin/lyris.pl?enter=online-news&text_mode=0)
Art Department Makeover #1 (http://www.towson.edu/~lieb/jep/makeover.html)
Art Department Makeover #2 (http://www.towson.edu/~lieb/jep/makeover2.html)
The author wishes to thank Suzanne Bourdess, Steve Konick, Regina Sztajer and Judith Turner for their help in the downloading trials.