No one likes to sit there for 5, 10 15 minutes while a screen slowly loads with a page sent across the web. But some people will get charged extra for hours beyond 20 or 30 their access service provides at a flat rate. Some schools -- in Minnesota, for example -- have fixed monthly InterNet access hours. When those hours are used up, you're shut off till the next month. Even if you have an unlimited-time InterNet account, you don't have unlimited time to spend surfing the web. At schools, at work, there are others who want to use the computer; and normal people (which I used to be before getting into doing these pages!) have other things to do in their lives. For everyone, therefore, time should be a major consideration in web page design.

Unfortunately, it's all too easy to fall in love with a gorgeous page you created, using several huge, slow graphics. If that's your startup page, it may indeed be worth the load wait -- the first time it's seen. But if it's your startup and main menu that will be seen again and again, that's bad design, inconsiderate of your users (who likely won't be back).

This tutorial shows some tricks for reducing the time it takes your pages to cross the web and load. It assumes you are somewhat knowledgeable about HTML (say, by having taken the Maricopa tutorial and created at least one page that way), and that you've used paint-type (or bit-map) graphics programs some.

Vocabulary for this section:

GIF -- the Graphics Interchange Format which compresses bit-map (paint-type) files somewhat and can be understood by almost all types of computers. GIF standard 89a lets you do transparent backgrounds and a multi-pass loading effect that gives you a big checkerboard that gets more detailed with each additional pass. The extensions of GIF files are generally FILENAME.GIF.

JPEG is a bit-map file format that can save more colors and do much tighter compressions (but the read-back may lose info and become blurry if compressed too much). It stands for Joint Electronic Photography Group. You can't do fancy effects with JPEGs. The extensions of JPEG graphics files are generally FILENAME.JPG, occasionally some other extensions are used.

So this isn't about timesaving page construction tricks. It's about creating pages that -- while looking great -- cross the net and load AFAP. This means that you spend more not less time in construction. I went to a hard school to learn some tricks. FDL's server is 56 kbaud, just about as slow as you can get. It becomes very slow indeed when there are simultaneous users on-campus, and surfing in from afar. There are several general principles of designing for speed-loads:

1. Reduce the size of your graphics files. There are several ways to do this.

   
   

   You should (almost) never use a pic bigger than the browser window anyway (which means a height max of about 250 pixels, and a width max of about 550 - 600 pixels).

   If your graphic is bigger than this, you can crop it (which loses no info, keeps it sharp) or shrink it (which loses info, and you'll probably want to use paint program enhancement tools to get back some of its quality).

2. Reduce filesizes by using higher JPEG compression, for photo-type graphics. If they are GIF's, you can do color-reduction. LViewPro does great, for PC's; Big Pro expensive PhotoShop can do even more). Here's what I mean:
   
   

   There are 5 levels of color in graphics files: 2-bit is 2-color, black and white, or (with color conversion) any 2 colors. 2-bit graphics are the smallest possible files of the type. 4-bit files contain a maximum of 16 colors. 8-bit (the largest you should ever use on the web) contain up to 256 colors, and can give true photo-realism if a color reduction (dither) algorithm is used. 16-bit files would contain 32,000 colors and 32-bit files contain up to 16 million. In professional printing, the last is what's used. Filesizes are immense; 90 megabytes wouldn't be unusual. Let's look at JPEG, the compression standard most often used for photo-realistic images.

   Don't compress JPEGs in trucolor (24-bit zillions of colors), or 16-bit (32,000). Use a paint program's file conversion method to reduce it to 256 indexed colors (the reduction algorithm most likely if named is adaptive diffusion). Then use the JPEG converter and set compression to 50%. This is the smallest form of JPEG which is looks reasonably good when decompressed and read by the browser. It will be about 10 times smaller a file than a 24-bit JPEG compression. (If you reduce colors to 32 or 40, and then compress, the JPEG graphic file will be bigger than if you started with 256 colors.) JPEGs created this way are smaller for the same file than 256-color GIF's, unless you can color-reduce your GIF's by diffusion dither to 16, 32 or 40 colors.

   Often you can do very nice spot color graphics, of 16 colors (including black, white and any background you want to make transparent). Often, a graphic you developed in trucolor looks quite nice reduced (adaptively) to 16.

   Photo-realistic GIF's can sometimes look fine, reduced to 32 colors and almost always at 40. The resulting file is then just about the same size -- or just a little smaller -- than a 256 color JPEG compressed 50%. It has the advantage that you can have a transaprent background to float it, and sometimes the color-reduced JPEG is actually clearer and sharper than the 50% JPEG.

   There's another advantage: the server has only 256 palette index positions to use (on a page) for color info. If you have several 256 color images, the same colors on each are not going to receive the same arbitrary index numbers, so there will be color distortions. If you use graphics which use up fewer of those index numbers, they will be sent and seen pretty much as you prepared them, without palette index conflicts and color distortions they cause.

   This adds up to spending quite a bit of time fiddling with all the graphics you plan to use, to streamline them for fastest cross-net transfer, to minimize the time the user will sit there waiting for your page to load.

   
   

