Everything old eventually becomes new again and lately that's meant a revival of interest in something most web developers probably abandoned long ago – progressive JPEG images.
Progressive JPEGs offer some advantages over their more common "baseline" counterparts, including potentially smaller file sizes and faster perceived load times. But there are trade offs to bear in mind before you start converting your back catalog of images.
If you happened to have missed the pixelated image loads of the circa 1999 web, here's a brief refresher: There are two primary types of JPEG images, baseline and progressive. These days the vast majority of photos you encounter are baseline JPEGs, which means they start loading with the fully rendered top of the image and then continue to draw in the rest of the image as the data is received.
Progressive JPGs on the other hand load the full photo right off the bat, but with only some of the pixel data. That means the image briefly looks pixelated and then appears to sharpen focus as the rest of the data loads. This was the generally recommended way to optimize images back in the days when 56K dial up was considered smoking fast.
Lately, with mobile devices bringing bandwidth limitations back to the web, there's been something of a resurgence of interest in progressive JPEGs. The Web Performance Advent Calendar even ran a piece entitled "Progressive JPEGs: a new best practice." Here's developer Ann Robson's take on why you should use progressive JPEGs instead of baseline:
If you're building responsive websites, progressive JPEGs are also appealing because you can avoid the content reflow that happens when baseline images are loaded after text content. With progressive JPEGs, because some data is loaded right off the bat, text doesn't jump around (you can avoid this for non-responsive images by specifying the image dimensions).
Be sure to read Robson's full article for some important caveats regarding progressive JPEGs, including the fact that browser support is less than ideal. All browsers will render progressive JPEGs just fine, but many of them – Safari, Mobile Safari, Opera and IE 8 – render progressive images just like baseline JPEGs, meaning there is no speed difference.
Another strike against progressive JPEGs is that they must be rendered multiple times as more data arrives. So while they may be marginally faster and possibly make users feel like the page has loaded faster, they hit the CPU pretty hard. That makes them potentially slower than baseline JPEGs in one of the use cases they're supposed to be ideal for – underpowered mobile devices.
But perhaps the most questionable aspect of progressive JPEGs is whether or not users actually perceive a fully loaded, but blurry image that eventually comes into focus as faster than an image that takes longer, but renders all at once. Unfortunately I haven't been able to find any actual usability studies addressing that question. I suspect that how you feel about progressive JPEGs is probably, among other things, a good indicator of how long you've been using the web, which is to say that if you're all-too-familiar with progressive JPEGs from watching them slowly sharpen into focus over painfully slow dialup it's hard to see them as anything but an annoying anachronism.
So, should you switch to progressive JPEGs? As with most things in web design there is no right answer. First you should look at your site's stats, see which browser and devices your visitors are using and whether or not those browsers even render progressive JPEGs progressively. Assuming they do and you want to test progressive JPEGs, check out this old, but still very relevant, post from Yahoo YSlow developer Stoyan Stefanov, who has some data on when, where and how to use progressive JPEGs.
