Expected Image Size is incorrect #10802
Comments
|
This is the intended behavior of the best practice audit @tmb-github. The audit is advocating for true responsive images that when a client requests a high DPR image, they receive one. |
|
Using Chromium Version 81.0.4044.138 (openSUSE Build) (64-bit). openSuse Leap 15.2 I am experiencing a similar problem. I am loading a total of 17 images. Lighthouse is flagging just 2 of the images with the same error. The sizes specified in html, the displayed size and actual size are correct. Yet, Lighthouse is expecting something else. They are as follows: Image size is 44x44. Lighthouse is expecting 116x116. I'm not sure where Lighthouse is getting the expected size information. It is possible that the image metadata is incorrect? |
|
@medicalspanw It's expecting you to supply additional images using the srcset attribute. You'll have to consider not just the width of various display devices, but the DPR (Device Pixel Ratio), which is a multiplier. A device with a DPR of 2 will want images at twice the effective size specified by the HTML and/or CSS; a device with a DPR of 3 will want images at three times the effective size, etc. |
|
@tmb-github I have the same problem, and I do provide the Specifically, Lighthouse reports that the FWIW, here is the failing HTML: |
I'm running into the same problem. Did you find an answer to this? |
|
@dixonge If the page in question is at https://www.technicallywizardry.com/diy-dashcam-raspberry-pi-zero-w-motion-eye, I can't reproduce the error in LightHouse, either in the current Chrome or in Chrome Canary. But as I last wrote, the issue is that you must take the DPR of the device being tested into consideration. If the image will be sized by the CSS to be 100x200px, and the DPR of the device is 3, then the browser will expect a 300x600px image to be available. You'll have to identify the image in question, find it in the DOM display in DevTools, hover over the element in the DOM display, and the effective size will be revealed. If it's 50x75 and the DPR is 2.5. then you'll need a 125x187.5 (rounded to 125x188) image in the srcset. Determine the DPR by examining the mobile device used by Lighthouse in the audit, currently Moto G4. which has a DPR of 3.0. |
No, that's not a page I am familiar with... My site is vagabondians.com - on that, the Moto G4 is expecting that my header background of 960x110 (which I really want to be much smaller) should be sent over as 2880x330 !!! That is much larger than any image I want to send to a mobile device. It would kill my Lighthouse speed scores. I don't even have an original header image that size. It would just be a blurry blob that would take up the entire 'before the fold' part of the screen. |
|
@dixonge I see, you were quoting @zaneclaes , who had reproduced his Looking at your page while displaying it on a Moto G4, I now see what you're confronting. If you select the element for inspection in the DOM display in DevTools, and also look at its rendered size in the computed styles display (the one with the box model), your HTML and CSS work together to tell the browser that the size of the element is 960x110. If it should be less than that on mobile, you'll need to look at your CSS to determine how it's computing that size. The DOM inspector doesn't lie: something about your CSS rules is indicating that that is the rendered size, and you'll have to analyze the CSS to get to the bottom of it and revise it. That's step 1. Step 2 is understanding the DPR of mobile devices. The Moto G4 has a DPR of 3.0. That means that if the rendered size of an image is 100x100 (following the sizing calculations of the CSS that affects it), the Moto G4 will want a 300x300 image to use for display. You multiply the rendered size by the DPR to determine the size that should be present in your srcset. Liighthouse offers a little bit of wiggle room there, and if you look at the JS for its routine, you can find out by how many pixels or by what percent greater it will accept a size that you offer in the srcset. But you should target the size that the Moto G4 expects in this case if you want to please Lighthouse. And in the case of that image, because the CSS indicates to the browser that the rendered size is 960x110, then the Moto G4 expects an image 3 times as large, 2880x330. The main issue here would seem to be your CSS. You'll have to explore the interaction of the style rules not just affecting the image itself, but all of its containers to determine why it expects 960x110 instead of a smaller size when on a smaller device. (Are you not using @media queries in your CSS?) (Actually, looking at DOM of your page in DevTools, I can't see you have any CSS that's affecting that element. The lack of CSS affecting it may be the root of the problem.) |
|
In addition to the great explanations @tmb-github is offering I just wanted to let folks know that in later versions of Lighthouse we reduced the suggestion of this high DPI images audit to a max of 2x. We agree a 3x DPR offers minimal value on mobile and is not worth the byte cost. |
|
I eventually tracked my issue down to this bug with the imagesloaded script, which is included by default on Wordpress. I corrected it by forcibly dequeuing the script in a WP hook. |
|
@patrickhulce Off-topic re: images and DPR, but could the throttling options once present in Lighthouse be restored? At present, the hard-wired throttling option is a bit draconian (especially the 4x CPU slowdown...what percent of mobile devices are affected by that kind of throttling? The desirability of things to load quickly at different throttling rates may be market-dependent, e.g., the Mercedez-Benz website may have no need to worry about that, but a charitable organization aiming to help disenfranchised people directly may wisely want to accommodate a slower connection and device speed.) |
|
@patrickhulce On topic re: image sizes. Instead of testing whether a site has images that meet the demands of one device (with its specific screen size and DPR pitted against the srcset images on the site being tested), why not simply test whether (1) the site is using srcset for its images, and (2) if the srcset sizes are in a decent spread of size values? A webmaster might factor a lot of things to determine which sizes to include, including demographic information on possible users, and include 6 or more images per My own site has hundreds of images, and when the Lighthouse audit switched to the Moto G4 (and the PageSpeed audit switched to whichever device it's now using), I had to create hundreds of new images and rework my Reading that Lighthouse would once again be switching test devices, from a 3.0 DPR to a 2.0 DPR, is chilling: it means the game of whack-a-mole will continue with the So, rather than test for a specific device, why not look at the range of sizes provided, and see if the spread that's present there seems sufficient? To be clear, I do not mean checking for a sequence of specific image sizes. Instead, I mean checking to see if the images in "spread" fit a predictable expansion pattern. For example, 360px. 580px, 768px, 960px. 1200px, 1600px would be a good spread, because there's a good distance between the smallest and the largest size (360px vs 1600px), and values in between follow a good expansion pattern. On the other hand, if the sequence were 360px, 380px, 400px, 420px, 440px, 1600px, then it would fail the test, because even though there's a good spread between the smallest and largest image (360px vs 1600px), the first five images are clustered around 400px, so the internal spread isn't good. Also, if the last value in this sequence were 480px and not 1600px, it would fail because there's not enough distance between 360px and 480px, even though the internal sequence would be a good spread. Would this not make sense as a better approach to testing image sizes? Wouldn't it be a better indicator that the page's images have been sized to meet the demands of a good sample of devices, rather than just one device? |
Simply put: because lots of pages use srcset incorrectly in a way that doesn't actually consider hidpi images and because manually verifying that these work as expected is not possible without fetching those other resources which Lighthouse is not willing to spend the time doing. Loading as a device that requires at least a 2x image and checking if a 2x image was loaded is the least obtrusive path to validating true responsive image usage.
This isn't what's happening. The test device is not changing, we just loosened the requirement that you deliver an image exactly matching the DPR to you must deliver at least a 2 DPR image if the device DPR is >=2.
Very sorry you had to do this! I'm betting this would have been prevented with the 2x consideration change we made. Apologies that it happened too late after your work had already been done.
It certainly sounds more comprehensive yes, but as this is not a high priority critical item to tell developers to deliver larger images, we're ok with only flagging the most basic failures of a single device and be fairly lenient there. If the current policy is still too strict in the latest version of Lighthouse, I'm happy to hear suggestions on how to further loosen it :) |
- was failing best practices lighthouse audit for "displaying images with inappropriate size" - expects true responsiveness, which includes providing high-DPR images when requested - GoogleChrome/lighthouse#10802
|
We are also getting knocked down on our scores for this issue when we provide a full src-set. You can see in the screen shot the two offending files. The file paths of our images include the dimensions being served and are clearly the correct size (a 4k monitor requesting 2x DPI) What would make this even easier to debug is if you could highlight which of the values is actually wrong? The actual size or expected size?
|
|
If you suspect a legit bug in this audit rather than what's described here, a new issue with a reproducible URL would be much appreciated :) |
|
I have filed #11838 as I feel it's actual bug. |
|
I have exactly the same issue. I have 4 teaser in one row. Each has on top an image. All sizes and the entire code is the same for each teaser.
URL: https://dlgo.de/111 |
|
For the images flagged on my site, providing 2x, 3x, copies would be pointless, as the images are computer-generated block graphics with no diagonals or gradients. A crude pixel stretch at 2x or 3x on the client will produce exactly the same perfectly crisp enlargement as if I provided wastefully larger versions. In this case, what I'm doing is better than the "best practice". I don't agree with this requirement, as trading off between media fidelity and "cost" in the form of bandwidth, storage, etc., will always be a judgement call by designers, developers and business managers. |
|
@stevefal we certainly don't want you to serve wasteful higher fidelity images in that situation. The best practice there is to use |
OS: Windows 8.1
Chrome: Version 85.0.4148.0 (Official Build) canary (64-bit)
Lighthouse Version: 6.0.0
Website: https://thomasbrodhead.com
In the Best Practices audit, using Mobile mode, Lighthouse reports:
The image is 115x35 in natural and display size, and yet Lighthouse multiplies the display size by the D.P.R. (3.0) of the new default Moto mobile device and (apparently) incorrectly concludes it should be 345x105 ( = 115x35 * 3).
This isn't a problem is the stable version of Chrome (Version 81.0.4044.138 (Official Build) (64-bit)), which does not complain about the image during the audit.
Steps to reproduce:
The text was updated successfully, but these errors were encountered: