Images on the Web

by Brian Farr — May 14, 2012

Or, "CDN's are great, but you're serving an image 4x larger than it should be."

I've been noticing a trend lately on a lot of websites I visit: They are doing a lot of things right for load speed: compressing/minifying CSS and JS resources, using content distribution networks, setting correct server headers, serving gzipped content, and all that other good stuff. But then I look at their images, and they are serving half-megabyte PNG's for medium sized on-page images. These could be saved as a visually indistinguishable JPEG image that is about 4-5 times smaller.

Why care about file size in 2012? Several reasons, but... you could be saving money on bandwidth, and you can provide a noticeable speedup to anyone on lower bandwidth or mobile connections.

If you're fuzzy on the different image formats, here's a quick rundown on their uses, strengths and weaknesses:

  • JPEG — Good for photos and certain textures. Uses lossy compression, but this is not usually noticeable in the upper half of the quality levels. No transparency.
  • GIF — Good for background textures, and smaller, non-photo images. Limited size color palette. Supports basic transparency (transparent/opaque, nothing in between). Typically small file sizes.
  • PNG-8 — Fairly similar to GIF, with color palettes and basic transparency. Sometimes better or worse file size than GIF, depending on the specific image.
  • PNG-24 — Full blown PNG, with the full range of transparency (allowing for drop shadows and blending with other layers). Uses lossless compression, which means full/original quality images, but can result in comparatively large file sizes.

Some Examples

When I recently worked on a winery's website, I made use of lots of images. The background of the page uses a cropped and stylized photo of some of the grapes and leaves in their vineyard, and has fairly large pixel dimensions. If I exported this image as a PNG-24, it would give me a ~700kb file. However, by saving it as a JPEG, and selecting a medium compression level that did not produce visible artifacts, I was able to create a 60kb file.

The logo of the same site was saved as a PNG-24, since it has a drop shadow and intricate cutouts.

A Less-than-optimal Technique, and an Improvement

I've seen this in a couple of places now. The centerpiece of a web page was two photos, with a border between them. The page creators had done this by making an image with a transparent gap that combined both photos, and saved it as a PNG. Here's an example of what I'm talking about:

PNG Photo spread with transparency:
photo spread

This works on a surface level, but has several drawbacks. First, the file is a whopping 549kb. Second, although the transparent gap saves on some markup, it can't be adjusted to a different size without using an image editor.

Although I'm not terribly excited about making a two-photo spread in one image, here's both images, without transparency, saved as a JPEG instead:

JPEG Photo spread with transparency:
compressed photo spread

Doesn't really look any different, right? That's the point! However, this one has the advantage of being only 56kb, using a JPEG quality level of 50.

Conclusion

Take an extra second to optimize your images when creating them, and configure your backend to compress user submitted images, and enjoy the benefits of a lower bandwidth bill and faster page loads.