WordPress / performance

Performance plugin from the WordPress Performance Group, which is a collection of standalone performance modules.
https://wordpress.org/plugins/performance-lab/
GNU General Public License v2.0
362 stars 98 forks source link

Consider also replacing JPEG images with WebP images in `img` tags controlled by code #523

Open felixarntz opened 2 years ago

felixarntz commented 2 years ago

Feature Description

Related to #155 (and raised again by PR #517): While it probably makes sense to add a MIME type parameter to the relevant image core functions as described in #155, this doesn't mean that we should rely solely on the plugin and theme developers to use WebP.

Since the current behavior is to replace JPEG images with WebP images in post content img tags, potentially we could also do the same in other img tags which would be used in the frontend. I think that this would fall under the same considerations, e.g. as long as it's purely within img tags, we should be fine since those are definitely user-facing HTML in the frontend, within the body. In other words, we could by default adjust the output of wp_get_attachment_image() (which outputs an img tag) but not the one of e.g. wp_get_attachment_image_src() or wp_get_attachment_image_url() (which only return URL etc., but not necessarily for use in an img tag).

Special cases where this is not desired already right now would have to unhook the content replacement filter, so if we added one more filter somewhere else, they would simply need to remove that too, so not a notable overhead.

Let's think about this.

felixarntz commented 2 years ago

@maheshwaghmare @mukeshpanchal27 @jjgrainger Paging you here for awareness, we can discuss further here. #517 has a potential implementation for this, if we decide to move forward with the idea.

jjgrainger commented 2 years ago

Thanks @felixarntz

I think this is something worth exploring as it could potentially solve other issues raised (#513 and #509). These are cases where users were expecting WebP to be updated across other parts of the site, such as archive pages and other templates, which do not as they fall outside of the content.

We already update the featured image HTML, so I think updating images created on the frontend with wp_get_attachment_image should be explored. I also agree with only targeting functions that output the img HTML and not those that return a URL.

PR #517 looks like a great place to start and is the simplest approach that could be disabled by removing the filter.

If we move forward with this we would need to test this to make sure this doesn't impact areas that do not support WebP such as RSS feeds and Open Graph meta.

mxbclang commented 2 years ago

+1 on this! Since so many folks use page builders these days, I think we'll continue to get frustration/questions about this moving forward, so it would be great to address.

mukeshpanchal27 commented 2 years ago

+1 It would be fantastic if we could incorporate these changes into a plugin so that other page builders or custom template users could benefit from them.

I quickly test checked the Elementor Website Builder source code and they mainly used wp_get_attachment_image for image related blocks, so if we implement it, then it is a big win. Here we just need to think. We need to implement it as default like we do for the featured image.

For the unit test we cac remove_filter( 'wp_get_attachment_image', 'webp_uploads_update_attachment_image', 10, 2 ); filter so it will be pass.

If we move forward with this we would need to test this to make sure this doesn't impact areas that do not support WebP such as RSS feeds and Open Graph meta.

RSS feeds and OG meta does not use <img> tag related functions so i don't think there will be any impact on those. 🤔