Progressive vs. Optimized jpegs
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.
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.
Photoshop has an "optimized" option which compresses jpegs even smaller than baseline or progressive.
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.
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.
+1 to DA01
If OP is referring to reduced file size as "optimized" then here are some standard practices when saving as JPEG.
- Don't embed color profiles. Browsers these days have better ICC profile support.
- Export image as sRGB
- Set metadata to none
- Set quality at 65%. More about quality settings can be found here.
- 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.
Trial and error with over 6 years spent on optimizing images for the web. Here's a pretty picture example http://laurashoe.com/2011/10/18/jpeg-quality-compression-lightroom/ added to post. ty.
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.
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 https://github.com/iamaaditya/image-compression-cnn of Semantic Perceptual Image Compression using Deep Convolution Networks https://arxiv.org/abs/1612.08712 which is worth checking out. Google released a similar encoder https://github.com/google/guetzli
Also here's a more practical explanation of perceptual image compression by Flickr https://code.flickr.net/2015/09/25/perceptual-image-compression-at-flickr/
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.