-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Progressive transition into WebP formats #150
Comments
I'm feeling more and more we should stick with Strategy 1 here for the backwards compatibility reason alone. We can still achieve the goal of displaying WebP by default on the output side. In addition, the API/filter(s) should support an approach that enables only outputting WebP sub-sizes (with the exception of the full size -scaled image) - maybe not as the default, but as one possible option. This may turn out to be the best option for most users, especially over time. |
I agree with @adamsilverstein's feedback above, and I would extend it to say that we should probably always use the original format of the image uploaded as the default. In other words, it won't always be JPEG, it will only be JPEG if the original image is JPEG. If the original image is PNG, it would be PNG, and if someone directly uploads WebP, it would be WebP. I think that would preserve backward compatibility, and it would also keep the original format the primary one which makes it IMO more clear to understand. It also ties in with your draft PR #154, where you're exploring to store the "other" formats in a separate meta key. That makes me think even more that the default format should be the originally uploaded one. |
Closing this one as we have merged:
And we have #186 to customize the behavior for rendering the correct image. |
Feature Description
Based on:
the_content
with the correct image format #149At this point, we can assume that every image would have at least 2 formats when the WebP module is enabled in this case the well-known and supported JPEG and the WebP format, (eventually leading into other formats as those are supported in WP). So this issue is mostly to define the strategy behind this image generation and decide into the approach into the transition into a modern format and still have a fallback for older browsers or users using this plugin but not necessarily interested in test/using this section of the performance plugin.
Strategy 1 - Default JPEG and WebP as an enhancement
This approach suggests keeping using JPEG in the sizes definition of the metadata of each image, creating the WebP version after all the JPEG versions were created and WebP images are created only as an enchantment for the existing images.
Benefits
Problems
the_content
with the correct image format #149 in order to render the new image formatStrategy 2 - WebP by default and JPEG as a fallback
This strategy suggests instead a logic similar to the current behavior of the plugin which is for new image uploads only create the WebP version and create the JPEG version of the images as fallback, and WebP format is used as the default image format for all new image uploads. JPEG versions for the images are created as a fallback approach.
Benefits
wp_get_attachment_image_src
andthe_conent
would render automatically the modern image format, in this case WebPProblems
Reasoning
The main reason to discuss this approach is to have a standard way of doing things, due if we have WebP versions for some attachments as the main images and JPEG for others things start to become more complex due we need to deal with multiple combinations, in some cases JPEG version is used an in others WebP. So knowing before approaching #149 or other places where we need to replace or update references to images we know which mime type is the main image type and which one is the one used as an enchantment.
Note in all scenarios JPEG and WebP versions would be present in the WordPress installations and no file would be removed, unless the main attachment image is removed.
The text was updated successfully, but these errors were encountered: