The Not So New Best Practice: Progressive JPEGs

Recently, Chris Coyier of CSS-Tricks fame posted a hotlink to an article called “Progressive JPEGs: A New Best Practice” by Ann Robson. While I feel she makes some valid arguments for using progressive JPEGs this is far from new and far from a ‘best practice’ for the web design world.

Let’s argue why this idea should not be considered a ‘best practice’ shall we? Although I agree that some of her arguments for progressive JPEGs might be a valid solution in some cases, it shouldn’t be considered a best practice of developing websites as a whole.

First of all it’s an old idea. Back when the Interwebs were growing up and people first started to build web sites for commercial use and most of us were dropping in a AOL disk in the CDROM drive and taking over the telephone line – websites used progressive JPEGs. Why? Slow connection speeds… kind of like some mobile connections these days.

Essentially Ann offers two arguments for why progressive JPEGs provide a better and ‘faster’ experience:

The progressive scan gives the user a perceived faster speed.This argument is also old and also wrong. Progressive loading of an image actually gives the user a perceived slower (and annoying) speed. Two things happen to the user when a progressive JPEG is loaded: (1) Anticipation (2) Focus.

The user is now forced to watch the image load step-by-step building anticipation. This slow loading anticipation also distracts the user form the other content on the site. Instead of reading the paragraph below, the user is distracted by the pixelated image that is loading… curiosity. This is not the experience you want for the user.

It’s like standing in a huge line at the post office where you can see the desk at the end. That is great that you can see the end fo the long line, but it really sucks to watch the clerk at the desk take their sweet time making small talk with every person in line for five minutes if you actually have some where to go. If you are in a long line, it’s better to be distracted by other things around you rather than focus on the line you are standing in. Look at pretty much any ride line at Disneyland – they build in a line experience that takes the focus away from the line and onto other things.

A sequential JPEG actually provides a faster perceived and faster actual speed as well as a preferred user experience. By displaying either nothing or a loading image icon or something the user can then move to other content and start experiencing the website on slow connection speeds faster and not get distracted by some pixelated loading images that grabs their attention.

The other small user experience thing to consider is what the user is expecting. Since web designers have de-bunked the progressive best practice myth awhile ago the majority of users are expecting and comfortable with a ‘blank’ image with it loads.

Responsive images that should blow your mind.The argument here is just that when the image is shrunk down for mobile via a responsive or adaptive technique that the image will still be viewable while it is loading so that the user still views ‘enough’ image information. Now, this might be a fun trick for a small screen mobile phone, but the desktop or even tablet experience will still be slow and bad for the same reasons as above.

This isn’t an answer for responsive images being that you might be creating a better experience for a small screen while providing a bad experience for larger displays. There are better more effective and truly responsive answers to image loads on slow connection small devices – starting with image optimization.

I’m not trying to be a jerk I promise

Look, I don’t mean to be knit picky about this or sound like jerk, but from a design and user experience standpoint using progressive JPEGs doesn’t make sense and shouldn’t be considered a ‘best practice’. I’m down for revisiting old lost techniques if they make sense and push web design and user experience in a better direction, but using progressive JPEGs hurts the over experience of the web… it’s kind of like the old technique of telling the user to “download a better browser” or “this site best viewed in Chrome”.

If we consider mobile and performance issues as simply different accessibility problems than we can move the web forward and find better solutions and better ‘best practices’ that aren’t just old tricks or gimmicks.

But that’s just my take… I could be wrong.

About the author

Patrick Cox wrote 99 articles on this blog.

Patrick is a UX Designer and the co-creator of Payba.cc and Aplethora (a two man interwebs design firm). He also enjoys family, snowboarding, sports and sugar free water mix ins and.... this is his blog.

6 comments

  1. Sebastian Frost

    But browsing a website using baseline-rendered jpgs on mobile can be also very annoying! Lets say the page isnt completely loaded, but were curious and scroll to the middle of the page, maybe dig into some content (like reading a paragraph), and then suddenly, the baseline jpgs infront of it, get entirely loaded and the content we were into jumps (way) down the page and we have to search for it once again to read the rest of it. maybe it isnt a best practice, but progressive jpgs can give a certain advantage. Appreciate the thoughts anyway!

  2. D Dolan

    In complete agreement with you on this. I worked through the progressive jpeg era of the 90s and experienced first-hand the benefits and drawbacks. By her own statistics, 35% of current browsers don’t support the format in a way that is beneficial to the user. That is completely contrary to a “best” practice. In my mind, the best practice is the one that accommodates the widest possible audience, with 100% compatibility being the goal. And the use of dimensions in a layout eliminates one of her primary arguments for using pjpegs.

  3. Sebastian Frost

    But in RWD I avoid dimensions wherever possible.. And those 35% of the users that can’t benefit from the progr. format get no disadvantage, because (as far as i know) the progressive jpgs are treated as baseline jpgs if unsupported.

    • D Dolan

      According to the table in the article, the browsers without progressive jpeg capability renderer the image after it is completely downloaded, which by her own definitions is slower. Personally, I would rate the true disadvantage of this to a scale tied to the users connection speed. In a broadband environment, it may be a moot point.

      The reason I discontinued using progressive jpegs years ago was client feedback. They hated them. If there were a bottleneck in the connection anywhere, they would freeze in a blocky state. Granted, this was a decade ago and better infrastructure, more powerful graphics chips and much better browsers may have marginalized this issue as well.

      I’m not opposed to using them, I just take issue with her declaration of this as a best practice. Speaking of which, I’m curious as to why you avoid dimensions. I don’t usually apply dimensions to images directly, but they are always within some dimension-specified element. Is that what you mean, or do you just avoid setting any dimensions?

  4. Sebastian Frost

    I’m sorry, of course I specify dimensions, I could made my point clearer. But as you said, only on containing elements, and most of the time only relative widths (percentages). Anyhow there can be cases in which I have to set a height for certain circumstances..

  5. Pingback: Tweet Parade (no.01 January 2012) | gonzoblog