Subtle diagonal pinstripe pattern in light grey and cream, giving an impression of printed editorial paper

Serve WebP in WordPress with fallback for older browsers

WebP can reduce the weight of WordPress images, but visitors using an older browser need a conventional file when they cannot decode the newer format. Serving both options gives every audience a usable graphic while allowing modern devices to download the smaller asset. The key is to select the format in a way that remains dependable behind caches, CDNs and mobile connections.

For Australian publishers, retailers and agencies, this balance is practical rather than theoretical. A Sydney storefront can receive traffic from shoppers on suburban NBN, fixed wireless and mobile connections, while a regional operator may depend on a slower 4G link. Smaller image payloads can improve pages on those connections, provided the site does not simply remove the original JPEG or PNG.

The most dependable method combines WebP generation in the WordPress media library with a <picture> element, correct server headers and deliberate cache rules. Native WordPress support handles many modern uploads, while plugins and CDNs can extend the process to older libraries or larger sites. Testing both the preferred format and the fallback confirms that the optimisation works for every audience.

Why fallback matters

A browser understands an image through its decoder, not by the file extension alone. Modern versions of Chrome, Edge, Firefox and Safari can display WebP, while older browser engines and some embedded applications cannot. If a server sends only WebP, an unsupported client may show an empty frame, a broken-image icon or alt text. The fallback is a JPEG, PNG or another broadly supported format that remains available at a separate URL.

The <picture> element makes that choice in the browser. It contains one or more <source> elements followed by a final <img> element. The browser examines the source type, media query and image descriptors, then uses the first suitable candidate. The final image is the fallback for clients that support none of the listed sources, so it must have a valid src, sensible dimensions and useful alternative text.

Relying only on the HTTP Accept header for content negotiation can be harder to control. Proxies and caches may store a WebP response under a shared URL and return it to a client that cannot decode it. If a single URL serves different representations, the cache must vary on Accept; even then, plugin-generated files, CDN rules and stale entries can complicate the setup. Separate .webp and .jpg URLs inside <picture> provide a clearer contract and make troubleshooting easier.

Prepare the WordPress media library

Begin on a staging copy and confirm that your host allows enough disk space, memory and image-processing extensions. Current WordPress releases can create WebP files from uploaded JPEG and PNG images through the conversion option under Settings > Media. WordPress 5.8 introduced core WebP support, although the exact interface depends on the installed version. Existing images are not necessarily converted retroactively, so an older library may need a one-off regeneration tool or a carefully configured optimisation plugin.

Keep the original upload and the WordPress-generated fallback. Thumbnails, featured images and responsive sizes are separate derivatives, and deleting one fallback variant can break a particular layout even when the full-size image still works. Check the site’s media cleanup settings before running bulk conversions, especially on WooCommerce stores with years of product photographs. Test a mixed set of portraits, transparent PNGs, wide banners and images with embedded text; each benefits from different compression settings.

Also review names, alternative text and dimensions as part of the conversion. A WebP file with the wrong Content-Type may be rejected even when its bytes are valid, while an image without alt text remains inaccessible despite being smaller. Preserve meaningful filenames and avoid replacing originals with opaque hashes. Where an existing URL is already indexed or linked, keep that URL live or provide a deliberate redirect, since an unnecessary extension change can create broken links and waste crawl time.

Output responsive picture markup

A theme template can use a static example for a featured coastal image. The WebP source comes first, while the JPEG source and its responsive descriptors remain in the <img> element:

<picture>
  <source
    type="image/webp"
    srcset="/wp-content/uploads/coastal-320w.webp 320w,
            /wp-content/uploads/coastal-768w.webp 768w,
            /wp-content/uploads/coastal-1280w.webp 1280w"
    sizes="(max-width: 768px) 100vw, 1280px">
  <img
    src="/wp-content/uploads/coastal.jpg"
    srcset="/wp-content/uploads/coastal-320w.jpg 320w,
            /wp-content/uploads/coastal-768w.jpg 768w,
            /wp-content/uploads/coastal-1280w.jpg 1280w"
    sizes="(max-width: 768px) 100vw, 1280px"
    width="1280"
    height="720"
    loading="lazy"
    decoding="async"
    alt="Coastal lookout near Sydney">
</picture>

For WordPress-managed media, use wp_get_attachment_image() or wp_get_attachment_image_src() to locate the selected attachment and its registered size, then generate the matching WebP source. A source should never point to a file that was not created: browsers select it before the fallback, and a missing WebP URL can trigger another request or display nothing. Many plugins perform this mapping automatically, while custom themes should verify it against every registered image size.

