[wp-trac] [WordPress Trac] #57238: Criteria for Responsive Images of WebP: Preserve Alpha + Preserve Lossless + Smaller in size than original

[WordPress Trac]

#57238: Criteria for Responsive Images of WebP: Preserve Alpha + Preserve Lossless
+ Smaller in size than original
-----------------------------+------------------------------
 Reporter:  abitofmind       |       Owner:  adamsilverstein
     Type:  feature request  |      Status:  assigned
 Priority:  normal           |   Milestone:  Future Release
Component:  Media            |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:  performance
-----------------------------+------------------------------

Comment (by abitofmind):

 - Environment info attached.
 - Thanks for looking into 1 and 2.

 **File Size:** The HTML output provides a `srcset` and the web browser
 tries to get the smallest possible variant to saturate its needs. With the
 implicit assumption that a smaller image dimension is by tendency also
 smaller in file size. To fulfill the end goal: Consume as little network
 bandwidth as necessary for a fast loading time. There is no filesize
 stated per variant in the srcset b/c of that implicit assumption.
 Otherwise the srcset standard would probably have provided a means to
 indicate filesize-in-bytes per each img variant. Needing a little less of
 client-side image scaling (and hence RAM/GPU) may be a small benefit for
 low end devices, but negligible. **The main goal of Responsive Images is
 definitely asset loading speed**.  How to achieve that sized images are
 smaller in file size too?
   1. **Sophisticated:** By in depth analysis of perceptive quality in the
 input and then creating the output similarly too (but never higher)?
     - ❌ Certainly not in Core. Too sophisticated. There are plugins which
 send the images via API to external specialized SaaS, e.g.
 https://wordpress.org/plugins/wp-smushit/
   2. ** By best practises:** Which ensure that the sized versions are by
 tendency never larger than the input and have a certain agreed-upon
 quality level.
     - ✅ This is what I meant.
     - And if users reports an example where this is violated, then adapt
 the algorithm accordingly:
     - e.g. my discovery in comment:4
     - Or other example: When the input has a limited color set (color bits
 per pixel), also use that in the output, or else you will blow up the
 sized versions unnecessarily with no information gain.
     - Avoid adding unnecessary extra metadata (color profile, etc) or
 other chunks which are not present in the source.
     - And similar best practises.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57238#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform