Highly optimized images for the web in 3 steps

Posted on .

Optimizing images for the web

I used to think that image optimization for the web meant: “minimizing the image file weight in bytes without degrading the image quality to an unacceptable level, by using compression”. While this is certainly an important part of image optimization, there’s more to optimizing images for the web.

In this article, I’ll cover the techniques I use to make images load fast on a webpage.

Why optimize images for the web?

With more and more people having a broadband connection in their homes one might be temped to think there’s no real need to optimize image on websites. But consider this:

Three steps to faster loading, lighter images for the web

  1. Change the image content. Busy, colorful and detailed images are harder to compress. If possible, we could change the content of an image to make it more “compressor friendly”.
  2. Reduce the number of image files you have to export. Less files means less HTTP requests. Each of which introduce a slight delay.
  3. Choose the right file format and settings and export the images.

Let’s look at them in detail.

Step 1: Changing the image content

This isn’t something you can always do of course. For instance, for a museum site, you wouldn’t remove a few characters from a picture of Rembrandt’s “The Night Watch” just to make it compress better.

If a bitmap with a gradient is slightly grainy, chances are the image will not compress well.


Left, kinda grainy, it’s 10k. Right, no grain. 6k. Most people won’t even see the difference! So denoising or painting over bits in an image can really help. It will change the image slightly, but usually this isn’t a problem. In fact, often the image will look better!

Step 2: Reducing the number of HTTP requests

Here are several ways to reduce the amount of HTTP requests for images.
If you know more, please let me know!

Google's sprite image Google’s sprite image

Use sprites

A sprite is one big bitmap file containing different design elements for the design of a page. Using CSS background-position, width, height and overflow properties the right part of the bitmap can be shown at the right place. Only one HTTP request is needed instead of one per every design element, eliminating a lot of delay. A good example is the image you see here on the right.

Read Smashing Magazine’s great article on using sprites in web development.

Here’s a fantastic web app for creating a sprite images + css with just a few clicks!

Embed images in HTML or CSS with inline images

Another way to get the number of HTTP requests down is to use inline images. The image data is embedded in the HTML or CSS, so no additional HTTP request is needed.

From the Wikipedia page:


ul.checklist li.complete { margin-left: 20px; background: url('data:image/png;base64,↵ iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQMAAAAlPW0iAAAABlBMVEUAAAD/↵
g9C9zwz3gVLMDA/A6P9/AFGGFyjOXZtQAAAAAElFTkSuQmCC') top left no-repeat; }

Don’t use images at all

There are a lot of cases where you actually don’t need images. With technologies like Webfonts, SVG, CSS3 (rounded corners, gradients, box-shadow, text-shadow etc) it’s much easier to create good looking buttons and headings, all without images.

Most modern browsers support these technologies. Let the design of elements styled with these new technologies “gracefully degrade” in older, less capable browsers.

Step 3: Choosing the right file format and settings

Finding out which type of image format you should use is often more and art than a science. For the web, you basically can choose between JPEG, PNG and GIF. There are more options, but these aren’t supported by only a few browsers.

JPEG (lossy) or PNG/GIF (lossless)?

The rule of thumb is: Jpeg (lossy) for photographic material, gif/png (lossless) for text and graphics. If your image needs to have transparent bits, JPEG is out.

Still, I do recommend you experiment. For instance, in some rare cases saving text+graphics as jpeg at high quality settings gave virtually the same appearance (practically invisible artifacts and fringing) while having a much smaller file size. A good example of this are the large images in my portfolio (click on the photo frames). Most of them are high quality JPEGs, which look virtually identical to the PNG24 versions I had saved earlier. The only real difference was that the JPEGs were up to 200kb smaller!

Alternatives to JPEG

Jpeg2000 and JPEG XR, WebP are all alternatives for Jpeg. Since browser support for these formats isn’t too great I won’t discuss them here.

PNG8 or GIF?

Both GIF and PNG8 give you a maximum of 256 colors. I found that in 99% of the cases, PNG8 is a better choice than GIF in terms of file size. PNG also supports alpha transparency whereas GIF only supports 1 bits transparency (no translucent pixels, just on or off).

That said, Photoshop and Fireworks do allow you to save a lossy GIF which in some cases can give GIF the edge. Further, I could mention AnimGIF, but we buried that ancient bit of internet history next to the marquee and blink tag, right? ;). aPNG and MNG can do the same thing but browser support is lacking.

Compressing further

There are actually some ways to make the files that Photoshop and Firework or other similar software produce even smaller. Programs like PNGout, PNGcrush, OptiPNG, AdvPNG, JPEGOtim, Jpegtran and Gifsicle all do a great job at stripping out non essential bits and compressing even further, without a loss in quality.

I use ImageOptim, which is a GUI for the programs I just mentioned. It actually runs the same file through all these separate programs. Often it shaves of up to 40% off PNG files, sometimes even more! You’ll see smaller improvements in JPEGS, usually around 2 – 5%.


Wrapping up

Taking the time to do these optimizations can really pay off. I’ve seen cases where the image folder nearly was half its original weight, with a lot less files in it.

If you know of more ways to optimize images for the web, I’d like to hear them from you!


(3 so far) Add one

  1. Patrick says:

    About the reduction of HTTP traffic. I think it is also good to know when your request will be issued. Your inline HTML images will be processed before your CSS images.

    This means that if you include an image in CSS, it will be loaded after the CSS has been parsed and processed. This behaviour can be bypassed by the sprite approach.

  2. For an alternative to ImageOtim on Linux, check out Trimage 🙂

  3. Pablo Mendoza says:

    And for an alternative to ImageOptim on Windows, RIOT

Comments are closed.