Cookies publicitaires

Nous utilisons des cookies publicitaires pour mesurer l'efficacité de nos campagnes. Vous pouvez les refuser sans que cela affecte votre navigation. En savoir plus

Resources · Blog

WordPress 6.7 already does WebP natively: why ImagePipe still matters

What WordPress 6.7's native WebP generation actually does, and why on-demand generation still covers a gap it doesn't.

Photograph icon representing image format conversion August 24, 2026

WordPress 6.7, released in November 2024, added automatic WebP generation to the core media library : when a JPEG is uploaded, core now generates WebP versions of the registered thumbnail sub-sizes alongside the original by default, without requiring a plugin. This sits on top of capabilities already present in recent core versions, such as automatically written width and height attributes on inserted images and a fetchpriority="high" hint applied to the large image detected above the fold.

Technically, this WebP generation happens once, at upload time. WordPress converts the sub-sizes that are registered at that specific moment, using whatever dimensions the active theme or plugins have declared through add_image_size. The resulting files are static : they sit in the uploads folder exactly like the JPEG originals they accompany, ready to be served, but frozen in both format and dimensions from the moment they were created.

That freeze is the structural limit, not a flaw in the implementation. If a theme changes its product grid and needs a new crop ratio, if a merchant wants AVIF (which frequently compresses photographic product images further than WebP at comparable quality), or if a new placement on the site calls for a size that was not registered at upload time, none of that applies retroactively to a catalog of images already sitting in the media library. Reaching every existing product photo requires a bulk regeneration pass, run deliberately, after the fact.

ImagePipe generates variants on demand instead of at upload, so a preset change or a new placement does not require touching the media library at all : the next request for that image is served under the new configuration, with no regeneration step to schedule. Format negotiation also continues past what core does today : on Pro and above, ImagePipe adds AVIF into the same Accept-header negotiation that already picks between WebP and JPEG, so the lightest supported format keeps being selected as browser support evolves, not just the one generated once at upload.

For a store with years of existing product photos rather than a brand-new catalog, the relevant question is not whether WordPress core can produce WebP today, since it clearly can, but what happens when presentation requirements change after those photos were already uploaded. That gap between a one-time conversion and an image whose format and dimensions can still adapt later is where ImagePipe's preset system sits, alongside core rather than instead of it.

Back to blog