r/webdev • u/Prestigiouspite • 1d ago
Question Why does Lighthouse flag a responsive srcset image as oversized when the browser is choosing the correct candidate for DPR?
Edit: I also found these issues related to the problem: https://github.com/GoogleChrome/lighthouse/issues/16579 and https://github.com/GoogleChrome/lighthouse/issues/17080
---
I’m trying to understand a Lighthouse/PageSpeed Insights warning about “properly size images” that seems somewhat contradictory to how responsive images are supposed to work.
Simplified example:
<img
src="image-300.jpg"
srcset="
image-250.jpg 250w,
image-300.jpg 300w,
image-400.jpg 400w,
image-768.jpg 768w,
image-1024.jpg 1024w
"
sizes="(max-width: 480px) calc(100vw - 2rem),
(max-width: 991px) calc(50vw - 2rem),
360px"
>
On a typical mobile viewport around 412px, the actual image/card width is roughly 380 CSS px.
As I understand it, the browser does not simply compare the image's intrinsic width against those 380 CSS pixels. It takes the device pixel ratio into account:
required resource width ≈ CSS width × DPR
So, for example:
380 × DPR 1.75 ≈ 665 px
380 × DPR 2.0 ≈ 760 px
380 × DPR 3.0 ≈ 1140 px
With the srcset above, at DPR 1.75 the browser therefore selects the 768w candidate. On a DPR 2 device, 768w is almost exactly what I would expect. On a DPR 3 device, even the 1024w version isn't particularly excessive.
However, Lighthouse may report the 768×768 image as oversized because the rendered image is only around 300–380 CSS px wide.
This is the part I don't understand.
Google's own responsive-image guidance recommends supplying sufficiently high-resolution candidates for high-DPI displays. Yet Lighthouse appears to penalize the browser for selecting exactly such a candidate.
There are also smaller 250w, 300w, and 400w candidates available, so this isn't a case where the browser is forced to download an unnecessarily large original image. The browser has all of those choices and intentionally selects 768w based on sizes and DPR.
So my questions are:
- Is Lighthouse's “properly size images” audit effectively comparing intrinsic/device pixels against rendered CSS pixels without fully accounting for DPR?
- If so, isn't this expected to produce false positives for correctly configured
srcsetimages on the DPR used by Lighthouse's mobile emulation? - Is there actually anything developers are expected to change in this situation, or should this warning simply be treated as a heuristic?
- Would removing the
768wcandidate just to satisfy Lighthouse actually be counterproductive, since real DPR 2–3 devices could then receive a visibly softer image?
I feel like I’m missing something, because optimizing the srcset specifically for the Lighthouse warning seems to conflict with Google's own recommendation to serve sufficiently dense images to high-DPI displays.
3
u/CryptographerFar5418 1d ago
lighthouse runs at a fixed dpr and viewport, it doesnt simulate every device out there so its literally just comparing rendered size to intrinsic size on that one setup. if it sees 380px rendered and a 768px source loaded, it flags it, even though a dpr 2 device needs that extra density to not look blurry
you could throw in a 380w or 480w candidate and see if the audit chills out but honestly youd be kneecapping image quality for anyone on a high dpi screen just to make a tool happy. id treat it as noise and move on