Blog Tags: 

PNG vs JPG: 6 simple lessons you can learn from our mistakes

Page load times are important. Amazon insiders estimate that every 100 ms increase in latency costs Amazon roughly %1 of profit.

Simply put: visitors hate slow sites, so don't make them wait.

Unfortunately, many web sites, including this one up until recently, are slowed down by inefficiently encoded images. Note that there are many other components to page load times and if you're looking to optimize your web site you should analyze and understand all of them. But today we're just going to focus on the images.

Our mistake was very simple: we used PNG for everything. Of course, we realized other encoding formats such as JPG existed, we just didn't have a good awareness of when you should use one and not the other. Bzzzzt.

  1. PNG is a lossless compression format: that means it compresses images without losing any quality. But it's not economical to encode most images in a lossless format such as PNG, when the loss of quality using JPG is barely perceptible to the human eye and a JPG might only take up a quarter of the space.

    For example previously the front page weighed 701KB and was visibly slow to load. A large component of that weight were the PNG appliance icons. Batch converting the icons to JPG shaved 400KB off, a 60% reduction!

  2. Gotcha! JPG doesn't support transparency (but don't waste your time trying to optimize PNGs): since we initially depended on icon transparency in the web design we resisted making the change and tried optimizing the PNGs first. We tried every tool we could find. Lossless optimizers such as pngcrush and optipng only yielded a 3-4% decrease in filesize. Lossy compressors such as pngnq slashed the file size dramatically by reducing the color depth but the decrease in image quality was often unacceptable. Some icons (e.g., Drupal) looked OK, but others looked terrible.

    A few examples. In the first row are originals, second row reduced to 256 colors, third row 128, fourth row 64:




    Bottom line: PNG optimization is a poor substitute for JPG. We concluded that it was better to modify the web design and compromise on that than accept a 3X increase in load time for the front page.

  3. Don't compromise on resolution, compromise on compression: after we finished with the front page we turned our attention to the screenshots section. To compensate for the size of PNG encoded screenshots we had previously reduced the resolution of the image but that's a bad move because it results in dramatic reduction in readability of the screenshot.

    For the same size we discovered you could encode a much higher resolution JPG image at high quality such that the user would barely notice any compression artifacts. Overall this would provide a much nicer, more usable screenshot without increasing bandwidth requirements.

    Long story short, resolution is very important to the perception of quality and it's one of the last things you want to give up when you are reducing bandwidth requirements.

  4. Keep PNG "masters" for future image manipulation: I can't stress this enough. JPG is a lossy format, and every time you re-encode a JPG the quality deteriorates. After a few passes compression artifacts pile up and can become easily visible to the human eye.

    For this reason it's best to always keep around masters of your images in PNG format in case you want to perform edits.

  5. When PNG is better than JPG and vice versa: sometimes you just don't want to compress an image with JPG. As I mentioned earlier, if you really need transparency JPG is out. But also we've discovered small and simple images may actually compress better using PNG than JPG. It seems to depend on how much is "going on" in the image. PNG works best for vector type graphics with hard lines. JPG works best for anything with complex gradients (e.g., a photo).

  6. Use imagemagick to batch convert PNG to JPG: manually re-encoding PNG images into JPG is boring, especially if you're converting a large number of images.

    ImageMagick is the swiss-army knife of command line image manipulation tools. Using it saved us a ton of time:

    apt-get install imagemagick
    convert -flatten -background white file.png file.jpg
    

    Convert an entire directory:

    
    for f in *.png; do
        n=$(echo $f|sed 's/.png/.jpg/');
        convert -flatten -background white $f $n
    done
    

Was this post helpful to you? Share your experience, post a comment!

Comments

Liraz Siri's picture

Thanks for chipping in. If memory serves I tested pngout extensively. Instead of fiddling with the PNG optimization at random I just tried all the options exhaustively and let that run for a few hours then came back to see the results. I didn't discuss the experiment in detail because I was disappointed to have so little to show for it. Perhaps with DeflOpt and AdvanceCOMP one might get better results. I'll have to try that sometime.
amir's picture

I have read an article, what both formats have advantages and disadvantages. What about raw format? What is your opinion?

The Articles is here

Jeremy Davis's picture

But how does graphics hardware acceleration make images load faster in a web browser? I guess maybe it could render them faster but I'd imagine the network bandwidth would be the bottleneck, not the graphics rendering.

Also how many people are actually using IE9? Last I checked XP (no IE9) was still the dominant OS (by a significant margin) and there are still people using Win 98 & 2000 (no IE9). Mac (also no IE9) sales continue to be steady and although real numbers are hard to get (because it's free), there is a growing body of evidence to suggest that the Linux desktop market share is continuing its steady growth (again no IE9). So unless your market are Win Vista & 7 users only then taking advantage of features only in IE9 would seem to be business suicide.

Liraz Siri's picture

If you're just displaying a static image hardware acceleration shouldn't make a noticeable difference. But it might if you're web application does something fancy with images (e.g., CSS3 manipulations + Javascript). Javascript is usually only used for very basic stuff (e.g., form input validation before submit), but it's a turing complete language that can do pretty much anything you can do in any other language. The main issue is not capability but performance, in which case hardware acceleration integrated with the browser might actually come in handy...
Jeremy Davis's picture

That makes perfect sense. And I guess really that's were it's all headed isn't it!? Lots of web/cloud apps that are far far more than just static pages...

Liraz Siri's picture

What's happening today is pretty much the original Netscape/Sun vision of the browser/network gradually eroding the relevance of the desktop computing paradigm. Your applications would run anywhere, on any device, over the network and it wouldn't matter what operating system happened to be running on the front-end device you were using at the moment. The visionaries were right, they just got the timing wrong.

Today, behind the scenes there are powerful interests at work (e.g., Google, Facebook that don't want to have to negotiate access to their users with companies like Microsoft/Apple who control the platform at the operating system level. This used to be a huge problem with Microsoft a decade ago. They were ruthless and people were scared. They were unstoppable! Funny how that turned out. You'd get really funny looks back then if you suggested that Apple would be resurrected from the brink to overthrow them as kings of evil (and eclipse their stock capitalization).

Anyhow, a decade or so late everything is gradually moving to the web/cloud now, regardless of concerns regarding the sensibility of this kind of centralization or the massive security issues. It's a necessary step before super cheap, ubiquitous, ever pervasive computing that follows you everywhere. Note that I'm not sure this is necessarily a good thing. Maybe I'm just paranoid/conservative but they'll take away the Personal Computer running under MY control when they pry it from my cold dead fingers. I actually like being offline.

Jeremy Davis's picture

I'm with you on the OS owership though. I don't think we have too much to worry about in the near future anyway. I'm not sure what it's like in your part of the world, but here in regional Australia mobile web access (3G) is still too unreliable and expensive for the dream of a mobile OS to really work (eg ChromeOS). Even if the issue of offline useage is circumvented, the perception of the average Joe will still be that it relies on internet access and will be turned off by that.

Pages