A new proposal by the performance team opened up the idea of loading WebP images by default across all WordPress sites. The idea stoked a lot of debate last week as contributors and users discussed the possible good and bad side effects of what would be the biggest front-end change to media since responsive images arrived in WordPress 4.4. Since announcing the proposal, the team has since decided to step back, do more research, and collect more feedback from the community. We’re going to quickly breakdown what WebP images are and how this change would affect end users.
What are WebP images?
Developed/acquired by Google over a decade ago, WebP is an image format that is meant as a smaller, quicker alternative to both PNG and JPEG image files. Whether or not WebP is always a smaller file remains to be seen, but overall, the image format has seen its popularity increase, mainly due to WebP’s inclusion as a recommended metric in Google’s Pagespeed Insights tool.
I’ve written previously about the Performance Team and Google’s heavy-handed support as a method of pushing the direction of the WordPress project. Whether good or bad, this is another example of how even open source projects are ultimately subject to the incumbent tech giants who have the resources to contribute to them. On the whole, though, WebP is certainly a less pernicious feature to support than previous ideas from Google (remember AMP?).
It’s important to note that WordPress has offered support for uploading WebP images since 5.8. What’s being discussed here is whether WordPress should automatically convert your JPEGs (and eventually PNGs) into WebP images when you upload them. Then WordPress would dynamically serve the correct filetype to your audience. This key distinction is important for understanding why this discussion has such high stakes.
The Case for WebP
The basic selling point here is that WebP images are smaller and faster, and thus use less bandwidth. You’re decreasing the amount of data being moved across the internet, and every little bit helps speed up your website and ultimately decrease the energy usage of the web as a whole. What may be a small change on one website could have huge ramifications across 43% of the web.
Currently, the two most popular image formats serve different use cases. JPEGs are great for photography. They capture the wide color palettes and general details of real life. They can be compressed much further than PNGs, but also lose a lot of detail along the way. PNGs on the other hand are great for artwork, graphic design, and logo images. They don’t lose detail as they’re compressed, meaning they often can’t get as small as JPEGs, but they also offer transparency, so you can let background colors show through a PNG image.
WebP is meant to combine the best of both image types, from great compression to transparency. As WebP images gain even more browser support, fewer roadblocks exist and arguments in their favor continues to grow.
The Case Against WebP
The primary argument against loading WebP images by default is whether the compression is actually helpful or even useful for most images. While WebP appears to be a lot smaller than PNG files on average, it’s not always the case for JPEGs, or at least the gains are sometimes marginal. To make matters worse, converting PNGs to WebP is actually a lot harder, and may not be possible on most popular web hosts as they’re currently configured.
However, the next big complaint – the total effect on server storage usage – comes in as a very close second. When you upload an image to WordPress, the CMS actually creates a number of copies of that image in your /uploads/ folder. For example, one “full size” image will be duplicated, compressed, and cropped into a “large” size, a “medium”, and a “thumbnail” version. And that’s assuming your active theme isn’t also creating other sized images as well. Overall, the multiple sizes are great for archive templates or responsive images, where WordPress can serve a smaller image file for mobile browsers.
However, add another file format to the list, and we’re essentially doubling the size of every user’s uploads folder overnight. For users on budget hosts with limited server space, or really any user running a media-rich site, this could immediately turn into an additional cost before a user would even have the relevant information and tools necessary to opt out.
Finally, others have concerns about potential changes to the actual mark-up of their websites. Many other iterations of WebP support actually altered the markup of the page, causing issues with CSS styles not being loaded correctly. For example, instead of a basic <img> tag, plugins like Imagify would use the more modern <picture> tag to wrap the output of the WebP image and provide fallbacks. Any styles scoped to that <img> tag, however, would break, causing funky frontend styles.
These days, browser support is wide enough that we’re seeing the .webp extension appear directly in <img> tags, so this is becoming less of an issue and, from what I understand, wouldn’t apply to this implementation.
So, should WordPress start converting your images to WebP?
This is a tricky situation, and I’m not sure there’s a right answer. Both sides make a decent argument.
The first suggestion by most is that this should be an opt-in feature. The reality is that we have a method for opt-in features – they’re called Plugins. I’m a huge fan of Decisions, not Options: if something needs to be opted-into, then it doesn’t need to be in core. I’m actually a proponent of offering a suite of “core plugins” that are supported, even pre-installed, but never actually merged. The precedent here exists in the form of BuddyPress, BBPress, Akismet, and that “must-have” plugin, Hello Dolly.
But the discussion here is about inclusion into core. WordPress contributor “Otto” makes his case against it very clearly:
If I upload an image, then I have made that image, chosen how it looks, taken steps to optimize it. I chose the format to use. I chose everything about it. […] So when I decide what to do, then WordPress does not get to second guess my decisions.
Samuel Wood (Otto)
Unfortunately, I think we’re well past the point of WordPress simply rendering the content as we entered it (see: responsive images, block editing, capital_P_dangit, etc.), but I do agree with the sentiment. Messing around with image formats feels one step removed from what should really be inside of WordPress core. Increasing the space used on hosting servers may limit bandwidth in the long-run, but for 99% of WordPress sites with relatively low traffic, it probably will be about a wash.
Instead, I’d love to see less efforts from Google to push their software and ideology into WordPress core. There’s nothing wrong with WebP specifically, but WordPress already supports it without forcing it on users. If WebP is going to be the next big image format, then we continue to allow users to upload WebP images instead of just generating them automatically.