Keep the sizes value aligned with the real layout. A full-width mobile banner, a square product thumbnail and a sidebar image need different candidate widths. The width and height attributes reserve space and prevent layout shift; the browser can still scale the chosen asset. Lazy loading suits below-the-fold images, but the first hero image is often better loaded eagerly with fetchpriority="high". Search crawlers can index WebP images, and descriptive alt text remains important for accessibility and image search.

Configure MIME types and caching

The web server must identify .webp files as image/webp. Most modern Apache and Nginx installations include the mapping, but a CDN, security rule or restricted host can remove it. Apache users can place this in .htaccess when mod_mime and mod_headers are available:

<IfModule mod_mime.c>
    AddType image/webp .webp
</IfModule>

<IfModule mod_headers.c>
    <FilesMatch "\.webp$">
        Header set X-Content-Type-Options "nosniff"
        Header set Cache-Control "public, max-age=2592000"
    </FilesMatch>
</IfModule>

For Nginx, confirm that mime.types contains image/webp webp, or define the type in the relevant server block. A separate location also provides long-lived caching for the format:

location ~* \.webp$ {
    types { image/webp webp; }
    add_header Cache-Control "public, max-age=2592000" always;
    add_header X-Content-Type-Options "nosniff" always;
    try_files $uri =404;
}

Cache the generated image files for weeks or months, but keep the HTML containing <picture> on a shorter policy or purge it whenever markup changes. Because the WebP and JPEG URLs are distinct, they do not require Vary: Accept; that header becomes important only if one URL returns either representation. After deployment, inspect response headers through the browser’s network panel and confirm a 200 status, the correct MIME type, no forced download and a cache policy that suits your update process.

Compare plugin and CDN delivery

A WordPress plugin is usually the simplest choice for a small site. Look for one that both generates WebP files and emits <picture> markup, rather than a converter that changes files without changing theme output. Check its recent maintenance, PHP requirements and support for your WordPress version. Review any .htaccess edits, because a plugin’s rewrite rules can conflict with the server configuration or with a CDN. Install one image-delivery stack at a time to prevent duplicate markup and repeated compression.

CDN delivery suits sites with many images, global traffic or an existing edge network. It can optimise media on request, vary output by browser and serve cached copies from an edge closer to the visitor. Australian businesses should compare edge locations in Sydney, Melbourne, Brisbane and other regional hubs, along with egress charges and image-processing rules. A cheaper origin plan can still perform poorly if the first request must fetch and convert every derivative. For WooCommerce catalogues common among Australian independent retailers, verify product thumbnails, zoom images and cart views across mobile checkout journeys, especially during busy online sale periods.

Privacy settings belong in the delivery review as well. A third-party CDN or optimisation plugin may receive visitors’ IP addresses and user-agent details, and some services add cookies or audience-tracking scripts. The federal Privacy Act 1988 and Australian Privacy Principles generally apply to Australian organisations with annual turnover of $3 million or more, while some organisations are covered regardless of turnover. Document the relevant service providers, update the privacy notice, and use consent controls where tracking or targeted advertising is involved. Image optimisation itself can remain cookie-free.

Test, monitor, and maintain delivery

Test the finished template in a staging environment with both modern and legacy browser profiles. A structured browser compatibility test can reveal whether the page requests WebP, whether the JPEG remains reachable and whether any theme or script changes the markup. In developer tools, confirm that the selected source returns Content-Type: image/webp, that the fallback image returns 200, and that alt text, dimensions and lazy-loading behaviour remain correct. Test a real older operating system when possible because changing only the user-agent string does not remove WebP decoding support.

Repeat the check under Australian network conditions, including NBN in a major city, fixed wireless in a regional town and mobile broadband on 4G or 5G. Compare page weight, visible loading time and interaction response rather than looking at image size alone. Also verify that a slow connection still receives the fallback first when required, that repeated visits use cached files and that no layout gap appears before the image arrives. Throttling tools help, but a check on an actual connection provides a useful additional signal.

Keep the conversion process visible after launch. WordPress Site Health, server logs and CDN analytics can reveal missing derivatives, 404 responses, unexpectedly large files or cache misses. Schedule recurring checks of key product, campaign and editorial images, and purge affected HTML or image caches after a deliberate replacement. Update WordPress core, themes, plugins and PHP as part of normal security maintenance so the media workflow does not become an overlooked weak point. A well-tested WebP setup then delivers smaller files to current browsers while retaining a dependable conventional image for visitors whose software cannot decode the newer format.