I think the first step of any optimization strategy is to understand what you are doing, and stating the goal that can clearly be either reached or not. Size cr

I think the first step of any optimization strategy is to understand what you are doing, and stating the goal that can clearly be either reached or not. Size crunching on a couple of images is fun, valiantly processing a sizable collection of pictures with optipng makes you realize that your CPU(s) are glowing from heat for hours just to take 10 bytes off the file that still fills the same amount of disk sectors. That's even bigger waste of energy than mining. One particular trick is getting images with visually low number of distinct colors, like logos and screenshots, through pngquant. You don't have to worry whether the actual number of colors is less than 256, how to posterize or filter the image to decrease that number, or how to suppress artificial colors from font anti-aliasing — the tool measures the visual likeness, and provides the means to set the acceptable limit so it would leave unsuitable images intact. Obviously, when you're dealing with some long-term archival storage, or assets for further editing like stock clipart, such presentation-oriented lossy optimization should not be used. Other automatic tools are referenced in the article, though you should treat them as a nice sanity check that prevents images holding raw uncompressed data or simple two color graphs saved as 4 byte RGBA from appearing in your project, and not a magical solution that would send it to the sky performance-wise. Bandwidth (and loading time) is usually wasted on complex high resolution images like photos or combined graphics with photographic details. These can't really be optimized well enough in PNG with naive lossless or lossy methods, and have to be converted to JPEG to reach sane size or regenerated as independent layers that use different compression.