- MIRROR sites: closer, faster, non-English -
Save a bit...
asting bandwidth on the Web is the equivalent of talking too much. If you have something interesting to say, people don't mind. Even if your words are not worth much, you may still be entertaining to have around. However, talking too much and saying nothing of consequence is intolerable.
Always be conscious of bandwidth. Bandwidth refers to how much data you can push over your telephone line. The average user is still using a 14.4 modem. You best average throughput is about 1.7 kilobytes of data (1.7k, 1,700 bytes) per second of bandwidth. That assumes that you have a clear connection, are connecting at the optimum compression level, no telephone noises, your PC and modem are able to keep up with the rate of data coming in, your access provider (Netcom, UUNET, AOL, Compuserve, Prodigy) is able to keep the transfer rate at that level, and the source of the data (somewhere out there on the internet) is equally able to feed the data out. If any of those gets busy your average transfer rate will begin to drop.
Most people have trouble with this. ;-) It's true it is all relative. However,
using average modem and access speeds of Web surfers will give us a decent
benchmark. Laura Lemay,
in her highly recommended book
Web Publishing With HTML in 14 Days (Premier Edition)
(Sams.net Publishing ISDN:
suggests that 1k per second is a good meter to measure Web pages by. This
is a modest measure as most sites and modem should be able to exceed this.
Unfortunately I have been on a number of services, at varying times, that
proved how slow connections can get. A Web page with a total of 30k of text
and graphics will take 30 seconds to display. 100k=1 minute 40 seconds. I
think it is a good measure for the status of the internet today. Many sites
and providers don't maintain throughput at levels that match the capability
of 28.8 kbps
This table shows the best throughput for compressed data. Compression can
increase throughput above these numbers, but GIF and JPG have already been
compressed, so don't count on it. Most people will be okay with a page in
the Under thirty seconds range. In the
30 to 90 second you should make sure your page
has something to offer immediately while the bigger items load. Start applying
techniques to reduce sizes of images, reuse cached images, and quicken the
display of the page. Use JPGs with compression (up to 30 on a 255 scale works
well) instead of GIFs. For 90 to 120 seconds
you are pushing it. Hopefully there is a lot to read on the page or all those
graphics are just amazing. For2 to 10 minutes we
have to assume that you have some movie or giant sound downloading. It can't
interfere with content at all. If a viewer has to wait two minutes to see
your page, they are long gone before it ever shows up. Consider breaking
up the page into more edible chunks, smaller clips and sounds with offers
to FTP larger ones.. For the more then 10 minutes
areas, consider a non-HTML format. PDF might compose your page more efficiently.
GIF Animation isn't always best, use a video format for more complex images.
GIF Animations can be used as a slide-show preview of the full movie. Early
AVI formats lacked any real compression. Look at the newest IV32 compression,
or better yet use MPG. Offer large files for FTP not as part of the page.
Browsers, such as Netscape, spawn a separate program for downloading files
in the background so the browser can continue on to other sites. Warn users
of the size and the time.
The Internet is getting very crowded. Millions of useless pages of entertainment and self promotion are swamping servers and T1s. There are a lot of small things you can do to your little corner of the Web.
Images vary from eye-candy entertainment to a vital function of a page. It's up to you to decide which of those apply. Remember, the World Wide Web used to be a place of TEXT, information, ideas, and exchange. While major corporations hit the Web with flashy sites to latch onto the newest marketing craze, the Web is still a place to exchange information, hopefully in a pleasing or entertaining way. The image should say something or provide function. Some images give a feel to the page, that's fine. However, the design of the page should never take away from its function. A text based menu works faster and easier than a great big image map any day.
Once an image has been downloaded by a browser it is placed in the disk-based cache of the PC. If you recall that image on another page (using the same exact absolute address) the image will be instantly recalled from the disk cache, not reloaded across the internet. This will speed up subsequent pages considerably. Using the same image also makes your pages more consistent. They appear related. Reuse the same image off your server repeatedly to conserve bandwidth.
One trick that you may want to use is changing the size of a GIF through HEIGHT and WIDTH tags. Netscape 1.2 or better will scale a GIF to conform to the pixel size set in the HEIGHT and WIDTH attributes of an IMG tag. You could take a larger graphic loaded on a page and scale it down for use as a button or icon. Small images can be scaled up, but scaling up doesn't increase resolution, so the image becomes blocky in appearance.
Yeah right, size doesn't matter! Oh course it does! But what matters more is function, what you do with it. A image should be as small as it can be without making it unusable or inconsistent with the visuals of the page. If you generate a GIF and find it's too big, DON'T use HEIGHT and WIDTH tags to reduce it. A big GIF squeezed down will still take a long time to load. Make your GIFs the right size.
GIF89a-based animation uses LZW compression (a proprietary algorithm patented by Unisys Corp.) This compression is very useful for line art and computer drawings. Ray traced and photorealistic images do not compress well with GIF and are better suited towards JPG, PNG, and motion formats such as MPeG, AVI, and QuickTime, and Shockwave/Director. Using complex continuous tone images will result in large, slow-to-download GIFs. You may want to consider another format for these types of animation.
To conserve bandwidth, do whatever you can to make your image compact and small. There are a couple of areas to work in. Lets start with the individual images.
GIF allows for any number of colors between 2 and 256. The fewer colors the less data and the smaller the graphic files. Not all software will let you set the bits per pixel for GIFs or the colors of the palette. For example, CorelDraw! 4 will export GIFs in 16 or 256 color format. However it uses a set palette. A gradient shading of reds will be reduced to the five or six reds available in the standard palette. Think of it as as lazy painter who doesn't like to mix colors to get it right. Whatever's colors are available on the palette are all it will use. Some programs simply do this better than others. Learn which ones are best.
All of the following programs allow you to set pixel color depth on a GIF. In brackets next to each are the color levels it can handle. An asterisk(*) indicates software that definitely optimizes palettes when reducing. A "T" indicates Transparency support only or "89a" indicates full or near full GIF89a compliance. An "E" indicates a full image editor and "C" indicates strong conversion capabilities.
Also, be careful about what you use to edit your GIFs. Most (and unless your software SPECIFICALLY mentions transparency) will save your GIFs in GIF87a format. This is the older format. If you set transparency, then edit your GIF in one of these programs you will lose the transparent color and any other information from the 89a format(multiple images, comments, controls, loops, etc). If you edit an animation with most programs you will lose all but the first frame of the animation.
The next optimization also has to do with palettes. GIFs have a single global palette at the beginning of the file. This palette is used by default for all the images within. However, GIFs have the ability to store a local palette with each image inside it. GIF palettes use three bytes for each color. That's 768 bytes for 256 color, 48 bytes for 16 colors, and 6 bytes for 2 colors. (Note: Many software programs list 2 color GIFs as Black and White. This is wrong. Two color GIFs can use any two colors. It is an unnecessary limitation of software packages for these colors to be black and white only.) So, a 10-frame 256-color GIF could use a single 768 byte global palette or 7,680 bytes of local palettes. You should use a global palettes whenever possible for all images.
How you construct the animation can make a large difference. A great advantage of GIF89a animation is the ability to do "delta frames" with their own offset. Don't panic...I won't be using calculus or trigonometry-no high school flashbacks. Delta simply refers to the difference. Think of a big sign, let's use this one:
To this sign we want to add the following white letters:
GIF allows us to give a x,y coordinate (or top and left) for each subsequent frame. We can then position the letters at positions inside the GIF. This avoids redrawing and transmitting the entire GIF. Eight frames of the entire picture would be about 16,000 bytes. Our final animation using "delta" frames is only 3,759 bytes. See...
The resulting animation is smaller in size and can execute faster. I have added delays between each letter to stop the animation from running too fast. Several GIF Animation programs now will do this for you automatically. There is one large drawback. If you repeatedly export your frames from a product, such as CorelDraw each frame will not be ABSOLUTELY identical. Minor pixels variations will occur. This is because the image is being mathematically rasterized (turned into a pixel image). Sometimes your round down, sometimes you round up. Consequently, you may find that although you didn't alter a part of the image, pixels colors shift and slight movement occurs. Sometimes this resembles snow on a TV screen. Programs that detect these differences won't reduce these animations much. My Guestbook animation has this problem. Tiny fluctuations in the edges of the pages force redraws of the entire image and not just the pen. Unless you are working with products that repeatedly produce identical images, putting the images together yourself may be more efficient. The delta technique and extensions to it are explained further in the tutorial.
Let's just re-mention using previous cached images, using scaling attributes and multiple instances of a single animation on a page. Each of these cause reuse the images on the user's disk drive. Multiple copies of an animation play very fast, giving you the ability to do interesting mosaic animations.
For more on Bandwidth Conservation, hop over to the
If you have a few minutes, please fill out the Visitor Survey. It will help in making this site better.
(Go to the TOP of PAGE for MENUS)
|Copyright 1996 Royal E. Frazier Jr.||Last Updated: January 1997|