Not the big picture
I suspect this won’t be the last time I talk about the points I raise here, but they need repeating. And repeating. And repeating. The size of your page matters, and the reason it matters is that it determines the time it takes a user to download it. There are plenty of slow-loading pages out there with all the appearance of having been designed by someone with a T1 connection who is blissfully unaware that most users have a 56k modem connection — or an even slower one. Bloated pages take forever to load over a modem connection — and guess what? A lot of users won’t stick around to see your spiffy site if it takes minutes to appear. Size matters.
The principal determinant of size is usually graphics. If the size of your page totals around 60k, you are approaching a load time of 20s if you are talking about a 56k modem. It’s closer to 30s with a 28.8k modem; that’s a long time to wait for a page to load.
If you take a look at what Jakob
Nielsen says about usability, you will find he says 3kb is the upper limit
for a web page because that is the biggest pages can be if they are to download in one second which is the required response time for hypertext navigation
using a 28.8k modem. For that reason, his site uses no (or almost no) graphics.
This seems to me to be ejecting the baby with the bathwater. The only time I have ever seen a page load in a second is when it is on my hard drive — and even then it sometimes takes longer. Many other factors come into play apart from the size of the page and the speed of your Internet connection; sometimes even a short page of plain text will take six or seven seconds to load. It is also worth remembering that the Internet has been around for something like 30 years, and for most of that time pretty much no one “ordinary” — i.e., outside of IT and academia — ever heard of it. What has made it staggeringly popular is the Web — graphics, in other words.
Not using graphics isn’t the answer. What you must do is use graphics sensibly. In practical terms, you don’t want your page taking any longer than about ten seconds to load; if it takes longer than that, you are heading into the “Sod this, I’m going somewhere else” zone. So you need to keep the size of your graphics files as small as you can manage without noticeably sacrificing quality. Additionally, don’t unecessarily duplicate graphics — if you are using a number of very similar images, why not use the same image? Remember, cached images load much more quickly.
Which file format?
The first thing to consider is what type of graphics format to use. To decide that, you must think about the nature of your graphic. Is it a photograph, or an image with subtle gradations between colours? In that case, you probably need to use the JPEG format, which is good for that type of image and supports image compression.
The JPEG compression is a lossy compression: that is, information is lost. The higher the compression, the poorer the quality, obviously — but you can lose a great of quality from a JPEG before any major difference is noticeable to the human eye. Go for the greatest compression you can before loss of picture quality becomes obvious. Monochrome photos, by the way, tend to compress less well than colour ones.
On the other hand, the image may be a line drawing or a graphic consisting of large blocks of solid colour. The JPEG format is not very good at handling these, and the compression does not produce terribly good results. For graphics like these — such as the logo at the top of the page — you get better results using the GIF format. An added advantage with it is that you can specify a colour as transparent, although that does have its own pitfalls.
GIF doesn’t support compression in the same way as JPEG does, but an important way to influence the file size is to set the colour depth of the image. After all, if you only use two colours in an image, there is no point in setting the depth for 256 colours, is there? There are also utilities readily available which will optimise your GIFs, trimming them down to the minimum file size.
There is another file format with a lot of promise, PNG, but GIF and JPEG are basically the only graphics formats you should use at the moment because they are the only ones you can count on browsers supporting. Do not use BMP files because, in addition to the fact that not all browsers support the format, they are generally very, very big (by which I mean more than, and frequently a lot more than, a megabyte).
Dimensions
Assuming you have selected the appropriate file format for your image, the next thing to consider is how big it should be in terms of pixels on the screen. A 500×250 pixel image is going to be bigger in kilobyte terms than the same image resized to 300×150, irrespective of anything else you do to the image.
One thing which is striking about first-time web designers is that they always seem to want to use enormous graphics. It is important to remember that any image larger than the browser window is not being seen at its best. Scrolling down to read text is one thing, scrolling down — or to the right — to see more of a photograph is quite another. If you are including an image as some form of illustration, the absolute biggest you should normally consider for its height is about 500 pixels. That will still mean that people using screen resolutions of 640×480 will have to do a bit of scrolling, but it will fit other screen sizes.
However, you really should give a lot of thought as to whether you actually need such a large image. An image 500 pixels in height is going to be quite large, and add significantly to the loading time. You may find that you can just as effectively use your image if it is, say, 200 pixels high. If it is essential that your users can see the full-size image, put in a hyperlink so that they can click on either a small picture or a text link (or, better, both) to load the big one if they want to. If they are not interested in it, you haven’t wasted their time and irritated them by forcing them to wait while your graphic loads.
When you are incorporating your graphic in your page, always
specify the HEIGHT and WIDTH attributes of the
<IMG>
tag (or specify the dimensions in the style sheet). Yes, the graphic will still load all right if you don’t do this, but
the loading of the rest of the page will be delayed because the browser does
not know how much screen space the graphic is going to take up. Specifying the
dimensions in the <IMG> tag means that the browser can set aside the space needed for the graphic and can load the rest of the page before the graphic has finished loading. There is no guarantee that the browser will do this, but the most commonly used browsers do and this is an simple way to improve the user’s experience of your site.
Get the size of the graphic right
Now
the next point is particularly important, not least because so many people do
this: you should never, ever, attempt to alter the size of a graphic merely by using the <img> tag’s attributes.
Just in the past four days I’ve seen three examples of this. There are
two reasons why it is a bad thing, but only one really matters: you may take
(and this is a real example) a 1356×969 pixel, 152kb image and write the tag
as <IMG SRC="[URL]" WIDTH="606" HEIGHT="489">
and, yes, your browser will display it as a 606×489 picture, but the user
is still downloading a 1356×969, 152kb image. You’ve only made it look
smaller, nothing more than that. Use your graphics software to reduce the actual
size of the image and match the attributes of the <img> tag
to the actual dimensions of the image.
The second, relatively unimportant, reason not to use this technique is that having graphics resized by browsers can mess them up. That is not, after all, what browsers were designed to do, so they don’t necessarily make a very good job of it. Do it properly: use a graphics program.
As a little aside, I have noticed that every time I have found a web page which does this it has been authored using MS FrontPage. Now it is a while since I tried and loathed FrontPage, but I do wonder if something about the way its interface works leads neophytes to believe that adjusting the tag attributes actually changes the size of the file. After all, there are other authoring packages out there, to say nothing of the people who build web sites by bashing out HTML in a text editor. Yet whenever I see this being perpetrated, it is always a page built with FrontPage.
Don’t overload the page
The final major point I want to make is the question of how many graphics to have on a page. That is entirely up to you, of course, but remember that if you want to have your page load (all other things being equal) in 10s or less, you want to keep the page size below 50kb. It is also important to remember that the more graphics you have on a page, the less effective any of them are.
If only one or two graphics take the size to 45–50kb and you have another six, put them on another page. Just as you would not produce a book which had the entire contents on one long, long page, why should you put all your content on one web page?
Are you using several images which are similar? If so, why not use the same image: it will be cached and load much more quickly after it is first loaded.
It should be absolutely clear after everything I have said so far that you should not put enormous graphics or large numbers of graphics on your site’s home page: your visitors should get some warning before being faced with a huge page and have the opportunity to decide for themselves whether or not they want to look at it.
Background images
Everything I have said applies to background images, although there is perhaps a little more leeway, provided there is content there for the user to read while the image is loading. If you re-use the image on every page in your site, it will be cached and there will be little or no delay for it to be loaded again with each new page. You should still keep file size down as much as possible; picking the right file format is crucial.
For example, the background image used in the first version of this site was very large, 1600×1800 pixels, so that it didn’t start to repeat on large monitors. It was, though, only 20kb: it was a GIF file — good for blocks of solid colour, remember? The same graphic as a JPEG would have been anywhere between 48kb and 240kb; since the highest levels of compression produce artefacts, the smallest usable file size would have been in the 60–70kb range.
There are other factors to consider which are specific to background images — particularly the question of ensuring that text is readable, and the implications for readability if the text colour has been specified and the background image hasn’t loaded for some reason. But these are matters for another time.
Animations
I’m not really going to talk about animations at all just now, beyond two points: everything I have said about images still applies if you are including an animation — with knobs on; and you should always think very carefully whether or not your animation actually adds anything to your page. It rarely does.
Further reading:
- Alertbox: The Need For Speed
http://www.useit.com/alertbox/9703a.html - Response Times: The Three Important Limits
http://www.useit.com/papers/responsetime.html
© DC 2000, 2001. All rights reserved.
