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.
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.
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 The operating system used on iPhones and iPads. < 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 A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) consumers have mixed support, so OG tags should remain JPEGs for compatibility.
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:
- 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 Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
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 Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. 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.
The approach in the core patch is being updated to reflect the revisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. 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.