14-Step Diet Plan for Web Pages

Are you growing a beard waiting for your Web pages to load? Getting impatient? Well, chances are you're not alone. Visiting a Web site for the first time is like getting a first impression on a date—if visitors are greeted by a slow-loading page on their first visit to your site, it's likely that that will be their last. To minimize this risk, enroll in the following 14-Step Diet Plan designed specifically for Web pages. As with any diet plan, this has to be followed through with much conviction and consistency in order to be successful. ("Diet" is used loosely in this context and refers to trimming a page's total download size as well as decreasing its rendering time.)

Step 1: Remove Unnecessary Code Build-up

Keep your HTML code as simple as possible; this means removing all unnecessary tags, redundant tag attributes, and extra spaces. If you use a wysiwyg HTML editor—especially an unregistered version—to create your Web pages, chances are it will add various comments or meta tags to your code to let people who peek at your source code know that you had used that particular application to create your pages (think of it as discreet advertisement). Needless to say, you can safely remove this fluff. If you thoroughly tweak your HTML file, you'd be surprise at how much code you can leave out without changing the look of your Web page.

Step 2: Eliminate Hard Carriage Returns

Forget the nice indents and double spaces that give your HTML code good structure—that's preppy. Eliminating all carriage returns may seem trivial at first, but it can snip off a few precious k's from a very large HTML file with lots of slack space. If there are structured routines (e.g., JavaScript) in your HTML code, leave them as they are because turning them into one long string can render them useless. You should also keep a nicely formatted copy for easy edits unless you like working in a mess of tight code.

Step 3: Avoid Large Background Images

Generally, avoid using any background images unless they are crucial to the theme of your Web site. If you're going to use one, make it small—loading a 640 x 480 image through a modem pipe will often drive a person's patience, and the average WWW surfer will probably get turned off if your Web page were to take, say, longer than two blinks of an eye to load.

Step 4: Stay Away from Beefy Animated GIF's

Animated GIF's are splashy at best, downright annoying at worst. Everything in between leans toward gaudy. If you look around the Internet, you'll notice that the majority of professionally designed Web sites with mega traffic have no animated GIF's at all (unless it's an animated GIF repository). Of course there are exceptions, but in most cases animated GIF's are for amateurs.

Step 5: Say Goodbye to Large Image Maps

This is something that can't be emphasized enough, for even large corporate Web sites exploit image maps. Using image maps for compact navigation bars is okay, and may even save you some bytes if your current navigation bar uses complex tables with dozens of images, but an image map that takes up the whole screen can take forever to load. A better alternative is to mix text links with spot graphics (a home page that serves up one monster image map and offers no text links is more insulting than welcoming).

Step 6: Cut Back on Images Containing High Amounts of Bits

Many people fail this step. A Web page may look all jazzy with 256-color GIF's and high quality JPEG's, but what's the use of a nice-looking page if no one visits it? It's a tough choice to make, but people visit Web sites for the content and not for bandwidth-consuming eye candy. Stick to 1-bit (2 colors) and 4-bit (16 colors) GIF's unless the images are part of a gallery and quality is everything. If you're using JPEG's, try saving them at a higher compression ratio, and use the "progressive" encoding option if your graphics app supports it. For dimensionally large GIF's, practice the strategies in Step 8. Finally, as a last step remember to always compress all your images using an image optimization program or online service (I highly recommend gifwizard.com).

Step 7: Crop Images to Barest Essentials

You're halfway through the plan! Never leave empty pixels between an image's content (i.e., the picture that makes up the image) and the image border. Imagine an image that measures 200 x 200 pixels, but the picture inside the image is only 150 x 150 pixels—shaving 50 pixels off each side of the image will reduce its file size considerably. This results in a faster-loading page for the visitor, and more visitors for you. An ASCII picture is worth more than a thousand ASCII characters:

