WordPress and WebP: What It Does Automatically and What You Still Have to Fix
WordPress has generated WebP versions of uploaded images automatically since version 5.8, and more recent releases serve them by default. A lot of site owners take that as the image-optimisation box ticked. It is not — it handles one part of the problem and leaves several others untouched.
What WordPress does handle
On upload, WordPress generates its registered thumbnail sizes and produces WebP versions alongside the original. When a browser that supports WebP requests an image, the WebP is served. The srcset attribute is populated automatically from the registered sizes. For a straightforward blog this genuinely covers a lot of ground.
What it does not handle
The original upload is untouched. If you upload a 5000-pixel, 8 MB JPEG straight off a camera, WordPress keeps it at full size and generates derivatives from it. The full-size original is what gets served in the lightbox on many themes, and it is still 8 MB. Resize before uploading, or set a maximum upload dimension.
Quality settings are conservative. The default WebP quality is tuned to avoid complaints rather than to be small. Dropping it to 80-82 via the wp_editor_set_quality filter typically halves file sizes with no perceptible difference on photographic content.
Images in page builders often bypass it. Elementor, Divi, WPBakery and similar builders frequently reference images through their own markup and their own caching layers. Background images set through a builder's style panel usually miss the responsive and format handling entirely.
Theme and plugin assets are not covered. Icons, decorative graphics, sprite sheets and anything shipped inside a theme or plugin directory was never a media-library upload, so nothing processes it. On some themes this is a surprisingly large share of the total.
Existing media is not converted retroactively unless you run a bulk regeneration. A site with ten years of uploads has ten years of unconverted images.
Where the weight usually hides
In practice, on a site that already has WordPress's WebP handling enabled, the remaining bulk is almost always one of three things: full-size originals served in lightboxes, hero and background images set through a page builder, and PNG screenshots in old posts that should have been converted years ago.
PNG screenshots deserve a specific mention. Documentation-heavy sites accumulate hundreds of them, each often over a megabyte because PNG compresses photographic and anti-aliased content badly. Converting those to WebP — lossless for pure UI shots, lossy for anything photographic — is frequently the single largest saving available on the whole site.
A sensible order of operations
- Set a maximum upload dimension so new full-size originals stop being enormous.
- Lower the WebP quality filter to around 82.
- Convert the worst offenders in the existing library — sort the media library by size and start at the top.
- Audit what a page actually loads using DevTools, filtered to images, with mobile emulation on.
- Fix whatever the audit surfaces, which will usually be builder-set background images.
Keep the originals somewhere
Whatever you do, keep a master copy of your photography outside the CMS. WordPress's derivatives are disposable and regenerable; your source images are not. Treating a CMS media library as an archive is a decision people regret at migration time.