Thanks for filing @paales! This is a great idea!

It's important to note what Lighthouse is actually flagging here though. The breakpoint for this image that gets selected is the 300px version while its displayed size with DPR factored in is ~240px, which because it's a square is ~56% larger (300300/240240) than necessary. In this case it feels like Lighthouse is being a tad overaggressive given the wide range of breakpoints you have in your srcset already.

Lighthouse core team, the fact that our Moto G4 example device has a DPR of 3 makes this audit much less useful IMO. It basically has a forgiveness factor to non-responsive images of 90% waste while here we're ending up flagging fairly reasonable breakpoints instead our actual intention of ensuring they've used breakpoints. How would you feel if we dropped our emulated DPR down to 2 or even 1? If there's some consensus there, happy to break it out into a separate issue for discussion.

Thanks for the prompt response!

Lighthouse is flagging my 'upgraded' images because i can not detect a slow connection. If you disable JS on the page, you can see it'll download the low quality images. The intention is that I keep them low quality if the connection is 3g (or lower).

As for the size, nice catch, I can add a 150px and 250px breakpoint, that might make a small difference in this case. As for lowering the DPR that'll help a lot! It kinda feels as a workaround.

The this this doesn't allow me to do: Offer highly compressed images for low bandwidth situations and offer pristine images on high bandwidth situations.

Lighthouse is flagging my 'upgraded' images because i can not detect a slow connection

The size explanation was attempting to clarify that this is not lighthouse's intention. A site does not need to detect a slow connection and serve 1x resolution images to pass. It just needs to serve images that are not excessively larger than the displayed size and in this case 56% larger was too much due to the specific breakpoints used.

The this this doesn't allow me to do: Offer highly compressed images for low bandwidth situations and offer pristine images on high bandwidth situations.

That's definitely a best practice we want to encourage here (very impressive you've implemented this by the way!), so we'll likely implement the ECT change as well, but it's not something we're enforcing yet.

How would you feel if we dropped our emulated DPR down to 2 or even 1? If there's some consensus there, happy to break it out into a separate issue for discussion.

no opinion on this yet, but this would be a breaking change right? and if we didn't match what moto g4 is...what's the point of labelling our emulation as such?

FYI: I've made a temporary workaround by doing a user agent sniff. I know this is kinda dirty, but allows me to work around the issue now.

this would be a breaking change right

I would consider it a breaking change, yeah.

if we didn't match what moto g4 is...what's the point of labelling our emulation as such

Mobile UA, viewport size, CPU performance are the more important aspects of mobile emulation, IMO. While the Moto G4 is a helpful pick for those three attributes, in the case of DPR emulation it is actually detrimental to our performance recommendations.

The point of labelling our emulation in my view is to give end users an easily understandable reference for the caliber of device we are targeting without needing to understand the details of processor specs, viewport resolution, etc. Admittedly, if we did such a change for DPR we should probably find a realistic phone that matches a Moto G4 on the other dimensions we care about but actually has 1:1 or 2:1 DPR like our old Nexus 5X.

(going with dpr=3 would mean images that are huge would get a free pass on responsive-images)

More calculations for why dpr=3 is bad

edit: a few months later (oct 2020) we added core(hidpr-images): never recommend more than 2x by patrickhulce · PR #11518 [merged]

We'll consider overwriting this in JS, though we may have to simulate with protocol.

We are using effectiveType to load some scripts only on faster connection. Lighthouse seems to emulate the speed of a 3g connection while effectiveType is 4g when the audit is running. Please can you set a coherent value with the connection speed before running the audit?

Hello! :-)

That's definitely a best practice we want to encourage here (very impressive you've implemented this by the way!), so we'll likely implement the ECT change as well, but it's not something we're enforcing yet.

That would be so good if you could implement "navigator.connection.effectiveType" and "navigator.connection.downlink". I am currently using downlink to get lower quality images, but unfortunately it doesn't work.
When I test in Lighthouse, "Moto G4" reports a downlink of 10, instead of something around 1.6.

IMHO, downlink is more useful than ECT, but having both would be the best :-D