Top Ten Web Tips
Nota Bene: I do not pretend that the tips I recommend must
be followed to the letter, or that I'm absolutely right. However,
if you follow these tips, you should manage to avoid the worst of
the most common mistakes.
That's it. Doesn't leave you with much, does it? Well, it does
make you work harder to present real content, because it will be
harder to hide it behind flash and trash if you follow these
- Image Tags
- All your images should have ALT,
HEIGHT, and WIDTH tags on the
IMG SRC HTML command.
The ALT tag helps make the page more friendly
to text-only browsers and people who've turned off
auto-loading of images, and the HEIGHT, and
WIDTH tags help your web pages load faster,
since the browser will know exactly how large the
graphics will be and therefore also know exactly where
all the elements will fit together, before
pulling down a single image.
- Web Page Size:
- Your web page (measured in KB) should be as small as
you can reasonably make it. Your target should be no
larger than 20KB, and absolutely no larger than
40KB. Yes, this includes all the graphics.
This statement is based on recommendations I've read
from various books, as well as personal experience.
Note that the main Yahoo! page is about
17KB in size, and should load in something like twelve
seconds across a 28.8Kbps modem, and the main DejaNews web page
is about 8KB in size and should load in something around
six seconds. These two sites are typically used as
the yardstick by which all other good web sites are
If you've got something that is a diagram or drawing, then
a GIF is probably the right type of graphic file format to
use. If it's a picture of a person, place, or thing, try a
JPEG instead, since they're optimized for that sort of
- Color Reduction:
To help you on your quest to keep your web pages small,
you should reduce the size of your GIFs as much as
possible by reducing their bit depth (which also reduces
the number of colors available).
Virtually all GIFs used as menu bars, etc... can be
reduced to 5 bits (32 colors plus dithering) without
any noticable effects. This would be a 37.5% reduction in
the size of the graphics, all else being equal.
Virtually all other GIFs can at least be reduced to 6
bits (64 colors) without noticable effects. This is
typically a 25% reduction in size.
If you have to leave your GIFs at the full 8-bit color,
you should make sure that they use only the 216 "net safe"
colors. Otherwise, the colors you see on your screen may
be wildly different from what your viewers see.
Tools to help you in the quest for optimized GIFs include:
If you've got a picture of a person, place, or thing,
it can typically be represented as a JPEG in much less
disk space than a GIF. That's because GIFs use a
lossless compression algorithm, while JPEGs use a lossy
compression algorithm that is closely attuned to the
way the human eye sees detail in pictures.
- Size Reduction:
With GIFs, you reduce the number of bits used to represent
each pixel. With JPEGs, you simply increase the
compression level. A default compression level of 50% is
typical, but many JPEGs (especially those on the web) can
be safely reduced to 30% or even lower without too much
impact on the quality of the graphic.
- Color Reduction:
With JPEGs, you can not only increase the amount of
compression (reducing the level of detail that is
kept), but you can also reduce the color depth of the
JPEG as well.
By default, JPEGs are 24-bit "true color" (16M
colors), but virtually all JPEGs can be safely
color-reduced to 16-bit (64K colors), with little
or no loss in visible quality (relatively few people
have monitors capable of displaying 24-bit color,
and even those that do probably won't notice the
Reducing from 24-bit to 16-bit color will almost
certainly reduce the size of the image by one-third,
but it may be considerably more, as you take fuller
advantage of the JPEG lossy compression algorithm.
JPEGs may be able to be further color-reduced,
depending on the original image. You'll just have
to try it out and see.
See above for tools.
If the content that you're delivering is graphics
(imagine an online picture album), then you should use
thumbnail graphics and represent large graphics with
an array of smaller ones linked to them. When the user
wants to see a full-scale picture, they click on the
small thumbnail image to pull up the larger version.
Thumbnails are typically done as GIFs of JPEG images,
reduced from whatever the normal scale is to something
like thirty-two or sixty-four pixels in the largest
dimension (e.g., the full-scale image might be 640x480,
but the thumbnail that links to it would be 64x48 or
You should use frames sparingly, if at all. Yes, with frames
you can do all sorts of nifty tricks to try and guarantee
exact placement of certain elements on the page, but that's
just trickery. And, sooner or later, you're going to run
across a situation where some browser blows up.
Besides, many users still haven't upgraded from versions of
browsers that don't understand frames at all, or if they do,
they do so poorly.
You should use these sparingly, too.
The problem here is that many users are sitting behind
firewalls that will strip out any and all Java and/or
single browser yet that implemented them well. Every one
I've seen so far has major meory leaks and other problems
that mean that, sooner or later, you'll probably crash
their browser, if not their machine.
Besides, it's a source for potential security holes.
Use these sparingly, also.
Users don't like having private information about them being
handed out to machines/people they don't know. Many users
have installed software to permanently remove any and all
cookies that get put on their machines, or have configured
their browsers so that they will never accept cookies.
Avoid like the plague.
this is the world's largest security hole that
could possibly be built in (and it's intentional, too).
Also frequently stripped out at firewalls.
- Multimedia (animations, RealAudio, MIDI sound, etc...):
Generally speaking, you want to avoid these, too.
If the content you're providing is multimedia, then go
ahead and present it (while working to make it difficult
to send the user something they might not be sure they
want, which would just cause them frustration as they seach
for the "Stop" button in a panic).
But don't use multimedia as an attempt to dress up or hide
the ugly warts on an otherwise drab web page. It may work
once, but it probably won't work a second time, and soon
your viewers will tire of it and go somewhere else that
has some real content.
- Browser Discrimination:
Try testing our your web pages in as many different browsers
as possible. In particular, try testing them out with Lynx or
with your regular browser but with images turned off. See if
you can navigate your pages without any graphics, and if the
content presented to the user is seriously handicapped in any
However, you should also try it out with the AOL web
browser, while dialed-in across a 14.4KB modem, between
6:00 PM and 11:00 PM Eastern time. Like it or not, this
is still the picture that the largest group of users will
ever see of your site, so you should make sure that it's
at least reasonably presentable to them under these extreme
- Browser Colors:
Generally speaking, you should leave the background,
foreground, link, etc... colors alone, or at the very least
leave changing them to professionals who really know what
However, it's ultimately the content that you're trying to
get across to people, not the trappings -- right? This is doubly
important when it comes to things like handling visually impaired
users that may be using a text-to-speech translator on their browser,
so that they can hear your content spoken to them.
It is possible to intentionally violate one or more of these
rules and still succeed in achieving good web page design, but
doing so requires good design sense, intelligence, and just plain
common sense (which we all know isn't). The combination of these
three is virtually impossible to find.
If you're designing a commercial web page, you might also be
interested in looking at How
to Avoid 10 Fatal Website Mistakes, by Hannah Kate Kinnersley
on the TechWeb site. I may disagree with some of their specific
hard recommendations regarding web page size, but their other
suggestions appear to be very good.
If you have any comments, please email me at