CDN Caches and WebP: Avoid Stale Image Rollouts

Moving a site from JPEG or PNG to WebP is not only a conversion task. It is also a delivery task. If a CDN, reverse proxy, CMS cache, or browser cache keeps serving old variants, the rollout can look inconsistent: some users see WebP, some see the old image, and some receive a file that does not match the page markup.

A good rollout plan treats caching as part of image optimization. The files can be correct on disk and still be wrong in production if cache keys and invalidation are not understood.

"Clear your CDN cache after converting to WebP" does not answer the production delivery question. The real quality check is whether the right variant, content type, fallback, and cached object are being served to the right client after the rollout.

Know Every Cache in the Path#

Start by listing the systems between the source file and the visitor:

• build output or media folder
• CMS image processing layer
• origin web server
• reverse proxy
• CDN
• browser cache
• service worker cache

Each layer can keep an older asset. Updating the file in one place does not necessarily update every cache. MDN's HTTP caching documentation is a useful reference for the caching headers that influence browser and shared-cache behavior.

For image rollouts, identify who owns each layer and how it is cleared or versioned.

Turn the path into an owner table:

This prevents a generic "purge cache" recommendation from hiding the actual owner and failure point.

Avoid Reusing URLs for Different Bytes#

The safest deployment pattern is often to give changed image bytes a changed URL. That can be a hashed filename, versioned path, or build-generated asset name.

For example:

hero.jpg
hero.9f31c2.webp

or:

/images/2026/hero.webp?v=2026-01-05

Hashed filenames are usually cleaner than query strings when the build system supports them. The important principle is that caches can treat the new file as a new resource.

Overwriting hero.webp in place can work when cache invalidation is reliable, but it creates more room for stale results.

If files are generated locally before deploy, record the conversion command and output path:

npx -y getwebp ./source-images -o ./public/images --recursive --format webp --json

The GetWebP CLI commands reference documents separate output directories with --output, recursive processing with --recursive, explicit webp or avif output with --format, and structured output with --json. Keeping generated files in a predictable deploy folder makes it easier to version paths and verify what the CDN should receive.

Check Vary Behavior for Negotiated Images#

Some systems serve WebP from the same URL based on request headers such as Accept. This can be convenient, but it must be cached correctly. If the CDN does not vary the cache key by the right header, one browser may receive a variant intended for another.

Review this carefully if your setup uses content negotiation:

• the same URL can return different formats
• the response declares the correct Content-Type
• shared caches distinguish the variants
• fallback browsers do not receive unsupported files
• testing covers both WebP-capable and fallback clients

Explicit file URLs such as .webp and .jpg are easier to reason about. Negotiation can be useful, but it raises the standard for cache review.

For WordPress, the distinction matters because GetWebP supports PHP-based frontend delivery and server rewrite delivery as different paths. The Frontend Delivery docs describe rewriting rendered image output when optimized siblings exist; the Server Rewrite docs cover server-level behavior. If a CDN sits in front of either path, verify the final edge response, not only the WordPress admin state.

Confirm Content-Type and File Extension#

A WebP file should be served with the correct media type. Google's WebP documentation identifies image/webp as the MIME type. Misconfigured servers can return a WebP file with a generic or incorrect type, which may confuse tooling, proxies, or debugging.

Check response headers after deployment:

Content-Type: image/webp
Cache-Control: public, max-age=31536000, immutable

Use direct header checks in the deployment note:

curl -sI https://example.com/images/hero.webp
curl -sI -H 'Accept: image/avif,image/webp,image/*,*/*' https://example.com/uploads/hero.jpg
curl -sI -H 'Accept: image/jpeg,image/png,image/*,*/*' https://example.com/uploads/hero.jpg

For explicit .webp URLs, the expected response is straightforward: Content-Type: image/webp for the WebP file. For negotiated same-URL delivery, record whether modern and fallback requests return different Content-Type values and whether the CDN varies the cache key correctly.

Long cache lifetimes are sensible only when filenames are versioned. If URLs are reused, extremely long lifetimes can make rollbacks and corrections painful.

Purge With a Targeted List#

If the rollout requires cache purging, use a known list of changed URLs. Avoid relying on a vague "clear everything" action unless the site is small and the operational cost is acceptable.

Keep a deployment note with:

• original URL
• new URL
• pages that reference it
• cache keys or variants
• purge status
• verification result

This turns a cache issue from a guessing exercise into a checklist.

Example purge manifest:

Rollout: homepage campaign hero - 2026-01-05
Changed URLs:
- /images/home-hero.9f31c2.webp
- /images/home-hero.9f31c2.jpg
Old URLs kept:
- /images/home-hero.2025.jpg
Pages affected:
- /
- /campaigns/q1-demo/
Cache actions:
- CDN purge: exact paths
- service worker manifest: updated
- CMS page cache: purged for affected pages
Verification:
- clean browser session pass
- repeat visit pass
- fallback request pass

The manifest should name exact paths. "Cleared cache" does not prove the stale-image rollout was resolved.

Test From More Than One View#

After deployment, test with normal browser navigation and direct URL requests. Use DevTools to confirm the served type, status code, cache state, and selected image candidate.

Check:

• a first visit with empty cache
• a repeat visit
• a mobile viewport
• a desktop viewport
• a fallback path if one exists
• a page behind any service worker

If the site uses a CDN with regional edge caches, a single local test may not prove that every edge is updated. For high-traffic campaigns, staggered or monitored rollout may be safer.

For public page checks, combine browser and terminal evidence:

Page: /
Visual slot: homepage hero
Rendered HTML: picture tag points to versioned WebP and JPEG fallback
Network: browser selected home-hero.9f31c2.webp on Chrome desktop
Header check: Content-Type image/webp, CDN cache HIT after first request
Fallback check: JPEG URL returns image/jpeg and current creative
Mobile check: selected mobile candidate, not desktop hero

This shows whether the rollout improved the page, not only whether a file exists.

Keep Rollback Boring#

Rollback should not depend on manually editing many templates under pressure. If a new WebP asset fails visual review after deployment, the team should know whether to restore the previous URL, update a manifest, purge a CDN path, or change a CMS field.

Store originals and fallbacks until the rollout is verified. A local-first conversion workflow helps here because original files remain available, but the deployment process still needs a clear restore path.

GetWebP's WordPress FAQ documents the sibling-file model and notes that originals are not deleted by conversion; generated variants can be removed while original URLs remain available. See the WordPress FAQ. That model is useful for rollback, but only if the CDN and page cache are also returned to a known state.

Report What Was Verified#

A useful deployment summary might say: "The homepage hero and four campaign images were published as versioned WebP files. CDN headers show image/webp. The old URLs remain available as JPEG fallbacks. The new URLs were verified from a clean browser session and repeat visit."

That is much better than "images optimized." It tells future maintainers which delivery risks were checked.

Make the summary auditable:

Images converted: 14
Pages changed: 3
Delivery pattern: picture tag with WebP and JPEG fallback
Cache strategy: versioned filenames, exact-path purge for affected HTML
Header verification: WebP URL returns image/webp; fallback URL returns image/jpeg
Stale check: repeat visit and CDN HIT still serve current bytes
Rollback: previous manifest retained for 7 days
Open issue: social preview image still cached by external platform

This is the level of specificity that separates a useful CDN rollout article from generic performance advice.

WebP conversion reduces bytes only when the right file reaches the right user. Treat cache keys, headers, purges, and rollback as first-class parts of the rollout, especially on sites with CDN delivery.