9

I know that progressive jpegs download in multiple passes, and optimized are smaller (and thus faster to finish downloading), but does anyone have any hard data or best practices on which type users actually prefer?

  • Progressive JPGs were kind of a thing during the dial-up era. They're likely still a good idea, but just haven't been used that much since then. BTW, I believe these concepts aren't mutually exclusive. A JPG can be both optimized and progressive. As for the user, I think they simply prefer whatever loads faster. – DA01 Jul 6 '15 at 20:19
  • I consider myself a user, and will, from today, be using non-progressive jpegs, as my image-editor of choice (MS Paint - love it) cannot open progressives. – theonlygusti Jul 6 '15 at 20:19
  • Photoshop has an "optimized" option which compresses jpegs even smaller than baseline or progressive. – Choylton B. Higginbottom Jul 7 '15 at 20:31
  • Are you referring to reduced file size as optimized here? if yes, then read the document in the link I've posted in my answer. That's the best as far as best practises go. – Rayraegah Aug 5 '15 at 21:31
12

Let's start with the difference between progressive and non-progressive JPEG files. Non-progressive JPG files ar not by definition smallers than progressive JPEG files. A rule of thumb found by Stoyan Stefanov is that JPEG files smaller than 10K are best compressed non-progressive JPEG, but that bigger JPEG files become smaller when stored as progressive JPEG.source see the chapter progressive JPEG.

So if you just want the smallest download non-progressive is not always the best choice.

This 2012 article goes into more detail Progressive jpegs a new best practice

Tip if you want even smaller JPEG files use mozjpeg

But now to anwser your question. You wanted to know if anyone has actually done any research on user preferences. Well actually someone did.

You can read an article on the research by Tammy Everts here: Progressive image rendering: Good or evil? It contains a link to where you can obtain the full report.

Spoiler: users seem to prefer baseline JPEG files over progressive.

5

Here's an alternative perspective on it. Not an absolute rule, but a thing to keep in mind.

It depends on what the image is for. Content, or decoration?

If it's a background or other design element, use progressive, so the page looks okay-ish as soon as possible. If it's an element that moves stuff around, it needs to be there ASAP so people don't mis-press a button due to layout shifting. (been there a couple of times on mobile.)

If it's content the user is going to download, or consciously pay attention to, use regular JPGs. This communicates to the user that it's not yet finished, that they have to wait a bit. This stops them from saving an unfinished download, and they won't experience the site as bad quality but the server/connection.

  • 2
    I like the perspective. On a side note: stuff shifting around can be helped by setting height or min-height in your CSS (where possible) – Choylton B. Higginbottom Aug 6 '15 at 17:02
3

+1 to DA01

If OP is referring to reduced file size as "optimized" then here are some standard practices when saving as JPEG.

  1. Don't embed color profiles. Browsers these days have better ICC profile support.
  2. Export image as sRGB
  3. Set metadata to none
  4. Set quality at 65%. More about quality settings can be found here.
  5. Ensure the file size and dimensions are in scope of your requirement. i.e. don't export a 2000x3000px image for a mobile website.

More about Optimizing images Guide by Google.

  • Where does the 65% come from? – rink.attendant.6 Aug 5 '15 at 21:30
  • Trial and error with over 6 years spent on optimizing images for the web. Here's a pretty picture example laurashoe.com/2011/10/18/jpeg-quality-compression-lightroom added to post. ty. – Rayraegah Aug 5 '15 at 21:32
  • I would recommend against picking a hard and fast JPEG quality setting. 65% is a great target, but the particular content may require a higher quality. Or, you may be able to get away with less. – Brad yesterday
  • I think my reply needs an upgrade. Since 2017 I've been experimenting with content aware image compression ever since I caught google chrome browser using a variational autoencoder to upscale images on the client. I found a python implementation github.com/iamaaditya/image-compression-cnn of Semantic Perceptual Image Compression using Deep Convolution Networks arxiv.org/abs/1612.08712 which is worth checking out. Google released a similar encoder github.com/google/guetzli – Rayraegah yesterday
  • Also here's a more practical explanation of perceptual image compression by Flickr code.flickr.net/2015/09/25/… – Rayraegah yesterday
2

I'm having trouble finding a definitive, recent answer but from what I can tell, Mobile Safari, to pick just one mobile browser, supports progressive JPGs, but doesn't actually load them progressively--meaning it just waits for it to download entirely, then displays it.

So it seems that the visual progressive loading feature simply isn't all that relative today, making the benefit much less appealing.

That said, making a JPG progressive may help compress it's total size, so by all means, that's still a benefit, but it's probably just not a big enough benefit where it's caught on widely.

Also, as stated in my comment, I don't think this is a 'vs.' issue. Unless I'm misunderstanding what you mean by 'optimized' a JPG can be both progressive and optimized. In fact, any image format for your web site should be optimized.

0

The main difference is that when the picture (jpeg file) is export as "progressive" is going to load the full size image with reduced quality, while if it's export as "optimize" is going to load section by section from top to bottom.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.