GoogleChrome
Image sizes incorrectly flagged as too large for display context
FAQ
- [x] Yes, my issue is not about variability or throttling.
- [x] Yes, my issue is not about a specific accessibility audit (file with axe-core instead).
- [x] Yes, my issue is not answered by other FAQs.
URL
https://pagespeed.web.dev/analysis/https-checkmatefire-staging-ledgardjepson-net/hwnevlfqhj?form_factor=desktop
What happened?
Both Lighthouse and PageSpeed insights are flagging hero images that are correctly sized as being incorrectly sized when looking at "desktop device" audit results.
Go to: Pagespeed insights > analyze: https://checkmatefire.staging.ledgardjepson.net > Desktop tab > click "Try insights" > Unfurl "Improve image delivery" insights > we see:
This image file is larger than it needs to be (1440x600) for its displayed dimensions (1335x556). Use responsive images to reduce the image download size.
Firstly, the actual flagged image size is already very close to the display dimensions mentioned, AFAIK it's within the threshold (image is 25% larger or smaller than it's current display context) to not be flagged for being incorrectly sized for the display context.
Secondly, this flagged image size is already part of a Responsive image pattern that supplies a range of image sizes, of which the browser should be choosing the most suitable for the display context anyway. Namely 1170w, 1300w and 1440w within the desktop image's <source> tag.
We have used this exact hero image pattern for a long time and not seen this flagged before, as recent as 3 weeks ago it was not being flagged during the same test, so I believe this might be a newly introduced bug.
What did you expect?
The images to not be flagged for being too large as they are already close to the display dimensions
What have you tried?
Double checked the responsive image pattern
How were you running Lighthouse?
PageSpeed Insights
Lighthouse Version
Lighthouse 12.6.0
Chrome Version
Version 138.0.7204.51
Node Version
No response
OS
MacOS
Relevant log output
This is resolved with 12.7.0. I checked your site and am not seeing this issue anymore.
12.7.0 may not be fully deployed for everyone to PageSpeed Insights yet, but it should be soon.
@connorjclark thanks for the speedy response.
I just ran a test again (on the new URL, as we have now gone live), this time it used lighthouse 12.7.1, but i see the same issue: https://pagespeed.web.dev/analysis/https-checkmatefire-com/6k7ia8xvhz?form_factor=desktop
I'm also quite surprised and intrigued that our audit result scores seem very different, especially LCP.
I'm encountering this same bug (or one very much like it) on a just-launched site (www.ijm.org). The report is claiming "This image file is larger than it needs to be (960x960) for its displayed dimensions (380x380). Use responsive images to reduce the image download size."
On the face of it, that seems true—but it ain't, because this is the Mobile test, which uses an "Emulated Moto G Power with Lighthouse 12.8.2" with these stats:
Unthrottled CPU/Memory Power: 916
CPU throttling: 1.2x slowdown (Simulated)
Screen emulation: 412x823, DPR 1.75
Axe version: 4.10.3
So due to the DPR and the sizes attribute (seen below, but basically: 100vw at a 412px-wide viewport), the browser is properly requesting an image that is at least 412 x 1.75 = 721px wide. Given the available sizes, 640px is too small, so selecting 960px is correct and proper.
Here's the full responsive image code for the image in question (generated by the CMS, so I've removed a bunch of whitespace characters; hopefully they aren't what's tripping things up! 😆):
<picture class="flex overflow-hidden relative has-lqip" style="--aspect-ratio: 1;">
<source type="image/webp" srcset="
/cdn-cgi/image/width=320,height=320,gravity=0.5x0.5,fit=cover,format=webp/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg 320w,
/cdn-cgi/image/width=640,height=640,gravity=0.5x0.5,fit=cover,format=webp/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg 640w,
/cdn-cgi/image/width=960,height=960,gravity=0.5x0.5,fit=cover,format=webp/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg 960w,
/cdn-cgi/image/width=1280,height=1280,gravity=0.5x0.5,fit=cover,format=webp/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg 1280w,
/cdn-cgi/image/width=1600,height=1600,gravity=0.5x0.5,fit=cover,format=webp/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg 1600w,
/cdn-cgi/image/width=1920,height=1920,gravity=0.5x0.5,fit=cover,format=webp/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg 1920w,
/cdn-cgi/image/width=2240,height=2240,gravity=0.5x0.5,fit=cover,format=webp/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg 2240w,
/cdn-cgi/image/width=2560,height=2560,gravity=0.5x0.5,fit=cover,format=webp/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg 2560w"
sizes="(min-width: 1330px) 302px, (min-width: 800px) 25vw, (min-width: 480px) 50vw, 100vw">
<source type="image/jpeg" srcset="
/cdn-cgi/image/width=320,height=320,gravity=0.5x0.5,fit=cover,format=auto/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg 320w,
/cdn-cgi/image/width=640,height=640,gravity=0.5x0.5,fit=cover,format=auto/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg 640w,
/cdn-cgi/image/width=960,height=960,gravity=0.5x0.5,fit=cover,format=auto/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg 960w,
/cdn-cgi/image/width=1280,height=1280,gravity=0.5x0.5,fit=cover,format=auto/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg 1280w,
/cdn-cgi/image/width=1600,height=1600,gravity=0.5x0.5,fit=cover,format=auto/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg 1600w,
/cdn-cgi/image/width=1920,height=1920,gravity=0.5x0.5,fit=cover,format=auto/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg 1920w,
/cdn-cgi/image/width=2240,height=2240,gravity=0.5x0.5,fit=cover,format=auto/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg 2240w,
/cdn-cgi/image/width=2560,height=2560,gravity=0.5x0.5,fit=cover,format=auto/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg 2560w"
sizes="(min-width: 1330px) 302px, (min-width: 800px) 25vw, (min-width: 480px) 50vw, 100vw">
<img class="peer loaded" src="/cdn-cgi/image/width=1280,height=1280,gravity=0.5x0.5,fit=cover/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg" width="1280" height="1280" alt="202405 BGD Garys Trip Stock Photo 24 jpg 202405 BGD Garys Trip Approved for Full Use" onload="this.classList.add('loaded')">
<div class="lqip absolute block top-0 left-0 w-full h-full overflow-hidden bg-no-repeat bg-cover bg-center opacity-100 transition-opacity transition-discrete duration-700 ease-in-out after:content-[""] after:absolute after:top-0 after:left-0 after:w-full after:h-full after:backdrop-blur-xl peer-[.loaded]:opacity-0 peer-[.loaded]:pointer-events-none" style="background-image: url('/cdn-cgi/image/width=5,quality=10,fit=cover/https://assets-na.ijm.org/images/News/202405BGD_GarysTrip_StockPhoto-24.jpg_202405BGD_Garys-Trip_Approved-for-Full-Use.jpg');"></div>
</picture>
I don't understand why Lighthouse is penalizing for this, or pretending that the image would be rendered at its displayed dimensions of 380px on a 1.75 DPR screen!
To double-check, I prepared an image test page: https://www.ijm.org/dynamic/my-image-test There, I've optimized the sizes attribute to be more accurate (93vw instead of 100vw on small screens), and customized the image sizes being generated to match. The image displays at 380px in a 412px-wide viewport, on a 1.75 DPR screen, so 412 * 0.93 * 1.75 = 670.53. The closest available image sizes provided in this test case are 640, 671, and 720. PageSpeed Insights correctly uses the 671px image, and complains about it: "This image file is larger than it needs to be (671x687) for its displayed dimensions (380x389). Use responsive images to reduce the image download size."
For all intents and purposes, it seems like errors and performance penalties are being applied in situations where the DPR is being used to fetch the right image, and then ignored when evaluating the suitability of the fetched image. 🤦
Glad to see someone else has managed to reproduce this. Resolution for this bug seems to have been abandoned
@connorjclark Could you please clarify one thing for me?
In the code where Lighthouse checks if an image has the correct size, it compares naturalWidth with the expected width.
For example, let’s say I have an image that is 300px wide, with sizes="100vw". This makes its naturalWidth also 300px.
displayedWidth = 300px
naturalWidth = 300px
DPR = 1.5
The browser will then look for an image with a width of 300 * 1.5 = 450px in the srcset. If a 450px image exists, the browser fetches it for devices with DPR 1.5.
However, Lighthouse still shows a warning because it compares naturalWidth (300px) with the expected width, calculated as:
displayedWidth * LARGE_IMAGE_FACTOR * DPR
= 300 * 0.75 * 1.5
= 337.5px
Since 337.5 is always greater than the naturalWidth of 300, I end up receiving the “improve image delivery” warning no matter what I do.
If I increase the naturalWidth of the image, the browser will fetch a larger image than 450px, which reduces performance but suppresses the Lighthouse warning.
@connorjclark Am I missing something here? Why doesn’t Lighthouse multiply naturalWidth by the DPR when checking whether an image has the correct size?
Bump on this one, same issue here.
We have srcset="image.webp x1, image2x.webp x2"
and lighthouse complains that image is too big, is should be 2x smaller.
I’m also running into this exact problem.
Lighthouse is flagging correctly sized responsive images as “too large”, even though the browser is intentionally picking a bigger resource because of DPR and the sizes calculation.
In my case:
- Container is ~288px wide
- DPR ≈ 1.8
- Browser correctly chooses an image around ~520px
- But Lighthouse compares the displayed CSS size instead of the DPR-adjusted rendered size and reports:
“Image (530x654) is larger than displayed size (288x357)”, which is technically wrong, because the effective rendered pixel size is ~518px.
As a result, any layout with srcset + sizes + high DPR devices gets falsely flagged, even though the browser is selecting the optimal resource.
This looks identical to the behavior described above - Lighthouse ignores DPR when validating the image size.
Currently it’s impossible to avoid this warning on real high-DPR devices with correct responsive images.
