How is it possible to reduce an image by 90% without losing quality?

Formats and compression options

There are three popular image storage formats for web (not counting the promising WebP), and each format has its own compression options.

A clueless coder may pick the wrong format and use wrong options, resulting in less-than-optimal image quality and huge size. An experienced graphical designer is expected to know which format and options should be used, resulting in high quality images with low bandwidth footprint.

Let’s see how it works.

Example 1: 90% reduction

The first example is a photo. Nearly every photograph is stored in JPEG, but an inexperienced coder may hear somewhere that PNG is the best format, and prefer using PNG. This is what happens:

^{Open image in new tab to see the full-size 2470×1636 version.}

The size of this PNG image is 5 992 591 bytes—nearly 6 MB, enough to make both the server bandwidth and your customers unhappy.

^{Open image in new tab to see the full-size 2470×1636 version.}

Here is the same image exported as JPEG. The JPEG compression level was thoughtfully adjusted to avoid losing visual quality: watching the images side by side, you normally can’t tell which one is which.

The size of the JPEG image is 700 283 bytes, that is 683 KB: 11.7% compared to the PNG variant. We indeed achieved nearly 90% compression without affecting the quality of the image.

Example 2: 80% reduction

Now the clueless coder is convinced that JPEG images are much smaller than PNG ones, so he’s using JPEG for everything. When he needs to store a logo, he chooses JPEG.

^{Open image in new tab to see the full-size 1300×850 version.}

Since lower compression levels make JPEG artifacts noticeable, he should push the levels up to 100—lowest compression, highest file size. He obtains a 68 348 bytes file (67 KB).

A more experienced graphical designer prefers PNG. Here’s the result.

^{Open image in new tab to see the full-size 1300×850 version.}

By carefully adjusting the options, i.e. using a 8-bit PNG with 128 colors, he obtains the same visual result in a file which weights only 13 930 bytes (14 KB), that is 20.4% of the JPEG variant, that is a compression of approximately 80%.

Important notes about the examples

Although those examples show a difference of 80% to 90%, a really clueless coder may do worse. I knew people who were storing images in BMP format and were actually paid to create websites. There is always a way to screw things up and to achieve unnecessarily huge sizes without any visible gain in quality.

Having said that, both examples illustrate exactly what can actually happen when the website is done by inexperienced web designer or web developer.

The fact that many persons are using wrong tools makes things even worse. In those examples, I’ve used Photoshop to export the images in both formats. I would expect that different applications may perform differently when it comes to rendering final images, resulting eventually in poor quality coupled with excessive file size.

Why isn’t such a practice more popular in web development?

Who is Smush.It actually for?

Since we now understand how formats and compression options work and how are they enabling us to reduce the size of an image by 80% or 90% without losing quality, let’s see what is the actual value of Smush.It and who should use it.

Is it:

• For large projects made by teams of highly specialized and skillful persons?

  Probably not. Those persons can afford buying a Photoshop license and know what formats and options should they use for different images. They won’t need Smush.It, because the size of their images is already as small as possible.

  From there, either Smush.It will make some changes resulting in the loss of quality—something those persons want to avoid at all costs, or it will have no impact.

  This is confirmed by the website itself, which is very unfriendly. As a developer, I don’t want my images to be magically changed: I want to know what were the changes and all the magic which happened under the hood. I don’t want to use voodoo services: I need to know exactly what happens with my images, especially in order to learn from that.

  There might be some information on their FAQ page, but since it doesn’t work, we’ll never know.

  Blogs are not helpful either. There is one blog which mentions a gain of 4.79%, but this would be practically unnoticeable on most websites. The only mention of what actually happened under the hood is that Smush.It switched from GIF to PNG—something the developers should have be doing on their own if only they knew formats and compression options.

• For small projects made by inexperienced coders?

  Indeed, those coders don’t know how to store images in the first place and don’t care about the magic under the hood.

  But it’s not for them either. Chances are, they simply don’t care, and they have more important issues, such as the lack of client-side caching, the lack of CSS/JavaScript minification or the lack of Gzip compression.

The only two cases I can think of are:

• An inexperienced programmer who wants to impress his boss. He doesn’t know how to store images properly, but he knows that there is a tool which does all the voodoo magic for him. Result: he can make himself valuable in a company as a guy who was able to reduce the bandwidth because of his deep knowledge of online tools.

• A boss who learned about a new tool and wants to use it everywhere.

Having just tested it on a variety of images from a couple of web sites I maintain, I can state that I won’t be using it because it seems to do nothing useful: it was unable to achieve any savings for any of the four images I gave it (two JPEGs and two PNGs). I had taken no special steps to optimize these images, just saving them in the most appropriate format directly from Photoshop.