Image before dietImage after diet
+————————————————————+
|                    |
|        _           |
|      _(_)_         |
|     (_)@(_)        |
|       (_)\         |
|          |         |
|         \|/        |
|       \\\|//       |
|     ^^^^^^^^^^     |
|                    |
+————————————————————+
___________
¦ _(_)_    ¦
¦(_)@(_)   ¦
¦  (_)\    ¦
¦     |    ¦
¦    \|/   ¦
¦  \\\|//  ¦
¦^^^^^^^^^^¦
¯¯¯¯¯¯¯¯¯¯¯

After you've cropped your images, be sure to define width and height values for all of them. Without these attributes the browser works harder to calculate the dimensions and positioning of each image. Machines have been doing all the work for us for too long now; it's time we give them a hand.

Step 8: Break Down Large Images into Smaller Chunks

We all know that large images are also larger in file size than smaller ones. You can dramatically decrease the size of some GIF images by slicing them up into smaller pieces based on either pattern or color, or both.

By pattern:

  1. Look for a pattern in the image or large background areas of the same color.
  2. If you see a pattern, cut out the repeating section and save the smallest iteration of the pattern as a new image.
  3. Crop the main image and save it (see Step 7).
  4. Use your jigsaw puzzle skills and the table tags to piece together the main image and the extracted image, which you can lay out repeatedly like a brick, to reconstruct the original image. If the image has a lot of empty background space, then slice it up in a way that will slough off this pixel fat (a good example of this trick can be seen on the Stanford Linguistics home page).
Now instead of having one large image, you'll have a small image and an even smaller image to fill in the redundant parts. Using the ASCII picture from Step 7, let's squeeze out even more fat from this image:
Original image......broken into smaller chunks
___________
¦ _(_)_    ¦
¦(_)@(_)   ¦
¦  (_)\    ¦
¦     |    ¦
¦    \|/   ¦
¦  \\\|//  ¦
¦^^^^^^^^^^¦
¯¯¯¯¯¯¯¯¯¯¯
___________
¦ _(_)_    ¦
¦(_)@(_)   ¦
¦  (_)\    ¦
¦     |    ¦
¦    \|/   ¦
¦  \\\|//  ¦
¯¯¯¯¯¯¯¯¯¯¯
__
¦^¦
¯¯

If a GIF image has too many colors and you cannot compress it to an acceptable file size without an unacceptable loss in image quality, then try breaking down the image using the technique below.

By color:

  1. Find a region in the image where like colors are clustered together; as a rule of thumb, the region should not have more than five or six unique colors, discounting gradients. Keep in mind that breaking an image down into too many parts can actually increase the total page download time because a network connection to the server has to be established for each image. You have to find that perfect sweet spot, a compromise that can only come with practice.
  2. Cut out that region and run it through a compression program to reduce the number of colors to a minimum without a significant degradation in image quality.
  3. Repeat for each color cluster, again keeping in mind that slicing an image into two dozen pieces will probably not decrease your page's download time even if the accumulative file size for all of the images is smaller than that of the original.
  4. Use your jigsaw puzzle skills and the table tags to piece together the different regions.

Continuing with the ASCII picture, here is what an image broken down by color might look like (you can combine both strategies by further breaking the brown base image down into its most primitive form, as depicted above):

Original image......broken into smaller chunks
___________
¦ _(_)_    ¦
¦(_)@(_)   ¦
¦  (_)\    ¦
¦     |    ¦
¦    \|/   ¦
¦  \\\|//  ¦
¦^^^^^^^^^^¦
¯¯¯¯¯¯¯¯¯¯¯
________
¦ _(_)_ ¦
¦(_)@(_)¦
¦  (_)  ¦
¯¯¯¯¯¯¯¯
___________
¦^^^^^^^^^^¦
¯¯¯¯¯¯¯¯¯¯¯
______
¦   \  ¦
¦   |  ¦
¦  \|/ ¦
¦\\\|//¦
¯¯¯¯¯¯¯

Compare the optimized images contained in this directory with master-shadow-opt.gif to see a real-life example (and a real 20% fat reduction).

