Graphics Performance Tuning
Real World Web
by Jay Lorenzo
Not all users have T1 lines. Here's how to optimize download speed without compromising quality.
Let's start this column off with a discussion of some Web basics, focusing on some of the issues Web content developers face when attempting to increase the graphics performance of their Web site. By now, it is fairly obvious to all involved with the WWW that smaller file sizes translate into faster downloads. Although many corporations and academic sites are fed with T1 and faster connections, the general browsing public is primarily connected via modem-based SLIP and PPP connections. Web sites that are optimized for slower connections are being rewarded with higher volumes of traffic.
Most people tend to think of total pixel size when attempting to reduce bandwidth. Good design can minimize the size needed to convey a certain impression, and it can't be stated too often that graphic designers should always strive to minimize the pixel density wherever they can. What may not be so obvious is that file size is directly dependent upon the number of colors that are incorporated into a particular graphic.
One of our original goals at WRQ was to create a technical-support Web server that gives users the ability to access a graphics-enhanced Web over 9,600-bps SLIP and PPP links. We obtained this by specifying a six-color palette for each graphic, thereby minimizing the number of colors in a given image. Note that each graphic may use a different six-color palette--but be aware that some browsers will take their time displaying graphics when this approach is used, particularly if the image is interlaced. At WRQ, we tend to minimize jagged edges on graphics through anti-aliasing, a process that creates the visual effect of smooth edges between contrasting colors. This is achieved by blending the colors of the border pixels into two or more interim colors. We try to design these graphics with colors that can be used in the main image and still provide anti-alias support to graphic borders.
The home-page banner graphic that resides on our main Web server home page takes a different approach to this same subject. Typically, a main graphic starts out as a 1 MB or larger Photoshop file designed within our marketing communications group. We attempt to subtract and dither as many colors as possible from the image without losing visual impact. If it appears that too much content is lost, we will attempt to redesign the graphic to use a more suitable color table. We then index the colors and convert the graphic to an interlaced GIF file, and create an image map if it is to be used as the banner graphic. Indexing is a process handled internally in Photoshop, where you take a graphic with multiple color channels and multiple layers, and convert it to a flat graphic, which requires you to isolate each color component.
Our current banner graphic is a one-piece design that was reduced to 63K for a GIF file and 35K for JPEG. Browse http://www.wrq.com/techweb/mosaic/webtips/graphics.htm for an idea of start and finish graphics for this banner, which will hopefully provide a better explanation of the steps taken to do this.
When dealing with large complex graphics, it is sometimes more effective to break graphics into separate pieces and tile the components together. This results in the same color content as the original, but the total file size of the component pieces is smaller than that of a single image. There are two potential downsides to this approach: You may need to rely on the browser to understand <IMG BORDER> tags to create a seamless image, and you are effectively creating more load on your server by creating additional requests. In highly loaded environments, a server may not return all of the component pieces. That being said, it does make sense at times to take this approach, especially if the design incorporates areas that contain give a good deal of thought to the use of <ALT> name tags when taking this approach.
Never lose sight of the fact that performance is very much a matter of perception. Creative use of push/pull animation and lead-in text can provide the user with the perception that the page downloads quickly, when in fact there may be a substantial amount of download occurring. Another excellent practice is to use <IMG HEIGHT> and <IMG WIDTH> tags to define the height and width of a graphic, which allows users to interact without experiencing any page reformatting as new graphics are being displayed. It may seem trivial, but a page with numerous graphics can consume a good number of seconds, as the page is continuously updating text while graphics are being displayed.
Fun with Formats
Some sites dynamically load high-bandwidth documents to achieve a desired effect. A good example of this approach is the page found at http://www.next.com. Conversely, one of the most abused "performance" tricks used on the Web is the use of interlaced graphics. I know I will get a lot of mail on this, but in real-world performance, the amount of time taken by many browsers when displaying multiple images of non-uniform size can take significantly longer when interlacing is used. As with most techniques, interlacing can be a good thing, but you should always consider the potential consequences of doing so.
Since many browsers now display JPEG images inline, it is always a good idea to consider whether or not JPEG is a viable alternative for many graphics, particularly those that have a great deal of pixels or colors in them. As you might expect, JPEG comes at a price, since it requires more CPU effort by the client platform to render the image. It is probably a bad choice if your target audience is not currently running 486-class PCs. The reduction in file size can be substantial, though, and should always be considered when the primary target audience is on slow dial-up links.
As with every aspect of Web development, you are dealing with tradeoffs, which typically pit content against performance. Now that you have read my take on some of the issues involved with graphics tuning on a Web site, let me know what you think by mailing me at jayl@wrq.com. We'll discuss your responses in an upcoming issue.
Jay Lorenzo currently spends his time overseeing administration of the internal and external Web servers at Walker, Richer, and Quinn. He is a partner in Strings, a Seattle-based Internet consulting company.
Reprinted from Web Developer® magazine, Vol. 1 No.1 Winter 1996 (c) 1996 internet.com Corporation. All rights reserved.
Web Developer® Site Feedback
Web Developer®
Copyright © 2000 internet.com Corporation. All rights reserved.
