Shipping WebP on a WordPress Site

WordPress added native WebP upload support in version 5.8 (July 2021) and added automatic WebP serving in 6.1. For most modern WordPress sites, shipping WebP today is a one-plugin or zero-plugin change. This guide covers the options, the trade-offs, and the configuration that actually delivers the performance win.

For the underlying performance principles, see WebP Optimisation. For format choice, see Lossy vs Lossless.

What WordPress core supports

As of recent versions, WordPress core handles:

WebP uploads — you can upload .webp files through the Media Library.
WebP serving — uploaded WebP files are served directly without conversion.
Automatic image size variants — when you upload an image, WordPress generates thumbnail, medium, large, and full-size variants. WebP uploads get the same treatment.

What WordPress core does not do automatically:

Convert existing JPEG/PNG uploads to WebP.
Generate WebP alternates for new JPEG/PNG uploads.
Serve WebP to capable browsers with a JPEG/PNG fallback to others.

For most sites, you want a plugin to fill those three gaps.

Plugin options

Native WebP serving via image-optimisation plugins

The three most popular options:

ShortPixel — Cloud-based image optimisation. Converts on upload and on bulk-process. Serves WebP via <picture> rewriting or via Accept header negotiation through a CDN front-end.
Imagify — Similar to ShortPixel, from the WP Rocket team. Strong on automation and bulk processing.
EWWW Image Optimizer — Can run entirely locally (no cloud roundtrip) or use a cloud API. The cloud option is faster but adds latency to uploads.

All three handle the three gaps WordPress core leaves open. The choice between them comes down to:

Cloud round-trip latency — if your media library is large, the difference between processing locally and processing in the cloud matters.
Pricing model — ShortPixel and Imagify meter by image; EWWW can be flat-rate.
CDN integration — if you already use a CDN (Cloudflare, BunnyCDN), some plugins integrate more cleanly than others.

CDN-level conversion (skip the plugin)

If your site is fronted by Cloudflare Polish, BunnyCDN's Bunny Optimizer, Cloudinary, or any other modern image CDN, those services can do WebP conversion on the fly. The original JPEG/PNG sits in /wp-content/uploads/, and the CDN serves WebP to capable browsers based on the Accept request header.

This approach has several advantages:

No plugin needed.
No conversion delay on upload.
No additional WebP files on disk.
WebP conversion settings are tuned by the CDN provider.

The trade-off is dependency on the CDN. If you migrate off the CDN, you lose the conversion. For sites already using a CDN, this is the path of least friction.

Other plugin types

WP Rocket — primarily a caching plugin, but includes WebP serving (via the WebP rewrite rules) when used alongside Imagify.
Smush — WebP conversion in the Pro version.
Optimole — cloud-based image optimisation with built-in CDN.

The `<picture>` element vs URL rewriting

There are two patterns for serving WebP-or-fallback:

`<picture>` element rewriting

The plugin modifies your HTML output to replace <img src="photo.jpg"> with:

<picture>
  <source srcset="/wp-content/uploads/photo.webp" type="image/webp" />
  <img src="/wp-content/uploads/photo.jpg" alt="..." />
</picture>

Pros: works everywhere, no server config needed, browser handles the fallback transparently.

Cons: changes HTML output, which can interact with caching plugins, AMP, or custom theme code. Larger HTML payload.

URL rewriting via Apache/Nginx

The plugin adds rewrite rules so that when a browser requests photo.jpg, the server inspects the Accept header and returns photo.webp if the browser supports it (with Vary: Accept header).

Pros: no HTML changes, smaller response, transparent to caching layers.

Cons: requires server access (Apache .htaccess or Nginx config). Some hosts disable .htaccess overrides; some managed WordPress hosts require submitting Nginx config requests.

For most sites, <picture> rewriting is the safer default. For high-traffic sites where every byte matters, URL rewriting is preferable.

Bulk-converting your existing library

If your site has years of JPEG and PNG uploads, you need to bulk-convert them once.

All three major optimisation plugins offer a bulk process. Tips for the first run:

Back up /wp-content/uploads/ first. Bulk processing rarely fails, but image processing is one thing you don't want to redo because of a corrupted run.
Start with a small batch to confirm the output looks right before processing thousands of images.
Set quality to 75–80 for lossy WebP — see WebP Compression Settings for parameter detail.
Process during off-peak hours if the plugin pegs the server CPU.

The first run can take hours or days on a large library. Subsequent uploads convert immediately.

Specific WordPress optimisation considerations

Featured images and the LCP question

The featured image of a blog post or page is often the Largest Contentful Paint element. Two things matter:

