Plan for adding WebP & multiple MIME support for images

This post is a follow up to the “Enabling WebP by default” proposal post (and the follow up to that post). 

TL;DR – The Performance Team has reviewed feedback, conducted research, and reassessed the approach based on our findings. Our new approach – outlined below – aims to address the concerns raised on the original proposal.

Overview

The Performance Team takes community feedback very seriously. As a result of the concerns around our previously proposed approach to serving WebP, we took a step back to reassess and dig deeper into the specific issues raised in post comments, chat, and elsewhere. This work has included:

• Reviewing comments from the original and follow-up posts
• Engaging in research (as noted in #289 & #290) on the storage impact of additional WebP images being created on upload and WebP compatibility across browsers, email clients, etc.
• Sharing a survey with hosting providers to gather information about their storage and disk space infrastructure

What we found

Our goal with this research and reassessment was to collect data and additional context about each of the concerns raised by the community. With this additional information, we were then able to better understand and prioritize concerns, as well as determine how and why our approach to adding WebP should be modified.

WebP Compatibility

The team did additional research on WebP compatibility to better understand where compatibility issues might cause issues for users. Our research indicated that most compatibility issues were very minor and/or addressable:

• Web browser compatibility: Only Safari on Mac OS < 11 and iOS < 14 do not support WebP, which is < 3% of all browser usage. This small percentage of non-supporting browsers will be served JPEG images.
• Email clients: > 97% of clients support WebP.
• Mobile apps (web views): iOS 14+ supports WebP (and otherwise will be served JPEG images with the new approach). Android supports WebP natively from Android 4.0.
• RSS readers: Top RSS readers all support WebP, so RSS feeds can likely leverage WebP.
• Other: Open Graph tag consumers have mixed support, so OG tags should remain JPEGs for compatibility.

Storage

To assess the overall impact of generating WebP images on site storage, the team surveyed hosting providers. With a total of 17 responses, the results show that the number of stored files is generally not an issue for most hosts/sites, although storage space could become an issue for some users over time. Still, for large hosts (with 1,000 or more hosted sites), the vast majority of sites (> 86%) would be unaffected, even if their storage requirements doubled. We also learned that some lower-end hosting plans with limited storage also lack WebP support in their hosting stack, which means they won’t get extra image generation anyway.

The revised approach

Based on the results of the research outlined above, our new proposed approach addresses compatibility issues by:

• Providing a tiny (355 bytes uncompressed) JavaScript snippet that detects browsers that lack WebP support and loads JPEGs instead [tracking issue]
• Only using WebP for user-facing content in the front-end (template) context. Images in other contexts like Open Graph tags, RSS feeds, and REST endpoints would continue to use JPEGs [tracking issue]
• Adding a new parameter to the `add_image_size()` function that lets developers control whether to generate additional MIME types for each size registered. For the vast majority of image sizes this should be set to `true`; the only exceptions are image sizes that are being used exclusively outside of user-facing front-end content, such as Open Graph tags. Only for those special cases should the parameter be set to `false` to not generate additional MIME types. Developers registering custom image sizes with `add_image_size` will need to specify if the size should generate secondary MIME types by version 6.2, when we plan to make this behavior the default in core.

This new approach also addresses concerns around storage requirements by:

• Automatically generating WebP versions of only core image sizes in 6.1 by default. Custom image sizes will initially have to opt in to receive automatically generated WebP versions, or opt out if they are exclusively used for special cases where WebP is not beneficial or supported.
• Keeping secondary (WebP) sub-sizes only if they are smaller than the primary MIME type.
• Only generating WebP images for image sizes that are intended for use in user-facing front-end content. This avoids wasting storage space for WebP images that will never be used.
• Introducing a filter to control the generation of additional MIME types based on image sub-sizes. This enables developers to exclude certain image sizes, such as those that are not used in front-end content.

Next Steps

The approach in the core patch is being updated to reflect the revisions outlined above. The current plan is to merge this change early in the 6.1 release cycle so that it can be thoroughly tested. Additional feedback regarding this revised approach can be left on this post or the Trac ticket.

#core-images, #media, #performance