Step 9: Don't Add Transparencies

If your Web page has a solid background color, don't save any transparency information with your GIF images unless your site uses a ton of them and you plan to change the background color every other week or so. A transparency layer allows the image's background color (or any designated color) to be "transparent," making everything on the Web page beneath it show through. This step will save you up to 100 bytes for each image. A mouthful of bytes may seem like a pittance, but it adds up quickly, especially if your site is very "graphical." Besides, why use the extra transparency when you don't need to?

Step 10: Don't Add Interlaces

This step is especially crucial for background GIF images. Loading interlaced images puts a little more strain on the CPU than loading non-interlaced images. This is because an interlaced image is rendered in two processes: the browser goes through once and draws every other line of the image, then makes a second pass to draw in the remaining lines, making the image appear as if it were slowly beaming onto the page from the U.S.S. Enterprise. Interlaced GIF's are generally several kilobytes larger than non-interlaced GIF's.

Step 11: Avoid Stuffing Everything into Tables

Tables don't show up on the screen until all the data in all of the cells are loaded, so if you write a novel and put every plot development in its own table cell, you might not see your opus on the screen again for quite some time. Solution: break large tables into smaller ones, and put each one on a separate page. How large is "large"? Well, that depends on a person's patience . . . how long can you wait for someone else's Web page contents to appear on the screen? Also avoid using nested tables if possible (i.e., tables within tables). If your site must use tables, then be sure to specify the width of all the cells in the table; without the width values, the browser reverts to a complicated algorithm to determine how best to render the table.

Step 12: Be Cautious of Frame Overdose

Frames are nice for navigation, but having six frame panels on a screen is out of control! A Web page using too many frames is not only crowded and confusing, but it also takes longer to load because the contents in each frame have to be loaded and adjusted individually. If you're going to use frames, limit yourself to two frame panels (a frameset done right can actually reduce your site's overall load—see Step 14). As with tables, avoid embedding frames within other frames.

Step 13: Moderate Intake of JavaScript

Ask yourself this before you flood your Web pages with JavaScript scripts: "Are they absolutely critical to the functionality of my Web site?" If you can substitute a script function with equivalent HTML or SSI code without crippling your Web site, then that function is just excess baggage. For instance, a page with JavaScript rollovers (e.g., buttons that glow when you move your mouse cursor over them) has to load twice the number of images as a page with static images. JavaScript rollovers are charming compared to the background fader script. This script is so ruthless that it won't even let the frustrated visitor leave the site until the background has cycled through all the programmed colors. Well, you get the idea—use JavaScripts sparingly. (Note: this step also applies to other types of scripts, plug-ins and applets. KISS.)

Step 14: Stay Modular

Okay, last step. Chances are your Web site has a lot of redundancy, either in the HTML code or in the graphics elements that are used. If you have access to SSI or a server-side markup language such as PHP, then try to make as much of your code modular as possible. For instance, if every page on your site contains the same header, navigation bar, and footer and copyright notice, then put their code in reusable include files; this has the positive side-effect of letting you make site-wide changes by editing just one file. If you don't have access to any server-side facilities, then still try to make as much of your code modular as possible. It's harder to do now, but far from impossible. Pick and choose from the following menu to see how it can make your site lean and modular without any server-side assistance:

You have just seen some of the more common ways of reducing your code by sharing code and files. There are other ways to achieve this end—all it takes is a little imagination and some clever (unorthodox?) hacking. As you gain experience through trial-and-error and compulsive code tinkering, you'll soon develop your own bag of tricks. Your Web site visitors will thank you for it.

Congratulations on completing the program! I hope that your Web pages are now in nimble form and quicker to load, forcing fewer packets down your visitors' socket. Feel free to re-enroll if they start to put on weight again. The 14-Step Diet Plan may be revised without any notice.



Original plan by Tom Doan. These steps are an accumulation of years of personal experience and trial-and-error. Please email me if you have something to add, or if you have a success story—I'd love to hear how many kilos your site has lost :).