Web-page mistakes

I don’t understand, sometimes, how people put together their web pages. Who really thinks that, say, pink text on a red background looks good? Seventeen different typefaces on one page? A background image that makes people’s eyes cross?

One can argue that those are all matters of taste, and, after all, à chacun, son goût. And anyway, those things are easy enough to fix: one can apply a custom style sheet right in the browser, and override all those size and color and font and background things that were specified in the web page. There are instructions and bookmarklets floating around on the web... just stick one in your browser’s bookmark bar, and then click it when you encounter a retch-inducing or simply unreadable web page.

But there are lots of web-page problems you can’t fix up in your browser, because it’s the people who put together their web pages who don’t understand, and it’s not just in matters of personal taste. Perhaps one of the most annoying of these is what I call the lazy thumbnail error.

You’ve encountered these, surely: you’ll be looking at a web site for a business or organization, and you’ll click on a page labelled The Christmas Party, or Our Staff... and the page will take forever to load. You can’t see why, though: the Our Staff page shows maybe 20 people, from the company president to the secretarial staff, each with a small photo, a name, and a short paragraph by way of a bio. No big deal here. The photos are all tiny, something on the order of 100 by 120 pixels, like my mug at the top of these pages. What’s the problem?

The problem is that the photos aren’t as small as they look, because the webmaster was lazy about creating thumbnails for the staff pics. She asked everyone to send her a snapshot, and she put them all up on the web page with HTML like this:

<img src="staffPics/jane.jpg" height=200 alt="Jane Smith">

There... that makes all the photos the same height, 200 pixels. If someone sent a larger one, it gets scaled down, nice and small. Makes for a uniform look, and the page looks great.

What the webmaster doesn’t understand is that the scaling is not done at the server, but in the user’s browser. When the browser loads the page, it sees all these IMG tags, and it requests each image URL (such as staffPics/jane.jpg, in the example above). But it has no way to tell the server that it’s only going to display it 200 pixels high, and the server has no way to know. If Jane sent a high-res portrait, eight megapixels huge, the whole thing gets sent to the browser. And then the browser has to do the scaling itself, when it renders the page.

If ten of the twenty staffies have sent large photos, that simple Our Staff page can wind up being tens or hundreds of megabytes in size, despite how tiny the headshots look in the browser. Plus, there’s a load on the browser, which has to store the full-sized images and resize them for rendering — you can sometimes see that effect when scrolling the page is sluggish.

The solution is for the webmaster to take the time to create images of the right size (or close to it) from the start. If someone sends you a 2400 x 3200 portrait, scale it down to 150 x 200 yourself, and just put that image on the web page (there are programs available for this, which make it easier to handle a lot of photos). If you want to make the larger one available for clicking, something like this will do:

<a href="staffPics/full/jane.jpg"><img src="staffPics/thumbs/jane.jpg" height=200 alt="Jane Smith"></a>

The height=200 still ensures that they’ll all be the same height, in case the thumbnails aren’t all exactly the same size (there’s no harm in letting the browser do a small amount of re-scaling). But now people won’t have to grab all those high-resolution photos unless they actually want to.