Graphics are both the bane and the boon of a Web site. A text-only Web site can be boring and uninformative. But graphics increase the download time tremendously. A text-only Web site may download in three seconds or so. Adding a few graphics can stretch that download time to 30 seconds or more.
Because an effective site must have graphics, and because graphics can ruin a site's effectiveness, it follows that graphics design decisions are among the most important decisions a Webmaster will make. This chapter takes up the topic of how to design graphics to preserve and increase the effectiveness of the site.
Many different graphics formats are usable on the Web. A trip
through BrowserCaps at http://www.objarts.com/bc/ shows
various formats: GIF, JPEG, progressive JPEG, and exotics such
as XBM and PNG. This chapter examines each of these formats from
the standpoint of quality, compressibility, and download time.
| Note |
To get an idea of what the various formats look like and to see which formats your browser supports, visit http://www-dsed.llnl.gov/documents/WWWtest.html. To learn more about the formats themselves, go to http://www.dcs.ed.ac.uk/%7Emxr/gfx/. |
The human eye can discern far more colors-at far higher resolution-than the best computers. The closest approximation comes from high-resolution monitors (typically 80+ dots per inch) and display systems that can show millions of colors. Images designed for such systems are said to offer "true color." For every pixel, they show 24 bits of color information-one byte of red, one of blue, and one of green. While not up to the standards of the human eye, these images can look quite good when displayed on the proper hardware.
Often, the proper hardware means a high-end graphics workstation or a Macintosh computer. Most desktop PCs use a video card with a 256-slot color table. What this means is that, as a page loads, the first 256 colors displayed in a window get to be in the table. The remaining colors may be dithered out of dots of the existing colors or may be substituted from the existing colors. Neither solution is ideal. This process of allocating true colors to indexed colors is called color quantization.
Furthermore, a graphic often shares the HTML page with other graphics, and the page shares the color table of the browser (which gives some colors to its own borders and other apparatus). Finally, all open applications share the color table of the video hardware. It's not unusual for other applications to "flash" into unusual colors when the browser moves into the foreground. This happens because the old color map in the hardware was replaced suddenly with the color map of the browser.
Each browser has its own limit on available colors. Netscape uses
a built-in 6¥6¥6
color table by default. The colors are all combinations of red,
green, and blue=0, 51, 102, 153, 204, 255 (in hex, 00, 33, 66,
99, CC, and FF). The full table is shown in Table 5.1. Any graphics
that use only colors with those combinations will not take up
additional colors in the color map. Mosaic builds a color map
of 250 colors from the first five images it loads (at the rate
of 50 colors per image). Any colors requested after those 250
are set up will be made by dithering.
| Common Name (where available) | |||
| Black | |||
| Blue | |||
| Green | |||
| Cyan | |||
| Red | |||
| Magenta | |||
| Yellow | |||
| White |
Dithering is a process by which a color on a pixel is approximated with the help of the pixels around it. Suppose that the system color table is full, and the system needs to render a particular pixel. For example, humans are good at spatial discrimination in blue but not at color discrimination in the same color. Blue would be a good choice to dither since a few pixels off-shade are not likely to be noticed, particularly when viewed from the distance of a typical monitor.
For several reasons, there are advantages to keeping the number of colors in an image small. Many developers elect not to use photographic quality images because of their demands on the color map (although, as we will see, JPEG images are well-suited to photographic-quality images and make only small demands on the color map).
Mac users (or developers whose graphic artists use a Mac) have access to a powerful tool named DeBabelizer. DeBabelizer gives the developer access to the color tables of GIFs. If you want to load, for instance, four small images onto one page, use DeBabelizer to merge the color tables and develop one set of colors that makes all four images look good.
Graphic artists should remember that most users (even those with high-end graphics systems) do not have a calibrated screen. This means that users who spend a lot of time getting the colors "just the right shade" might be wasting their time. Even if the color tables aren't filled, the color settings on the user's display might cause a gold to be displayed as anything from a bright yellow to almost green!
Finally, graphic artists acknowledge that some colors just cannot be produced, even among the millions of colors of the 24-bit RGB model. Some colors require access to hue, tint, and saturation values that can only be approximated on the Web. Chapter 33, "How to Add High-End Graphics," addresses the use of high-end graphics to meet specialized needs.
In the future, Color Management Systems (CMSs) such as Apple's Color Sync will become common. These CMSs serve to negotiate between an image and a device to provide high-quality color. With a few exceptions, systems are not currently shipping with CMSs.
Until CMSs become common, experts recommend using a rich image format such as TIFF to preserve color codes. TIFF tags each pixel with information about the three colors (these can be converted from one form to another) and luma (a measure of brightness).
This section describes some terms one hears on the Net about the management of colors in various graphics programs.
The human eye has four types of vision cells: three kinds of "cones" for seeing color, and "rods" for detecting low levels of light ("night vision"). You use only the cones for everyday work on a computer.
In 1931, the Commission Internationale de L'Eclairage (CIE) adopted standards that describe in detail how the distribution of electromagnetic energy is translated into what we call color in a standard observer.
These standards are easier to use when the image glows by its own light, as a CRT-based monitor does. Reflective images, like a photo in a magazine or on some flat-screen monitors, are seen only with the aid of some light source, which brings additional complexity to the problem.
By combining various amounts of red, green, and blue, you can produce many different colors. Luminance can be computed directly from the red, green, and blue components. To the eye, blue appears dimmer than red, which in turn appears dimmer than green-even when all three components are at the same intensity. To compensate for this fact, color analysts weigh green more heavily than red when computing luminance.
To get an even level of brightness on-screen, better monitors give green phosphor more weight than blue or red in computing overall luminance.
Although green appears brighter, humans are highly sensitive to color differences in blue. Very small changes in the level or shade of blue are immediately noticed. In trying to make their monitors bright, manufacturers typically load the phosphors with very intense blue, to try to make up for humans' relative difficulty in seeing bright blue.
Human vision is most demanding in discerning details in areas that are predominantly black-and-white. For sites where visitors are expected to stay and read a fair amount of data, keeping the background a subtle white or near-white and using black for foreground text is wise.
Long before the Internet reached its present popularity, the popular online world was ruled by CompuServe Information Service (CIS). While many people today poke fun at CIS, the service broke ground on some important technologies back when 300 bps modems were common and 2400 bps was considered state-of-the-art.
Way back in the mid-eighties, CompuServe invented the graphical interchange format (GIF).
While there are two different "generations" of GIF, they are similar-and, for most purposes, interchangeable. Nearly all browsers support inline GIF, which means that you can safely put a GIF as the source in any <IMG> tag and expect the browser to display it at its natural width and height.
Nearly all graphics on the Web are compressed in some way. GIFs are no exception. Much of the compression in GIF is done with a technique named run length encoding (RLE).
RLE works this way: suppose that an image has the same color repeated, pixel after pixel, for 58 pixels. The row might look something like the following, where color is represented by an eight-bit number:
10 20 38 38 38 38 38 38 38...38 27 22...
In this example, there are, let's say, 58 pixels in a row of color 38. Rather than store every pixel, GIF makes this shorthand notation:
10 20 [58 copies of 38] 27 22
The actual mechanism is somewhat more sophisticated, but the principle is this: GIFs do their best compression with images that have long runs (particularly horizontal runs) of the same color. This statement applies mostly to line art and simple graphics, and tends to apply less to photographs or photorealistic graphics.
Before compression, the size of a GIF can be estimated this way:
So, an image that's four inches across by four inches high on a 72 dpi screen is about 288¥288 pixels. If that image has 256 colors, the size before compression is around 288¥288¥8, or 81K. Depending on the compression, that same image might compress to around 40K and should take about 29 seconds to download over a 14.4 Kbps modem.
Interlacing rearranges the rows in the GIF file. It doesn't save any room or any real download time. Because users see a full image in about a quarter of the time, however, they perceive that the image loads faster.
Here is the order in which interlaced GIF rows are downloaded:
Every eighth row, starting with Row 0. (Pass 1)
Every eighth row, starting with Row 4. (Pass 2)
Every fourth row, starting with Row 2. (Pass 3)
Every second row, starting with Row 1. (Pass 4)
Most browsers display the rows as they arrive, so the full image is present by the end of the fourth pass. By the end of the first or second pass, the user has a rough idea of what the image is all about and can decide whether or not to continue the download. The user gets the first two passes in about one-quarter the download time of the whole image.
For aesthetic reasons, it's often nice to have a graphic "stand out" against the background, instead of requiring that it sit in a rectangular frame. To get this effect, you can design a GIF89a graphic so that its background is exactly one color which is not used anywhere else in the graphic. Then set that background to be "transparent" using a graphics tool appropriate to your platform. You can get up-to-date information on tools for making an image transparent at http://www.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/Programming/Transparent_Images/.
One good choice for the transparent color is a light gray such as #C0C0C0. It's a good neutral color, so if a browser cannot handle transparent GIFs, the image still looks respectable. Many browsers use this color as their default background, so the image still looks transparent against the default background.
GIFs are a natural for making thumbnails. Thumbnails are a nice way of handling very large graphics that don't compress well. Suppose that you want to display an image library of a dozen images. Clearly, putting a dozen full-size graphics on one page is begging for disaster.
Such a page could be built, however, around 72¥72-pixel thumbnails. At 72 dpi, these graphics appear as a one-inch square. Remember the guidelines given in the HTML Writers Guild tutorial on thumbnails-increase the brightness, saturation, and contrast a bit to compensate for the smaller size. Remember to resample the graphic and then set the number of colors as low as you can. A small graphic sometimes needs fewer colors than the original because much detail is lost anyway.
A 72¥72-pixel image with five bits of color depth gives 32 colors, yet costs only about 1.5K. A dozen such images can be downloaded in about 22 seconds. If they are interlaced and have HEIGHT and WIDTH specified, the user will perceive the delay as only a few seconds. (See Chapter 4, "Designing Faster Sites," for more information.)
Thumbnails make an excellent starting point for LOWSRC <IMG> tags. Suppose that thumbnail.gif is a 72¥72-pixel image that weighs in at 1620 bytes. That image loads in about a second. Now suppose that the image that should be displayed is a 40K JPEG called highResVersion.jpg. Use a graphics program to scale thumbnail.gif to be the same size as highResVersion.jpg, and save it is as lowResVersion.gif. If you use the following statement, a blurry version of the image comes up almost instantly:
<IMG SRC="highResVersion.jpg" LOWSRC="lowResVersion.gif" ALT="Text Description">
| Tip |
Be sure to make the two images the same size or use HEIGHT and WIDTH tags. Otherwise, Netscape uses the LOWSRC size to lay out the page and scales the SRC image to match LOWSRC-probably not what you had in mind! |
JPEGs are nearly a perfect complement to GIFs. While GIFs are best suited to line art or other images with long rows of the same color, JPEGs store their information as mathematical formulas and take no advantage of run-length encoding. While GIFs are limited to no more than 256 colors, JPEGs support 24 bits of color-enough to render the small color shadings in photographs and fine art.
Support for inline JPEGs has lagged slightly behind support for inline GIFs, but the differences are small. Most popular browsers handle inline JPEGs-consult BrowserCaps to find out which browsers do.
Unlike GIFs, which use an indexed color scheme, JPEGs encode the true color into every pixel. Thus, the user is not at the mercy of whatever color table is in use in a given browser when the page downloads (though the user is subject to hardware limitations such as only 256 colors being available).
JPEGs compress much better, too. If it were possible to make GIFs with 24-bit color (it's not-the standard limits GIFs to 8-bit color by definition), a 288¥252-pixel image would be over 200K before compression. GIFs usually get about 2:1 compression, so the image would only squeeze down to around 100K (not very manageable).
The same image in JPEG is about 21K-about a 10:1 compression from
the uncompressed version. JPEGs take more time to uncompress and
display-and, as mentioned above, they're not well-suited to images
with large stretches of the same color or with sharp edges between
two colors. In cases where they do work, however, they work extremely
well.
| Note |
An excellent reference for JPEG is found at http://www.cis.ohio-state.edu/hypertext/faq/usenet/jpeg-faq/part1/faq.html. A site that addresses current issues, such as software versions and compatibility, is at http://www.cis.ohio-state.edu/hypertext/faq/usenet/jpeg-faq/part2/faq.html. An unofficial but very detailed site on JPEG is located at http://www.phlab.missouri.edu/~c675830/jpeg_tests/testgrnd.htm. |
Any user who has spent time on the Web has noticed that GIFs load as they are brought in, either from top to bottom or interlaced. But JPEGs historically have been coded so that they cannot be displayed until all the data has arrived. A new standard on the Web is progressive JPEG. A progressive JPEG has its data rearranged so that the image loads in increasingly better resolution. First, a low-resolution version of the image loads quickly. Then the difference bits between the low-resolution version and a medium-resolution version are sent and displayed. Finally, additional bits to create a high-resolution version are sent.
The overall effect is not unlike interlaced GIFs. The user quickly gets a sense of what the image is, and can decide whether or not to allow the download to continue.
X bitmap (XBM) is a two-color standard vastly inferior to two-color GIF. The foreground color usually is rendered the same color as text, and the background color usually is set to the same color as the browser background. Since XBM files are uncompressed (indeed, they store their contents as ASCII rather than binary data), they average at least three times the size of a corresponding GIF file.
One of the most exciting technologies to come to the Web has been
the portable network graphic (PNG) (pronounced "ping")
format. Contrary to popular opinion, the development of PNG actually
began a few weeks before CompuServe announced that GIF had run
into legal complications-but that announcement certainly gave
new urgency to PNG.
| Note |
What's the story about legal restrictions on GIF? In 1987, when CompuServe began development of the GIF specification, they used a compression algorithm named Lempel Zev Welch (LZW). At about the same time, Unisys Corporation was pursuing a patent application on LZW. In 1993, Unisys learned that GIF used LZW, which by then was covered by a Unisys patent, and the two companies began negotiating an agreement. In mid-1994, that agreement was signed; by the end of 1994, Unisys and CompuServe announced a licensing scheme that mainly affected software developers who wrote code that produced GIFs. Most people feel that the final agreement was fair to all parties. People who view GIFs or use them on their Web pages pay nothing. Developers of software that produce GIFs typically pay a few pennies for every copy of software shipped. Developers of free software are exempt from royalties. The official CompuServe announcement is at http://www.xmission.com/~mgm/gif/pressrelease.html. Unisys's press release is at http://www.spiders.com/tangled/GIF/unisys.html. The full text of the agreement is available at http://www.spiders.com/tangled/GIF/developer.html. Despite this amicable agreement, rumors circulated in late 1994 and into 1995 that GIF was being outlawed and that all GIFs would have to come down. The rumors, of course, were false, but by the time the dust had settled, many developers were looking for a good alternative to GIF. Enter PNG. CompuServe, who had been working on a 24-bit extension to GIF89a, abandoned that effort in favor of the developing PNG standard. See their press release about this at http://www.w3.org/pub/WWW/Graphics/PNG/ CS-950214.html. |
The following are some of the features that excited PNG enthusiasts:
The item about alpha channels bears explaining. In GIF89a, the developer or graphic artist can set exactly one color to be transparent. In PNG, each pixel can have optional "alpha channel" information that says how transparent it should be (from fully transparent to completely opaque).
You can find an excellent description of PNG by Lee Crocker in the July 1995 issue of Dr. Dobb's Journal. The official standard is available at http://www.boutell.com/boutell/png/.
With all these benefits, why hasn't PNG taken over the Web? To start with, it has only been stable since mid-1995-not long enough to become a market leader. Aside from that, there has been a chicken-and-egg problem. Browser developers are hesitant to add code for a little-used standard, and Web site developers don't want to use graphics that can't be widely read.
With the release of Netscape Navigator 2.0, this logjam may break. The newest Netscape product supports PNG. As the installed base for Netscape 2.0 grows, more and more site developers will add PNG graphics. As more PNGs come to the Web, then, other browser vendors will begin to handle PNG files. Keep watching BrowserCaps to determine when you want to add PNG to your site.
The Web was designed originally to meet the needs of high-energy physicists. There was no need for aesthetically pleasing graphics, let alone pretty backgrounds. My, how times have changed!
HTML 3.0 introduced the BACKGROUND attribute to the <BODY> tag. BACKGROUND allows a developer to specify a graphic that is tiled across the entire Web page.
Background graphics must be used with care. For many purposes, clients want large, striking backgrounds. One popular but ineffective design, shown in Figure 5.1, is a background that gradually fades from a saturated color like dark blue to a pastel and down to white. The reason this design is ineffective is that, to look good, the graphic must use up many colors from the color table. Thus, either the background or another graphic later on the page is likely to be forced to dither, with unpleasant results.
Figure 5.1: Gradations can consume all of the colors in the table.
Graphics with this much shading optimize poorly because they do not have long horizontal runs of the same color, and they are inherently large since they need to be wider than the widest screen to avoid tiling to the right.
The best background graphics are very small (but no smaller than 4¥72 pixels), with a subtle pattern that tiles well and does not compete for attention with the foreground graphics and text. One such background, from the Bandwidth Conservation Society, is shown in Figure 5.2. This page can be viewed online at http://www.infohiway. com/faster/4x72.html.
Figure 5.2: Small background GIF.
Background colors should never be interlaced. It also doesn't
make much sense to have your background graphics transparent,
and the behavior of transparent background GIFs is unpredictable.
| Tip |
Heavily filtered backgrounds sometimes have a small gap between copies of the background image, making it look like the background is made up of tiles. To smooth the background, use Adobe Photoshop and choose Filter, Other, Offset. This option moves the boundaries to the center of the page so the image will tile perfectly. You can do the same thing with Kai's Power Tools, using a module called Seamless Welder. |
Netscape took issue with the HTML Working Group, arguing that requiring the download of a (potentially large) graphic is not suitable for developers who simply want to put up a colored background. Netscape introduced the BGCOLOR attribute to the <BODY> tag, and retained the HTML 3.0 BACKGROUND attribute as an option.
For maximum compatibility, Web site developers can use the BACKGROUND attribute with a very small, solid color GIF. Such images compress well and download quickly and can be displayed by most popular browsers, including Netscape.
If developers or clients opt for the simpler solution of BGCOLOR and are content with the fact that pages lack this special background when viewed outside of Netscape, they can at least enjoy the fact that BGCOLOR is set up far faster than even a small GIF.
If you select a BACKGROUND graphic, it's still a good idea to specify the BGCOLOR-set it to a shade close to the dominant color in the BACKGROUND graphic. There are three advantages to this approach:
Netscape allows the developer to set the color of text, links, active links (those that are being moused currently), and visited links. Setting the TEXT attribute does little harm, because the attribute works only on machines that can also handle the BGCOLOR and BACKGROUND attributes.
Be careful, however, about setting a dark BGCOLOR or BACKGROUND. Such a background can make the foreground unreadable. Remember that the <TEXT>, <LINK>, <ALINK>, and <VLINK> tags work only in Netscape. A site with a dark background could become unreadable in a non-Netscape browser, as the text (black by default) is likely to blend into the background.
Many developers struggle with color combinations for <TEXT>, <LINK>, <ALINK>, and <VLINK>. Here are some general guidelines:
Netscape allows the developer to explicitly set the color of text. Resist this temptation. Using COLOR in this way can emphasize text in a manner invisible to other browsers. The consequence is that two different visitors come away from your site with completely different experiences.
Chapter 1, "How to Make a Good Site Look Great," introduced the idea of goals and objectives for a Web site. If the purpose of a site is to display art, like http://www.dse.com/nikka/ then the works are best shown off with JPEGs and thumbnail GIFs should be common. For most sites, however, graphics are almost as incidental as the needs of the physicists who were the original settlers of the Net. Follow their lead-use only the resolution and bandwidth that you need. Use only enough graphics to accent your content, and never so much that you overpower the content.
Mary E.S. Morris, in her article on style at http://www.sun.com/950801/columns/MaryMorris.col9508.html proposes the following experiment:
Find a group of people with a common interest such as cats. Show each of them ten Web pages on cats. Half the pages should be rich with content, the other half should be heavy with graphics. Twenty-four hours later, see which pages are remembered by the members of the group.
Her conjecture is that the content-rich pages would win hands down.
As a Web developer, you have a limited amount of time in which to make an impact on the site visitor. Every second you keep the visitor waiting is wasted time. Every second you spend downloading a graphic that doesn't support the goals and objectives of the site is wasted time. Yet, if a site contains no graphics, many people come away unimpressed and unmotivated.
This section assumes that you have made the hard decisions about which graphics do-and don't-support the site's objective. It also assumes that you have followed the guidelines from Chapter 4, "Designing Faster Sites," to make the site load faster. Nevertheless, the site is still dominated by graphics download time, and you would like to reduce that time even further.
Here's where the Bandwidth Conservation Society can help. The BCS is a loosely knit group of graphic artists and Web site developers committed to finding ways to shrink graphics without shrinking quality. The BCS site is available at http://www.infohiway. com/faster/index.html.
Earlier in this chapter and in Chapter 4, "Designing Faster Sites," we talked about getting the physical size (HEIGHT and WIDTH) as small as practical. The BCS advice begins after you have already pumped out all the size you can that way. Here's a summary of their recommendations:
While many developers are aware of the savings to be had by using the HEIGHT and WIDTH attributes, few Webmasters think about the third dimension-color. As we saw at the start of this chapter, each pixel has one or more bits of color or gray scale information. The more bits you have available, the more colors you can represent. Without question, most GIFs on the Web are set at the default 256 colors. But, as BCS examples show, reducing the number of colors in the color map can dramatically decrease the size of a file with very little loss in appearance.
The site, http://www.infohiway.com/faster/compare.html, shown in Figure 5.3, points out the increase in quality when moving from the default Macintosh palette to an adaptive palette in Adobe Photoshop.
The site, http://www.infohiway.com/faster/compare2.html, continues the discussion by showing how to cut image size by more than 70 percent with only a slight loss in quality; this is done by reducing the image from its original eight bits to just five bits.
In http://www.infohiway.com/faster/crli.html, the BCS observes that, because GIF optimizes around an (RLE) algorithm, you can insert one-pixel, one-color horizontal bands at regular intervals in the image to further reduce graphic size. As shown in Figure 5.4, there is a cost to this CRLI.
The final image in this CRLI series is quite dramatic. As shown in Figure 5.5, the image at http://www.infohiway.com/faster/crli2.gif is 496¥372 pixels. If this image at this size were saved using a conventional 8-bit color map, it would be over 90K in size and would take a full minute to download over a 14.4 Kbps link. With CRLI and a 4-bit color map, its size is only 19K, and it downloads over a 14.4 Kbps link in about 13 seconds.
Figure 5.5: A dramatic reduction in this large image has been achieved.
If you or your graphic artists use Adobe Photoshop, use this sequence to get further savings. (Other products have similar features under different menu choices.)
Choose Mode, Indexed Color. Figure 5.6 shows the dialog box that appears; this is where Photoshop converts true color to indexed color.
Figure 5.6: Adobe Photoshop Indexed Color dialog box.
Choose the Adaptive option button, and begin to explore how low you can set Resolution before quality becomes unacceptable. For a given image at a given resolution, experiment with choosing the None option button. This change often saves at least ten percent but might not have an appreciable effect on appearance.
Unlike GIF and PNG, JPEG is a lossy compression algorithm. This term means that, if you save a file as a JPEG and then open it and resave it, some of the original information will be changed. Typically, these are small shifts in color in a few pixels. Because the human eye is relatively insensitive to such changes, and because most graphics cards cannot display enough colors to make the effect noticeable, the loss of quality can be negligible.
Photoshop and other tools give the graphic artist great control over JPEG quality. Sometimes it makes sense to reduce quality to very low settings. For example, if the image serves as a background with text covering it, visitors to the site are not likely to examine the background in detail.
Take a look at http://www.infohiway.com/faster/venetian.html. The background JPEG is just 72 bytes. Figure 5.7 shows a "low-quality" JPEG.
Recall the example Real Estate site introduced in Chapter 1, "How to Make a Good Site Look Great." That site can be made more effective by allowing realtors to add photographs of the properties they have on the market. Here is a process for preparing such a page.
Figure 5.8 shows a typical listing page. Figure 5.9 shows the detailed image a user sees after clicking the thumbnail on the listing page.
Figure 5.8: Use a thumbnail on the listing page to keep download time low.
Be sure to add HEIGHT and WIDTH attributes to each <IMG> tag. Also remember that progressive JPEGs will reduce the burden on visitors looking at the homes, so look in the JPEG FAQ to find a program that will support progressive JPEGs on your platform. If you use Adobe Photoshop, you can do the job by adding a shareware plug-in.
Graphics are a key element of site effectiveness. Few Webmasters want a text-only site, but as soon as they start adding graphics, the download time increases. The Webmaster must carefully choose the file format of each graphic and should tune each graphic for minimum size and download time.
Once a Webmaster has effective copy, embedded it in validated HTML, and tuned the graphics of the site for minimum download time, he or she has done about everything that can be done to ensure the effectiveness of the static pages of the site. The next chapters introduce the idea of dynamic pages-running programs that make at least a portion of the content change depending upon real-time events.