Adam Silverstein 1:45 pm on April 12, 2022
Tags: core-images ( 9 ), media ( 90 ), performance ( 306 )

Follow-up on WebP by default proposal

This post is a follow up to last month’s Enabling WebP by default, which proposed a feature that would generate both JPEG and WebP images and output WebP sub-sized images in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. The post received quite a bit of feedback, primarily in regards to technical concerns questioning if this feature should be included in core in its current state.

TL;DR – The performance team has heard the feedback and takes the community’s concerns seriously. With the help of the community, we will work on conducting additional data-driven research. Based on our findings, we will reassess our proposed approach to enabling WebP by default.

The performance team wants to see WordPress continue to innovate and improve. The main goal of this feature is to set the foundation for WordPress to be able to process and deliver more performant formats in the same way other CMS like Duda, Wix, and Shopify are already doing.

To ensure that we’re implementing this feature as effectively as possible, we will investigate the main points of concern that have been raised within the community, including continuing our research and testing on image size & quality. We will continue to share updates about our work as part of the weekly chat summaries posted to the Make Core blogblog (versus network, site).

In addition, we’ve created two issues in the Performance Lab GitHub repository for tracking analysis related to the main concerns raised by the community:

Research: Impact of additional WebP images on upload [Issue #289]
Research: WebP compatibility [Issue #290]

Within these GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issues, the performance team will track testing and investigation related to these concerns to ensure that we have a full and data-driven picture of this feature’s impact. Please feel free to share your own research in these GitHub issues, as well.

Once we’ve completed our investigation and determined next steps on these two issues, we will work with the community to reassess two other concerns that were raised:

Having the feature on/off by default
Having a UIUI User interface-based control to turn the feature on/off

Thank you all for your feedback so far. We look forward to continuing to collaborate to move this proposal forward.

Many thanks to @tweetythierry, @flixos90, @mitogh, @mxbclang, and @jjgrainger for their help with this post.

#core-images, #media, #performance

jeffpaul 2:28 pm on April 12, 2022

Thanks for the update @adamsilverstein, as always you’ve handled the feedback from the prior post most graciously and I look forward to what the Performance team learns in this additional testing and research and appreciate all the efforts to ensure WordPress is forward-thinking and competitive in the CMS space.
Feast Design Co. 3:29 pm on April 12, 2022

Thanks @adamsilverstein for listening to the feedback and taking the concerns seriously. Particularly the disk space issue, and quantity of files being generated and their impact on hosting stability as well as backup systems.
Aaron Jorbin 4:15 pm on April 12, 2022

Having the feature on/off by default
Having a UIUI User interface-based control to turn the feature on/off

I really hope the next proposal isn’t one that violates the existing WordPress Philosophies. If this is the correct move for the majority of users, it should be done even if a vocal minority is against it.
Jon Brown 5:21 pm on April 12, 2022

Thank you @adamsilverstein. Well summarized.

I want to reiterate I think most want to see WebP and other modern formats (ie. AVIF) generation and handed by coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

Personally, I just really just have an issue with WebP generation being rolled out “on” by default for existing images. That’s a massive unexpected CPU hit to existing sites (even if done on the background/cron) and a massive unexpected storage increase as well.

In that vein I wanted to bring up something, not in the summary. There were several people who echoed that we’d rather see the issue of pre-generating thumbnails needlessly addressed prior to something like WebP in core. If thumbnails could be generated on-demand and saved to disk only in the sizes needed (which out to happen for existing JPEGs too) then we’d go a long way to avoiding CPU and Storage bloat multiple formats would cause.

@jorbin – I think there is a point of view issue here. I agree WebP generation in core would benefit the majority, but I also think that the same majority would be harmed by WebP generation on by default on existing sites because it will cause unseen impacts that they aren’t equipped to understand or mitigate.
- Felipe Lavín 11:22 pm on April 13, 2022
  
  +1 for this; I think it’s a very important point… I’m partial to some kind of background processing (which would be a great concept to add into code, as well), but I must admit that on-demand also has some interesting merits (like, no need to regenerate previous sizes on theme switch).
LewisCowles 5:25 pm on April 12, 2022

There is no point in this being included and on by default.

By all means allow for upload, and if you feel bored, include a feature so that people can have their media turned into these formats, but please make it togglable.

Some of the additional features are really not needed, and at the least need a way to disable; even if by hook and not UIUI User interface.
Andrew Wilder 11:20 pm on April 12, 2022

Thank you, @adamsilverstein and the rest of the performance team for taking all the feedback so seriously. I was alarmed at how quickly this appeared to be moving, and am grateful that we’re taking a step back to re-evaluate and figure out the best path forward for everyone’s sites.

Fundamentally the concerns raised about the current proposal primarily stem from the fact that it’s a “band-aid” on top of the existing way WordPress handles images, especially generating so many thumbnails (most of which likely go unused). Because of that, we’re stuck with compromises and tradeoffs.

It would be helpful to apply “First Principles” thinking here and ask, If we were starting completely from scratch, what would be the best way to approach images and thumbnails? Could we build a more nimble and less brittle system that can adapt more easily to new formats now, and in the future? What would that look like?
Maybe thumbnails can be generated as-needed, “just in time” or “on demand”? Could they be easy to manage (and convert formats or delete old thumbs) from the dashboard? Could thumbnails auto-expire after a set amount of time, and then be recreated next time they’re requested, like a cache?

Seems to me that this is inextricably linked to this performance proposal. I know it’s pushing the limits of the scope of the Performance team, but if we can improve how WordPress handles images/thumbnails, then it can be much more flexible — generating WebP, AVIF, or whatever else better comes along in the future, without doubling down on the existing technical debt.

I know the above is incredibly challenging to fix, and maybe even impossible considering the legacy issues… but I’m also really excited to think that maybe this is the moment to finally fix this in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.? 🙂
- anoopd 4:17 am on June 13, 2022
  
  I would second this , as i have found almost all autogenerated thumbnails are left unused for the whole site life-span , should think about overhauling the image handling process while embracing the future concepts .
webaware 11:04 am on April 13, 2022

I appreciate the work you and others are doing here. I still maintain that if it becomes part of coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., it should not be “on” by default, for the reasons you’ve mentioned above and also:

Cloudflare free tier does not support the Vary: Accept headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.. Their blog has a post announcing support for this header, but expressly says you need a paid account to access that support (and need to enable it via their APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.). Many people use the free tier of Cloudflare.

WebP lossy compression can totally ruin some images, due to colour compression. By default its chroma subsampling can mess up subtle gradients, producing ring effects and incorrect colour translations. There are options to correct that, but they reduce the compression benefit of using WebP versus a good JPEG compression such as MozJPEG.

When considering incorporating WebP into core as a default, these issues cannot be ignored. The Cloudflare problem has the potential to break image delivery for websites, and the colour compression issue has the potential to ruin carefully curated images on photographic and artistic websites.

I say this as a big fan of the WebP format, but knowing its limitations.
- Erik 8:24 pm on April 13, 2022
  @webaware can I ask you two clarifications?
  - What is the vary headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. for? and why?
  - Why do you say that webp has destructive color compression? it is better than jpeg, could you give me an example of an image with a gradient where you encountered this issue? this is a problem that i knew existed in jpegs that have been saved multiple times at different qualities. Curious about that because YUV 4:2:0 is a standard for all the compressed formats of the web.
  - webaware 1:59 am on April 14, 2022
    
    When a server can supply different content for the same URI, depending on the Accept headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. in the request, it should send the Vary: Accept header so that caches can differentiate between them. Cloudflare is a caching proxy server, so it will cache images returned from the origin server — and if the first image into its cache is a WebP version of a JPEG, that’s what it will serve up to all following requests while the image is in its cache. When Vary: Accept is enabled, it will look at the Accept header in the browser request and cache JPEGs separately to WebPs. Otherwise, the first request determines what is cached for all requests (whether they accept WebP or not).
    
    I wracked my brains and found an example image that naive conversion to WebP breaks. I used cwebp to convert from JPEG to WebP at quality 85. For comparison, I’ve added a near_lossless conversion and a MozJPEG optimised image.
    
    https://webaware.net.au/examples/webp/index.html
    
    Here’s a couple of other people who have issues with WebP fidelity.
    
    https://meow.pro/meow/colour-banding-of-webp-avif/
    https://eng.aurelienpierre.com/2021/10/webp-is-so-great-except-its-not/
    - Erik 10:05 am on April 14, 2022
      
      @webaware, i believe the headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. vary it is needed when the content of the page is served based on your request header “accept”. The way it is used with webp is this: https://modul-r.codekraft.it/2021/09/how-to-serve-automatically-webp-images-with-nginx/
      but can’t figure how it can be used with the performance pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party since the response doesn’t change depending on headers and the webp image is served in the same way a jpg was.
      
      Thank you for having found the jpg image (even to me after the conversion comes a crap), I guess the reason was that image has been saved multiple times into jpg format (the lower one < 10%) that's why conflicts with webp blocking. I will do more tests with this one as soon as I have a free time, have you also the original uncompressed one?
      What otto said here is always right, and what hasn’t been clearly said here yet is that you should never use a jpg to make another one, what results is a photocopy of a photocopy (and so on to infinity). Every time we re-save a jpg we introduce new artifacts that builds up to the previous ones but this one (this regardless of the compressed format we are using).
      
      The examples you linked are slightly different… the issue mentioned is the dithering but this happens also in photoshop if you don’t have a 10-bit monitor but I don’t think you can achieve this with compressed formats that are not meant for this due chroma subsampling!
      - webaware 10:27 am on April 14, 2022
        
        When serving WebP versions of uploaded images, it’s a good idea to always offer the original format (JPEG, PNG) for visitors that cannot consume WebP. Using the Accept headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. to determine what they can receive is best except when it doesn’t work, as is the case with the free Cloudflare tier. Picture elements work everywhere, but enforcing picture elements can be problematic because some themes expect image elements to be direct children of certain containers such as figure elements. Some optimisation plugins use JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. to set the image at runtime in the browser, which works as long as there’s no JavaScript errors for any reason.
        
        The example image I gave is as delivered to me by a graphic designer. cwebp with near_lossless and mozjpeg both maintained good fidelity when processing it, but cwebp in default mode really ruined it — and that’s what you can expect with an always-on optimisation in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Most images will be fine, but some with totally fall apart.
        
        The linked blogblog (versus network, site) posts demonstrate that JPEG can deliver clean images where WebP fails. No big deal for a low-end WooCommerce site selling T-shirts but a big deal for photographers and artists.
        
        I will say again, I am actually a fan of WebP, especially for photographic images with transparency. But WebP could be a nasty surprise for many site owners, for a variety of reasons, and thus should not be default-on.
        
        Anmol 4:47 pm on May 24, 2022
        
        Can Anyone tell me how i make slider on Hindi Talks
webbeetle 2:40 am on April 18, 2022

I strongly urge the developers to provide a simple (and easily accessible) on/off switch for WebP images!

I had experimented with WebP for my own site about 2 years ago and never experienced any significant speed advantage from this format (because I thoroughly optimise my images before I upload them).

WebP still isn’t suitable for every kind of image and therefor a fallback needs to be implemented, fallback jpeg images, which then drastically increases storage demands and the size of backups – to the point that they become unworkable (my Updraft backup uploads to remote location started to fail once my database became too big)!

I for one really don’t want WebP as a default format! And I own an image heavy website…
davidordave 9:46 pm on May 23, 2022

I agree – do not force this change on us! We demand the option to turn this “feature” on only if we want it via an easily accessible UIUI User interface control. The customer is always right. Listen – do not ignore us!

Comments are closed.

Welcome!

Communication

Follow-up on WebP by default proposal

Welcome!

Communication

Share this: