As outlined in #186 (comment), there is a flaw with the current approach of choosing the smaller image MIME file in frontend content:
- The current implementation only looks at the
full image and decides based on that which MIME type should be preferred.
- But what if e.g. for most image sizes (including
full) the WebP image is smaller, but for e.g. thumbnail the JPEG image is smaller? The current implementation would still always use WebP in that scenario, but it would be better to use JPEG for the thumbnail size.
- So I'm thinking maybe we need to enhance this to more deeply integrate into the replacement logic, per image size, rather than the overall MIME types filter.
While attaching the webp_uploads_get_mime_types_by_filesize() function to the webp_uploads_content_image_mimes filter seems elegant, I think this is the wrong integration point here. It's not sufficient to universally choose a preferred MIME type based on the full image size. We have to instead modify webp_uploads_img_tag_update_mime_type() directly and make this check for every image size individually.
As outlined in #186 (comment), there is a flaw with the current approach of choosing the smaller image MIME file in frontend content:
While attaching the
webp_uploads_get_mime_types_by_filesize()function to thewebp_uploads_content_image_mimesfilter seems elegant, I think this is the wrong integration point here. It's not sufficient to universally choose a preferred MIME type based on thefullimage size. We have to instead modifywebp_uploads_img_tag_update_mime_type()directly and make this check for every image size individually.