The featured image should not be lazy-loaded. WordPress core sometimes adds loading="lazy" to all images including the featured image, which regresses LCP. See WebP Lazy Loading.
The featured image should be preloaded if performance matters. Most themes don't do this by default. Add it via a plugin like Perfmatters or a small theme tweak in functions.php:

function add_lcp_image_preload() {
  if (is_single()) {
    $thumb_id = get_post_thumbnail_id();
    if ($thumb_id) {
      $img = wp_get_attachment_image_src($thumb_id, 'large');
      if ($img) {
        echo '<link rel="preload" as="image" href="' . esc_url($img[0]) . '" fetchpriority="high" />' . "\n";
      }
    }
  }
}
add_action('wp_head', 'add_lcp_image_preload');

Page builders and image handling

Elementor, Divi, Gutenberg, Beaver Builder, and others all output images through their own templates. Most respect the the_content filter that image optimisation plugins hook into, but a few exceptions:

Elementor background images are CSS, not <img> tags. Plugin-based WebP conversion may miss them. Use CDN-level conversion or a plugin with Elementor-specific support.
Image carousels sometimes pre-render the next slide invisibly, defeating lazy loading. Verify the network panel shows the expected behaviour.
Cover blocks (Gutenberg) use CSS background images and need the same treatment as Elementor backgrounds.

Cache plugin interaction

If you use WP Rocket, W3 Total Cache, or LiteSpeed Cache, ensure:

The cache stores separate variants for WebP-supporting and non-WebP browsers (the Vary: Accept issue). All major cache plugins handle this when configured for WebP.
After bulk-converting your library, purge the cache so the next requests rebuild with WebP URLs.

CDN setup

If your site uses Cloudflare:

Polish (paid plan) can convert images to WebP at the edge.
Mirror Polish setting is "Lossless" or "Lossy" — lossy is fine for photos, lossless preserves the original quality.
Cache rules need Vary: Accept to serve the right variant.

For BunnyCDN, Stackpath, or KeyCDN, the conversion options are similar.

Testing your setup

After enabling WebP serving, verify:

Open a blog post in Chrome DevTools → Network panel. Filter by "img". Confirm the requests are returning .webp (or that the response Content-Type: image/webp).
Test in Safari on iOS 13 or older (if you can) to confirm the fallback works. Or use a user-agent string for an old browser in DevTools.
Check the page in a Lighthouse audit. "Serve images in next-gen formats" should no longer flag.
Verify Core Web Vitals in Search Console after a week of traffic. LCP usually improves noticeably. See Core Web Vitals & Images.

Common issues

"WebP files appear in the upload directory but the site still serves JPEG"

Either:

The HTML rewriting did not apply (check the rendered HTML for <picture> tags).
The cache plugin is serving an old version of the page (purge cache).
The URL rewriting is not active (check the response headers for Content-Type: image/webp).

"Images break in Safari on older iOS"

If you are using URL rewriting (single URL, content negotiation), the Vary: Accept header must be present. Without it, a CDN may cache the WebP response and serve it to non-WebP browsers. Test by changing the Accept header and verifying the response changes.

"Lighthouse still says 'serve images in next-gen formats'"

Lighthouse evaluates a single Lighthouse-controlled fetch. If your serving is Accept-header-based, Lighthouse may not send the right header. Verify with a real Chrome session in DevTools.

"The WebP conversion is hammering the server CPU"

Image conversion is CPU-intensive. Mitigations: process in smaller batches, schedule bulk runs during off-peak hours, or offload to a cloud-based service (ShortPixel, Imagify cloud).

Recommended setup

For a typical WordPress site in 2026:

Install ShortPixel, Imagify, or EWWW Image Optimizer.
Configure it for WebP serving with <picture> element rewriting.
Set lossy WebP quality to 75–80.
Bulk-convert the existing library.
Add LCP image preloading for templates where the featured image is the LCP element.
Verify the response on the front-end and in Lighthouse.

For sites already on a modern image CDN: skip the plugin, configure the CDN's WebP conversion, and audit the response.

Where to go from here

WebP Optimisation — performance fundamentals
WebP Compression Settings — encoder parameter detail
Lossy vs Lossless — mode selection
WebP Browser Support — fallback patterns
WebP Lazy Loading — loading strategy
Core Web Vitals & Images — measuring impact
Convert content: PNG to WebP, JPG to WebP, GIF to WebP

Shipping WebP on WordPress is no longer a difficult problem. Pick the integration that fits your stack, configure it once, and the performance compounds across every page load.