3. Reduce the number of graphics that appear on a page. There are several ways to do this.

   
   

Now we're going to take a little smiley trip. One way to avoid too many grahics on page is to free float them. Another way is to spawn more and more pages.

So, back now from the Smiley Fool trip, eh? What, didn't go? Punch that second Smiley Fool button just above, cuz I'm gonna talk about the Smiley Fool trip.

I mentioned at the end of FAQ's tutorials page that the violet rod, used quite frquently on these pages instad of <HR> for both a separator and a design unifier is a graphic, but doesn't "cost" that much in time. Here's why. The server looks at the called HTML doc it's gtting ready to send in pieces across the net, and sees that certain items in it are used again and again.

It sends each of those items just once across the net in all the little data-pieces it breaks up everything into. Your system saves it just once in a coded file in your NetScape cache subdirectory. Netscape - the - browser looks at the received doc and loads each graphic into a piece of memory. It displays that piece as many times as it sees codes calling it in the HTML doc which contains the text and the layout info -- the page -- it has received.

That visual display reptition does take a little time -- you may see a colored line outlining a "saved" place where Netscape is going to put the graphic image when it gets around to that. But comparatively little time is used by the repeated use of the same graphic (if small). Hence all these clock buttons and purple pins on this page cost very little in time, and the repeated violet rod (though it's a larger file it is just a 4-bit GIF) just travels once also.

Some people use little colored balls or tack-heads repeated all down the left margin of a menu. The file is very small (this one's a 4-bit pin, shadow and all, just 128 bytes) . Repetitions of the identical graphic carry very little time-penalty.

Consider the Smiley Fool page. In addition to the 2-bit large graphic at the top of the page, the small button was repeated many times: as click-button icons on the Smiley Fool Research Project Menu, several times as repeated buttons elsewhere, and a row of them wishing you a nice day-yeee, in typical vacuous NewAger style.

What about that whole page of Smiley Fools we fled? For that, I made a background tile -- still 2-bit, just 2 colors, but I brightened it some because no text color showed well against it -- and used BODY BACKGROUND to call the tile (which is automatically repeated over any number of screens, if your page is long) instead of BGCOLOR which sets a single color.

You can see a more usable background (because it's been bleached down to very pale colors) on my GAMES page. There, I punched up a rainbow glass marble (which is a JPEG graphic, to preserve the color gradations) as a logo, shrank and bleached it, and then (since color gradations are lost anyway) reduced it to a 16-color 54-bit small graphic, which is used as the background tile. The file takes too long to load (that'll be fixed in the Big Re-org going on) but that's because there's too much text, in those menu tables. The fix will be to make each category of edutainments a file containing the single table for that type.

Smiley Fool's main page uses a single BGCOLOR definition in the doc header, which results in a weave of pixels. I'v seen all too many such which are illegible, because the multi-color weave fuzzes the smaller type, so I always set all type to bold the simplest way -- by using the HEADER text mark <H$> which causes the main body text -- whatever color I've chosen for text -- to be bold.

Why we did the Smiley Fool Project is a very simple screen with one trick. The colors header sets the click text to dark blue --same as body text, if I'd had any -- but with a white flasher, and a red "already been there" cachetext color. Let's check that out now. Use VIEW SOURCE when the Dark and Stormy Night page is loaded.

As you could see from VIEW SOURCING the header, that LINK= defines the initial color of linktext: #000041, with the 4 zeroes saying "nothing from the red and green vid monitor guns" and the 2 low numbers in the blue position of the 6 color digits setting a blue as dark as it can be without turning black.

How did the trip keep returning you right to the Smiley Fool Project menu, instead of the top of the doc, with his big blank face? That was done by setting the anchor marker <A NAME="mark"> just above the Smiley Fool Project Menu, and using the anchored file call <A HREF="smiley.html#mark"> to get back to that point within the doc. I used another MARK anchor to return from the end of Smiley Fool's menupage (smiley.html) to the point where we departed this page (ticks.html) you're on now, for the Smiley Fool trip. Any word -- any reminder to yourself -- can be used in anchoring.

All those joke-files of Smiley's dumb activities are rather fast-travelling, fast-loading docs, each essentially one screen. But you can use these time tricks to create longer, more normal, faster-travelling files that minimize the wearying user waits, don't overrun their limited InterNet hours, and allow students or teachers to do some significant surfing of your web project during the limited availability -- 30 minutes to an hour -- of most school computer lab schedules.

That's especially important if you're preparing a page by and for little kids; they have short attention spans and do not tolerate long waits where nothing seems to be happening onscreen.

To see more of the EZ How2's for each Smiley Fool Research Project page, go to this Tips and Tricks page.