The Age of Information | The ePublishing Enigma | Web Tolerance
Market Your Web Site 101 | Smart Tags or Dummy Tags | ASP vs PHP
|
Optimizing Images
for the Web Part I
|
Optimization - Who needs it?
After text and hyper-links, images are the most frequently displayed Web entity.
Images used on the Web are often combined with text and hyperlinks and can
range from low-resolution static images to high-resolution interactive images
complete with image maps. Everyone from the new mom making a Web page about
her new-born-child to the professional Web Designer/Developer creating an
interactive entertainment site for a highbrow client can use images to spice
up their Web pages.
Why Optimize?
Optimization is a reoccurring phrase in the Web vernacular. Image optimization
is simply creating and using images for the Web that are designed with the
Net in mind. This means you consider the way the images will perform on the
Net. Performance on the Web usually means how long it takes to load a page.
This is a necessary consideration because Web development is out pacing the
technology that makes the Web accessible. In other words, our preoccupation
with designing various types of Web content (images, text, objects, exc.)
leads to advancements in Web authoring that are always technologically ahead
of the Internet itself. This creates and maintains a need to design content
for the Web that will survive and even thrive under the deficiencies of the
Internet.
Don't be fooled by your PC
Unfortunately image file sizes can be quite large. These often-obese files
may have a difficult time jogging around on the Net's transfer-rate tracks.
They may do well internally on a given computer system but this is like exercising
on a stationary bike. There are luxuries an image may enjoy at a spa workout
on your PC that are not available while that image is being worked out over
the Web's jungle like environment. Applications accessing an image on your
hard-drive have the benefit of vast amounts of RAM memory, swift bus speeds
and high-speed processors (on most up-to-date systems). However when your
system has to access that same image over the Web, it's like making that chunky
file get off of the stationary bike and run in the Iron Man Challenge. The
conditions are strenuous and the progress of a user's file download can be
hampered by many different variables, some of which are outside of the user's
control. Although your PC or Mac may be an expert at getting these hefty files
around on your system in-house, the Internet has yet to handle the challenge
as well.
Putting Image Size into Perspective
They say a picture is worth a thousand words. As a matter of fact, on a computer,
a picture in the form of a graphic is worth a whole lot more than 1,000 words.
Let's look at the numbers. As an example, let's say a particular image file
that takes up about one quarter of a browser screen is around 80K (approximately
80,000 characters). Now, let's say that the average word is five characters.
In addition we'll add a couple of spaces for good measure giving a total of
seven characters. If you take an image composed of 80,000 characters and divide
that by a word composed of 7 characters, you get approximately 11,400 words!
This means you could have a text file composed of 11,400 words that was the
same file size as 1 image that takes up one quarter of the monitor screen
(in theory). Of course this varies depending on the resolution and number
of colors the image is composed of, but the lesson is clear. In order for
images to share the same page with other images and text while still maintaining
decent download time, optimization is a must.
An 80K file, transmitted to a browser across a 28.8 KBPS connection, takes about 40 seconds. A good rule of thumb (until broadband becomes a standard) is to estimate that the average home user is getting about 2K (2,024 characters) per second transfer speeds from their Net connection. This problem gets worse when International connections are taken into consideration. Some countries have very poor connection speeds due to out-dated phone lines and inferior phone equipment.
Why use the "ALT" Tag
Many advanced Web users who don't have broadband access turn off their automatic
image load feature. They navigate to the desired information, and then request
image loads for specific pages. Many Web Designers/Developers use the ALT
option with images so that a browser operating in text mode will display a
text message concerning the image or a text substitute for the image. Without
the ALT option, a user might not comprehend the objective of your page. This
is especially true if the image has text in it that is part of a company logo
or if the image has important information that is not included elsewhere on
the page. Therefore a Web Designers/Developers work should always make sense
even when images are not available. The ALT option makes sure the user gets
your point or message even if the image did not make an appearance onto the
display. Note that the text used in ALT cannot include HTML markup. Tags like
STRONG, header tags, and so on, are unusable. The ALT option uses regular
text or special characters and no tags!
Image Formats:
It doesn’t take much experience with images on computers to run into
a GIF file. GIF is a popular format that constitutes a significant portion
of images used on the Web. But GIF is only one of a number of different graphics
standards. JPEG, PCX, TIFF, and others are also widely used image file types
(not all used on the Web). Is it possible to use any image format in an IMG
tag? The short answer is no. Among all the various formats, the browser itself
can handle only a handful. Basically there are three (possibly four) that
are used in an IMG tag, GIF, JPEG, and XBM (check for PNG support). Other
formats can still be displayed on the Web, but not by using the IMG tag and
they usually require a special plug-in or application helper. Each of the
three formats that can be displayed by an IMG tag has different characteristics.
Examining these might make deciding which standard to use easier.
XBM
XBM is an X Window bitmap, and only supports two colors. Most PC and Mac browsers
can display these, but if you don't have UNIX, you might have a problem finding
the utilities that create them. GIF and JPEG, on the other hand, are standard
formats for both the PC and the Mac.
GIF
GIF (Graphics Interchange Format) supports a maximum of 256 colors and is
generally preferred when you want crisp lines (such as when text appears in
the image, as in some icons), or have images with large blocks of single colors.
JPEG
JPEG (Joint Photographic Experts Group) supports up to 16.7million colors
and is very good at compressing photographic and photo-realistic images. You
can control the amount of compression, trading size for quality.
Below you will find a summary of the image formats discussed above plus some others not mentioned. Tips and tricks concerning the optimization of these images will be discussed in part 4 of this series.
GIF
CompuServe's Graphics Interchange Format. 256 colors, has special capabilities
such as transparency and interlacing. Uses LZW compression. Widely available.
JPG, JPEG
Joint Photographic Experts Group. 16 million colors. Very efficient compression
for photographic images. User controllable trade-off in image quality versus
file size.
PNG
A format that supports more colors than JPEG, compresses files 10 to 30 percent
smaller than GIF, has multiple levels of transparency, and uses a faster interlacing
technique for displaying images more quickly. (Check for browser support)
XBM
Bitmap image for X Window. 2 colors.
BMP
Windows bitmap. Native to Windows 3.x and 9.x OS's. 16 million colors. RLE
compression. Generally larger than other compressed image formats.
PICT
Macintosh Picture formats. A native format on the Mac, analogous to BMP on
Windows. Supports 16 million colors, is based on QuickDraw display language.
TIFF
Tag Image File Format. A popular cross-platform image format for migrating
between Mac and PC. 16 million colors. There are several flavors of TIFF,
which sometimes leads to compatibility problems across platforms if options
are not carefully matched.
PCX
PC Paintbrush formats. 16 million colors.
TGA
TrueVision's Targa Format. 16 million colors. Used in ray-tracing applications
on PC and UNIX platforms (like POV).
Taking Control of your Images
If Web performance (time it takes a page to load) is to be improved, two primary
factors are to be considered, #1) the speed of the Net connection and #2)
the amount of data that needs to be transferred. There may be a vast number
of communications vehicles in-between the server that houses a page and the
browser that reads it. The slowest vehicle is usually the home connection,
which is typically achieved using a low-speed connection via analog modem
and standard telephone lines. A page that might take a few seconds to load
from work (on a high-speed workstation using a broadband connection) might
take five minutes on a bandwidth challenged home system using a standard telephone
modem. Therefore when a Web author is optimizing images for the Web he/she
must take into account not only the type of browser (surfboard) the user is
surfing with but also the type of connection (wave) the surfer is riding on.
The 30 Second Rule
Millions of people using the major Online Services (AOL, Prodigy, exc.) and
Internet Service Providers (ATT, Bell, exc.) are dialing in at speeds ranging
from 9,600bps to 56,000bps (bits per second). It was once believed by Web
authors that 30 seconds of load time for a Web page was a good rule of thumb,
however this needs to be explained further. This does not mean it should take
30 seconds for something to appear on the display, this means 30 seconds to
download the entire page (all content). The user should see text before the
page has completely loaded. All relevant text should appear on the display
before the first 10 seconds have expired and all small images (5k and under)
should be displayed before the 20 second mark. The Web is the domain of the
attention deficit populous of the right-here and right-now. After 30 seconds,
all bets are usually off as to gaining and keeping their attention. If the
user did not get what they were looking for or at least a pleasant surprise
that was unexpected, they're gone. However the 30-second rule does not take
into account Net congestion or overloaded servers.
The Two Screen Rule
Web authors have another rule of thumb that suggest that you should not put
more than two screens worth of information on one HTML page (the amount of
information that two screens constitutes will vary with font size, monitor
size and screen resolution). HTML markup and text should load in much less
than 30 seconds, but inline images on your page may take longer. Tuning these
images can significantly impact the transfer speed of your page.
The size of an inline image determines how quickly it can be loaded and is a key factor in optimizing images for the Web. You can manipulate four characteristics of an image to improve your page performance:
Dimensions
Number of colors
Type of compression
Reusability
Dimensions
The dimensions of an image describe the size of an image in pixels. One way
to speed up performance is to specify these dimensions in the markup. Doing
this allows the browser to block-out a space for the image first, then begin
displaying text instead of waiting for the image to load. Because the browser
knows what part of the screen the image will occupy, it does not need to load
the image right away; it can load text first and then load images. The overall
transfer time is not significantly different (the browser still has to transfer
the same amount of information overall), it just appears faster. The user
does not have to wait to start viewing text content and the frames for the
images pop up in the document right away. In HTML 3.2 and up the IMG tag has
options for WIDTH and HEIGHT that correspond to the pixel size of the image.
These options allow you to define the size so that the browser can block-out
the area for images and start displaying text.
For example, a quarter-screen image (1/4th of 640 x 480) would be 320 x 240 pixels, your HTML image tag would look something like this:
IMG WIDTH=320 HEIGHT=240 SRC="my_image.gif"
Number of Colors
GIF images can contain 256 colors; JPEG images can contain as many as 16 million
colors. Most browsers compatible with Windows display about 50 colors. Windows
9.x OS's generally use 16 colors from their 256-color palette (for SuperVGA
systems), the rest are used by the browser for it's menus, buttons, and so
on, leaving about 50 entries in the palette free. Windows uses some very complex
color palette combinations that are beyond the scope of this article. However
you need only know that your inline images on a Web page will not be displayed
in 256 colors and definitely not in True Color (this may be different under
Windows 2000 and future Windows offerings). Until browsers support 16 million
colors (when the Net supports the transfer of a file with 16 million placeholders
for color values that takes less than two weeks to download) you will want
to analyze your image to see how many colors are really need. Before an image
has been optimized for the Web it may have color values that will not be used
by the browser. Getting rid of these values means smaller file sizes. The
optimized image will (in most cases) still look as good as its predecessor.
You may be wondering how so many different colors can be displayed in your browser with such a limited option of colors for your browser to access. Take into consideration that color combinations are used to create colors that are not available in the palette (or something close). A good example would be an InkJet printer, most only use 3 different colors of ink (cyan, magenta, yellow) (some new models use 4 colors) to produce all of the different colors we see on our colored printouts.
If you want to see "Number of Colors" optimization techniques in practical application you should try the following:
Use your favorite search engine to find and download "LVIEW". Open a GIF image using LVIEW. Select "Retouch, Color Depth". Click the "Palette image button" and the "Custom Number of Colors button" and set the number of colors to 50. After you enter 50 in "Custom Number of Colors" click "OK". LVIEW calculates what mix of 50 colors will best represent your image. Compare the two files (before and after) and see if there is a noticeable difference. Try using different "Custom Number of Colors" settings to get the best match of colors and image quality with the smallest file size. You'll notice that saving the file results in a new file size that is dramatically lower than the previous. Since 1K equals about one second of transfer time, you could shave several seconds off of your image file download time.
Type of Compression
Most browsers support both GIF and JPEG as inline images however there are
variables to consider when using either.
JPEG is better at storing full-color photographic or gray-scale images, especially if you want your scenes to have realism and image depth.
GIF is best used for black-and-white images or images with only a few, distinct colors (as opposed to color blends). It works well with line drawings, and graphics that contain text.
If you are scanning pictures to use as images on the Web, you should consider the compression style used by either format. GIF gets rid of a lot of color information when it compresses. Compression ratios will range from 2:1 to 5:1.
JPEG achieves 10:1 to 20:1 compression ratios easily on full-color images, and can go as low as 100:1 in some cases.
When JPEG was first introduced, converting an image in GIF to JPEG could produce some very strange results. However up-to-date graphic conversion utilities can usually handle the conversion with ease producing eye-pleasing results. As a matter of fact, many of these utilities give tremendous customization control over the quality of the conversion. Nevertheless, you should decide which format you need when you originally create the digitized image and stick to it. However this is not always possible, especially if you're not the one creating the images. If you're just implementing the images into the Web page and not creating them, you may have to work with an image file format that is undesirable. It may be necessary to convert the image into a more manageable and user-friendly (not to mention compatible) format.
Reusability
No, this is not a new type of recycling project started by the neighborhood
tree-huggers. I am referring to the ability to re-use images, graphical menus
and other Web page elements. The performance of your pages can be significantly
improved by re-using page elements, especially images. You should use the
same navigational bar or buttons on all your pages, which helps the user by
making them only download these images once. As browsers go from page to page
on the Web, they keep images they've already downloaded cached (stored on
the local disk or in memory). This prevents the browser from having to retrieve
the images again from the server; the image can be retrieved from cache, which
is much faster for a browser to access than the server is. This provides a
graphical template for moving around your documents while actually downloading
only the new HTML markup and text.
This technique not only works with navigational bars and buttons, but with graphical bullets and rules as well. You should avoid decorating your lists with bullets of all colors of the rainbow. Each bullet will need to be retrieved separately, multiplying the time it takes to render your page. If you use a single bullet image, the bullet will be downloaded once and re-used for each list item. This will be achieved in a much faster load time than downloading a different bullet for each menu item. It should be duly noted that using the same image also means the same image name. Often times when someone uses a WYSIWYG editor (what you see is what you get) to create Web pages the code generated by these editors will give strange names to page elements such as images. One such application that will remain nameless (MS Publisher, cough, cough) will assign numbers to images that have been cut and pasted, copied, or inserted onto a page (example: image1.gif). These types of applications will use this method of keeping up with images even if you paste or insert the exact same image multiple times during the creation of the Web document. You may end up with a bullet that is used throughout the site 47 times with 47 different names (example: image1.gif, image2.gif, etc.).
If this sloppy design architecture is not cleaned up before the pages are loaded on the server you will end up with multiple copies of the same image under different file names. This will cause a users browser to download multiple copies of the same image which will totally negate your attempts at reusability. Therefore if you're using a WYSIWYG editor be sure you view all of your source code and edit it as necessary. Hand coding is a valuable skill and should be learned and practice fervently, (however, that's another topic).
|
Polish it off with a fresh hot SLICE of IMAGE pie, mmm…tasty! |
Image Slicing, What is it?
Image slicing is pretty-much what it sounds like, taking a single image and
"slicing" it into smaller pieces. The intended purpose of the slicing
is to provide Web designers/developers with a tool that allows them to better
optimize their images for Net data transfer as well as enhance artistic design
options. By using image design and editing utilities along with HTML tables
you can seamlessly create larger graphics from smaller ones right in front
of the clients eyes as they watch the page load.
Do Sliced Images Really Load Faster
Although the overall idea is to yield faster image or page download times,
in reality the download advantage is usually just the clients perception of
the download time. If the overall image is of a certain file size and is sliced
into 4 smaller pieces that are each 1/4th of the total image file size, the
total data transfer to display the entire image is still the same. In other
words, 100k is the same data transfer as 25k x 4, (4) being four separate
slices of 25k each.
So, What's the Benefit
The benefit comes from the client's perception, If the end-user views your
Web site and they see the whole image start to download after 5 seconds, then
it took 5 seconds to start the download. Perhaps it was a complete 10 seconds
before the image finished downloading, but it was the 5 seconds of "nothing"
on the monitor screen that they will remember. However if they saw one section
of a sliced image start downloading after 1 second, that's the speed advantage
that they will notice despite the fact that it still takes a complete 10 seconds
to finish the image download.
Because a small slice of an image is composed of less data than the one whole image, it will be contained in fewer packets (possibly one packet, but this varies with file sizes, browser settings and transfer rates). This means that in theory the actual displaying of graphic slices will begin faster regardless of how long it takes to finish the entire image assembly.
The Role of Tables
Tables have been traditionally used to hold text strings and values. As the
Web became more graphically saturated, it was not uncommon to find designers/developers
using tables to hold images. However slicing involves using individual pieces
of an image and assigning them to cells within a table (like a puzzle). Each
cell within the table holds a piece of the image puzzle, with the cell padding
adjusted to "none" to create a seamless restructuring of the image.
Image slicing can also provide designers and developers with a vehicle for pulling off some pretty impressive tricks. Architectural design enhancements such as wraparound effects that combine text and images, images designed to work with cell padding to produce optical illusions and other eye candy have been implemented using tables and slices. As a matter of fact, the downright abuse of image slicing has become an issue. In some extreme cases this abuse can actually negate the benefits of slicing images. Some overzealous designers/developers overload their pages with sliced images or create too many slices of a given image. Beware, there are many instances when slicing an image actually increases the time of download.
How Browsers Deal with Images
Browsers download information in packets on data streams, the size of these
packets and the number of streams your browser will maintain at one time is
another topic but by default most browsers can maintain 4 simultaneous downloads
at once (these settings can be altered). This helps the client start viewing
smaller downloads without waiting for larger downloads to finish which gives
the appearance of faster downloads. However it can also be argued that this
splits the bandwidth but that too is another topic.
This whole process begins by the browser pinging the server to see if it's there, the server will respond with a ping and a connection can thereby be established. Next, data begins to be transferred in packets. If the browser is downloading an image with a file size of 10K, that 10k is downloaded on one stream. However if the image is sliced into 5 separate 2K slices, in theory 4 of the 5 slices can download simultaneously on 4 separate streams. However you should remember that images should have height and width attributes so that the browser can delineate a space for them and then start downloading text. Fortunately, the table accomplishes this for you. The table defines the region of the images and the image tags define the size of the image.
Nevertheless, too many image slices can create a situation where the browser is making too many requests to the server for data and waiting for replies. This could cause the page to hang-up while loading or significantly increase overall download time. Therefore image slicing should be done sparingly and efficiently.
In Summary...
Although this does not cover every type of performance enhancing ritual used
to gain an edge in optimizing your images for the Web, it does provide the
initiate with a general idea of the problems with Image use on the Web and
some solutions. As the Web grows and technology gains in strides, the Web
will become more dynamic and connection speeds will accommodate the dynamics.
Perhaps we will even see a day when the file size of an image is not even
a factor worth discussing in terms of computers and the Net. Until then the
Web author should be a student of the University of "Ergonomics"
and a neophyte in the fraternity/sorority of "Optimized for the Web".