New responsive images metrics proposal

[gmetais]

Hi, I'm thinking of adding some metrics and changing some others, to better address responsive images and the reality of screen sizes and resolutions.

Issues with the current implementation:

• imagesScaledDown is bugged on images with srcset/w and sizes attributes.
• some websites intentionally scale down images to better handle high resolution screens (almost all mobile devices now have high DPI screens)
• imagesScaledDown reports data url SVG images such as src="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 300 177'%3E%3C/svg%3E"
• there is this comment in domComplexity.js: TODO: move to a separate module

What I could do:

• Create a new imageScaling metrics group for the following metrics.
• Keep imagesWithoutDimensions.
• Change the way imagesScaledDown works:
  • only use natural{Dimensions} on simple non-responsive <img src=""> images to avoid the bug.
  • it might also work on <source> tags inside <picture>, I have to test it.
  • when on a srcset/w syntax, rather check which size was picked by the browser in the list.
  • don't report if the image is scaled down by less than 20% or 100px.
• Add an imageScaledUp metric to help detecting issues with visual quality:
  • same technical detection, but only report if the image display ratio is <1.5x and the screen ratio is >= 2x.
• Add an incorrectSizesParameter metric:
  • check if the sizes attribute matches the image display size on the page (with a 10% error margin)
  • report a missing sizes attribute on a srcset/w syntax
  • report a existing but useless sizes attribute on a srcset/x syntax
• Optional (or later): add a respImageSyntaxError metric:
  • parse the sizes attribute and report syntax errors
  • parse the srcset attribute and report syntax errors
  • parse the media query in <source> tags and report syntax errors
  • detect a missing <img> tag in <picture>, for old browsers
  • ...

Do you or anyone have more ideas? Are metric names correct?

Maybe this kind of image analysis could even be split into a separate Node module, just like what you did with analyze-css. It would allow to deeper analyze the image: Is it correctly compressed? Would it be lighter in a different format such as JPEG or PNG. What size would it be with WebP, JPEG-XR or AVIF new generation formats?

Analyzing CSS background images would be great too, but not that easy.

[macbre]

@gmetais, thanks for this improvements / new metrics ideas!

What I could do:

Please, do go ahead 🙂

Maybe this kind of image analysis could even be split into a separate Node module, just like what you did with analyze-css. It would allow to deeper analyze the image: Is it correctly compressed? Would it be lighter in a different format such as JPEG or PNG. What size would it be with WebP, JPEG-XR or AVIF new generation formats?

I second this idea.