Small GIF and JPEG files - by design, not just optimisation by Ben Summers
Last month, I discussed how to get the best out of JPEG files, and the month before that, GIF files. But simply producing small files is not the only thing you can do. HTML forces you to consider its limitations when designing web pages, but with graphic files, the tendency is to draw first, optimise later. Why not design your site to have small graphic files in the first place?
This month, I'm going to discuss how to design Web pages to take advantage of the strengths and weaknesses of GIF and JPEG files, rather than making compromises when optimising the graphics.
The basic principle is an extension of choosing the right format for the right kind of image ... for iconic images with solid colors, use GIF, and for photographic images, or graduated colors, use JPEG ... but instead of thinking about it after the image has been created, consider it before you create the final graphics.
You'll probably have an idea of the overall effect you want to create, perhaps even a mock-up. The trick is to think about which format you're going to use when designing the final image, and then draw the image to make the best use of that format.
Try to make each cell as large as possible without compromising your design. Not only does each file have it's own image header (and palette if it's a GIF file) but there's web server overhead too. For each file requested, there's around 400 bytes of HTTP server chit-chat which needs to be sent to request the image, so if you're not careful, this hidden cost can be more than the file size you save. Unless, of course, you reuse these images on other pages, where since they're cached, they won't have to be downloaded again and are effectively free. It's a very fine balance.
GIF is very good at compressing images with large areas of solid color (or composed of regular dither patterns) and retaining sharp edges, so design your image with as small a set of colors as possible (not including colours used for anti-aliasing). You don't have to use the same set in each GIF cell, so you can use a much lower BPP (bits per pixel) than if you'd just used one larger image.
JPEG, on the other hand is extremely good at compressing changing colours, so use JPEG for cells with continuous changes (like a marbled background). It's not very good at sharp edges and solid colours, especially at the high compression ratios you'll be using, so steer clear of those.
Here, the red square aligns with the 16 x 16 grid of the JPEG's color channel.
The red square is in an arbitrary position here and the compression artifacts very obvious.
If you want horizontal or vertical sharp edges in a JPEG image, you can often get them nice and clean if you place them at the right point in the image. JPEG files are compressed based on 16x16 pixel blocks starting in the top left corner, so if your lines are at the edges of these blocks, the line will often appear at lot cleaner than edges at other position. (For example, a square at coords 16,16 to 32,32 exclusive). Brightness is stored in 8x8 pixels blocks, so if the brightness rather than the colour is changing, you can use edges of 8x8 pixel blocks, but you'll probably find the color blurring. Bear in mind you might be better off splitting the image instead, but this can be a useful trick.
Be careful if graphical elements cross format boundaries - if you have, say, a arrow which is mainly drawn using GIFs, and a part crosses over onto a JPEG, you may find that it's clean lines are blurred on the JPEG causing a rather noticeable effect - more so than if it was entirely represented with a JPEG and therefore all slightly blurred.
But that's not the only thing you can do - you can use browser caching to minimise the number of graphic files used. For example, you could use the same graphic multiple times on your page - it will only be downloaded once however many times it appears on your page. Or perhaps, if you're producing horizontal or vertical bars of color, create an image with smaller pixel dimensions and use the width and height attributes to stretch the image to fill the required area.
Try to reuse graphics from one page on as many other pages as possible - if they're in the browser's cache already, they won't have to be downloaded again when the user views the next page. Or indeed, don't use graphics files at all. Careful use of the bgcolor attribute in table cells can save an awful lot of graphic files!
Producing small image files is one thing, but producing small web pages is another, almost completely different, thing.
Your own perception of acceptable quality is important too. But quality isn't so important on the web as it is in print. Your work is always subjected to the user with the dodgy monitor set to be overly bright... But, is high quality and intricate, colorful design all that important anyway? Those are the things which, when you do all you can with the optimisation, will make your graphics files large... Most people just want to read the content!
Graphics were an afterthought by the original designers of the Web. Let's try and stop them being the thing which makes the internet crawl to a halt today.
Ben Summers is a UK developer specialising in providing dynamic web solutions for interactive online applications and developing web graphics software. Ben's company Fluffy Clouds has just released a new web graphics optimisation program called Ignite. a 30 day trial version is available for download from the Ignite Web Site.