[Yokohiii]

Adjacent advice: I've recently played with opengl and jpeg turbo and I wanted to display images fast. I don't remember exact numbers, but enabling progressive for a jpeg was a significant slowdown for decoding. So if anyone like me is stuck with the old school advice that progressive is an nice to have, it's likely not. I personally don't remember any visual progressive image buildup in like decades, so it's not doing anything valuable at all.

[msm_]

>I personally don't remember any visual progressive image buildup in like decades, so it's not doing anything valuable at all.

Maybe you just don't notice? It can be pretty invisible sometimes. I sometimes notice that image soon after page load an image is slightly blurry, and then another pass "sharpens" it. Yeah it's not like in the "old times" when the first progressive level was almost unreadable, but there's still value in sending a lower resolution version of image in 30% of the total file-size, basically for free

[jrochkind1]

I haven't been able to see it even setting Chrome developer tools to crazy slow network speeds. Maybe chrome developer tools simulation isn't enough to see it?

The observations you are reporting are from images you created yourself and you know are in fact progressive jpegs? (not "regressive", although that's funny). There are of course other techniques to start with a lower resolution image that do "work" (in the sense of actually displaying a lower resolution image first at least).

[cubefox]

Progressive decoding isn't expected to speed up decoding, it's expected to speed up displaying large image files, especially for downloads via slow mobile connections.

Example: https://youtube.com/watch?v=UphN1_7nP8U

[Yokohiii]

I've started using computers in the 90s, I've seen this every day back then.

Still the question is, does it help? Trying to access an average web app will probably take minutes before the browser may even see an image. If you do everything possible to render reasonably fast on very slow speeds, then progressive is nice. On a fast connection I don't think the average user will notice the difference.

[phyzome]

Where it helps is in finding out if it's even the image you wanted. You get a sense of it from the fast first pass, and then can hit back if it's not the thing you thought it was.

[chronogram]

I use cjpegli as encoder and it compresses best with its default progressive and full 4:4:4 approach, so it's not only a nice to have feature.

[Yokohiii]

I deliberately was talking about decode speed. The question is if you serve even via moderately fast infra, does it display faster? In my case on a (indeed fast) local system absolutely not. Mere size can be a decode problem of course. But it's extremely hard to tell that a single digit percent size difference is an advantage for serving.

But if better compression for storage or you can verify progressive serves faster then it is of course a benefit.

I guess the point I am making is that most people think: I heard it's somehow better so lets use it.

[Dylan16807]

Is you have a normal CPU then does decode speed matter?

But a lot of people do have slow connections sometimes.

[Self-Perfection]

JPEG photos stored as progressive usually take ~5% less space so there is value.

And it is possible to losslessly transcode JPEG to progressive.

Lossless transcoding to JPEG XL gives even more space savings though.