audit: Progressive JPEGs as part of opportunities

[addyosmani]

WebPageTest includes their own audit for whether sites are shipping down progressive JPEGs (images that are delivering with scans of increasing quality). This is something that may be interesting to explore as a Lighthouse loading audit.

Proposed description: Uses Progressive JPEGs Proposed help text: Delivering JPEGs with progressive decoding allows progressive delivery of images as a series of "scans" where each scan increases quality. This can improve perceived performance over "baseline" JPEGs, which display images as data arrives, one line at a time.

WPT presents this in an opportunities-style view that looks a little like this:

http://blog.patrickmeenan.com/2013/06/progressive-jpegs-ftw.html

[addyosmani]

@brendankenny @paulirish @patrickhulce tentatively assigning this to Ward as part of the next sprint. Would be interested in your take on whether this audit is worth being explored.

[patrickhulce]

Oh, yes I like it!

I am slightly worried about the cost of this audit needing to fetch all the image bodies over the protocol though. We previously found this to be prohibitively expensive and had to abandon the approach for image optimizations.

What do you think about piloting the new audit process on this @addyosmani? Specifically finding what impact we expect it will have and justifying runtime cost before proceeding to implementation.

[paulirish]

To add a few more things:

• Research indicating "regular" progressive jpgs aren't preferred by users: https://blog.radware.com/applicationdelivery/wpo/2014/09/progressive-image-rendering-good-evil/ .. but whatever.
• Nice posts on progressive jpg scan optimization: https://calendar.perfplanet.com/2016/even-faster-images-using-http2-and-progressive-jpegs/ & https://cloudinary.com/blog/progressive_jpegs_and_green_martians
• Mobile safari used to not support the progressive rendering of jpgs.. but according to this iPhone... it does now! :) Just emailed a Safari engineer to find out when this happened.

[paulirish]

I am slightly worried about the cost of this audit needing to fetch all the image bodies over the protocol though. We previously found this to be prohibitively expensive and had to abandon the approach for image optimizations.

Aye. We no longer need to fetch image resource bodies in Lighthouse. The optimal implementation would be a native protocol event/method or trace event indicating if a jpg is progressive or not. It does not appear to be a trivial implementation, unfortunately. But it's certainly doable.

[vinamratasingal-zz]

Hey Addy- thanks for writing in! I chatted with Paul and I was wondering if we can bake this part of our existing next-gen image format audit. Reason I'm saying is if we have a separate audit for progressive JPEGs, as an end user, it might be confusing because users might not be aware if they should be doing progressive JPEG, use WebP, etc. Consolidating into one image guidance audit might make more sense (and perhaps explaining that Progressive JPEG might require less effort than the other).

Otherwise, if you feel strongly Addy to have a new audit, I would follow Patrick's comment to create a new proposal with the new audit proposal system. Let me know if there are any questions here!

[addyosmani]

I chatted with Paul and I was wondering if we can bake this part of our existing next-gen image format audit. Reason I'm saying is if we have a separate audit for progressive JPEGs, as an end user, it might be confusing because users might not be aware if they should be doing progressive JPEG, use WebP, etc.

Implementing it as an addition to the existing next-gen image format audit sgtm. It looks like https://github.com/sindresorhus/is-progressive by @sindresorhus enables detecting if an image is a Progressive JPEG and may provide a useful reference point when looking at how we implement this as an audit.

Otherwise, if you feel strongly Addy to have a new audit, I would follow Patrick's comment to create a new proposal with the new audit proposal system. Let me know if there are any questions here!

This sounds quite reasonable. I can work on that. I just filed my first audit proposal in #4696 using the new system and found it pretty straight-forward.

[paulirish]

Aye, we'll need to know if a jpg is progressive or not. Unfortunately, the implementation here will have to be on the backend, as the perf of doing the check in JS isn't acceptable and getting image data has been unreliable for us in the past.

For the impl, we'll likely emit into a trace event some metadata about the images on decode.

I think we can then use byte-savings-estimation function similar to the one we devise for #4696. The byte savings tbh won't be very stellar. We do expect advantages to Speed Index, but it's hard for us to model that. As a result, I don't know how we can really quantify the benefit of this opportunity. So if that's true we can either leave it in diagnostics or it's perceived wastedMs benefit will be fairly small, but included regardless.

[jyrkialakuijala]

https://github.com/WICG/largest-contentful-paint/issues/71#issuecomment-769043733 discusses this need with passion, confidence and some evidence, too.