[wp-trac] [WordPress Trac] #55443: Create WebP sub-sizes and use for output
WordPress Trac
noreply at wordpress.org
Thu Jul 14 18:48:35 UTC 2022
#55443: Create WebP sub-sizes and use for output
-------------------------------------------------+-------------------------
Reporter: adamsilverstein | Owner:
| adamsilverstein
Type: enhancement | Status: assigned
Priority: normal | Milestone: Future
| Release
Component: Media | Version: 6.0
Severity: normal | Resolution:
Keywords: has-patch has-unit-tests needs- | Focuses:
testing needs-dev-note needs-docs needs-user- | performance
docs |
-------------------------------------------------+-------------------------
Comment (by adamsilverstein):
Hey @MatthiasReinholz, thanks for the feedback. Responses inline below:
> So if I understand right, the current approach is to make WebP the
default image format for all Core image sizes, correct?
Correct.
> additional resources for this conversion are tremendous.
I'm not sure I agree. Resources for generating images when you upload an
image will increase dramatically, however resources to serve an image will
be lowered. Since image uploading is very rare compared to image serving,
the extra effort to compress and store images should be worth it.
> Every single plugin in the directory utilizing MozJPEG compression plus
PNG compression (and no WebP conversion) will generate competitive (IMHO
better) results than the currently planned Core solution. This is because
the file sizes will be comparable but we don't generate duplicates.
I'm not sure what you mean by "MozJPEG compression plus PNG compression" -
isn't PNG a separate format?
MozJPEG is not widely available on PHP servers whereas WebP is. WebP
offers additional benefits over MozJPEG compression/quality wise and also
offers transparency and a lossless mode so it has the potential to replace
transparent PNGs for example. Additionally we are building hooks in so
existing plugins can control and integrate with the core feature.
> Further, there are other next-gen formats coming up that are even more
efficient than WebP (e.g. AVIF).
Absolutely and this feature is built with those potential formats in mind.
Still, major browsers still don't support AVIF (Safari has announced
support in their next release, hopefully Edge will follow suit). In
addition, AVIF support isn't available in PHP until 8.1. Future potential
improvements aren't a good reason to not take advantage of the significant
improvements available in WebP now.
> it will also be a serious threat to plugin authors and existing larger
websites that do not pay attention to this change
this is a significant change and I agree large sites and plugin authors
need to pay attention to these changes to choose the best path forward.
I'm not sure about the threat to plugins - the team reviewed many
image/optimization plugins and WebP is typically a very small part of what
they offer.
> Therefore, I'm questioning why this functionality should be activated by
default at this stage. IMHO, it should be opt-in only.
Appreciate the concern (although I don't completely agree). We are
starting with the change only for core image sizes in part as a way to be
cautious about impact and give the ecosystem time to adapt (eg. so plugins
or themes that add custom sizes can decide if they want secondary mime
output)
> Plus ideally, we would already start to think about adding further image
formats to be supported by this feature.
+1 this is already underway in the Performance Lab plugin where we have
open tickets exploring AVIF and JPEGXL support, as well as adding the
`picture` element to enable serving fallback images.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/55443#comment:43>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list