Cache Plugins and WebP Delivery: A Practical Compatibility Pass

WebP delivery often depends on more than image files. A WordPress cache plugin may rewrite HTML, preload pages, minify markup, lazy-load images, integrate with a CDN, or serve different variants to different browsers. That can be helpful, but it can also hide stale images or deliver the wrong format after a migration.

A compatibility pass checks the real delivery path before the rollout expands.

"Clear your cache and check again" does not establish production compatibility. A compatibility pass should record which layer changed, which headers were returned, and whether fallback clients still receive a valid image.

Map the Delivery Layers#

List every layer that can touch the image response or page HTML:

• WordPress theme
• image optimization plugin
• page cache plugin
• lazy-loading feature
• CDN integration
• origin server rules
• browser cache
• service worker if present

The order matters. A plugin that rewrites image URLs before caching behaves differently from a CDN that negotiates formats at the edge.

MDN's HTTP caching guide is useful background for cache headers and shared-cache behavior. Use it to understand what the browser and intermediary caches may retain.

For GetWebP sites, start with the frontend delivery documentation. It explains the PHP rewrite path, picture insertion, output buffering, lazy-loaded images, and when server rewrite is needed for external CSS background images.

Test After Clearing Only the Right Caches#

When an image rollout looks wrong, it is tempting to purge everything. That may make the immediate issue disappear, but it does not teach the team which layer caused it.

Use a controlled sequence:

1. clear plugin page cache
2. test page HTML
3. clear image optimization cache if separate
4. test image URL directly
5. clear CDN path or zone if needed
6. test from a clean browser session

Record which step changed the result. That gives maintainers a real recovery path for the next deployment.

Verify MIME Type and Actual Bytes#

File extensions can mislead. A URL ending in .jpg may serve WebP through negotiation. A URL ending in .webp may be cached with an incorrect content type. Inspect the network response.

Check:

• Content-Type
• response status
• cache status header
• request URL
• transferred size
• decoded image dimensions
• whether the browser used the expected candidate

Google's WebP documentation identifies the format and MIME type background, but the production response is what matters.

Run both a format-capable request and a fallback-style request against the same URL:

curl -sI -H "Accept: image/avif,image/webp,*/*" https://example.com/wp-content/uploads/photo.jpg
curl -sI -H "Accept: image/png,image/*,*/*" https://example.com/wp-content/uploads/photo.jpg

Record the Content-Type, Vary, Cache-Control, CDN cache status, and final URL for each response. If both requests return the same cached bytes while the site expects negotiation, the cache key needs review.

Check Vary and Negotiation Rules#

Some delivery setups send WebP only when the request indicates support. If the same URL can return different formats, shared caches need a way to keep variants separate. Otherwise, one client can poison the cache for another.

Ask these questions:

• Does the cache key vary by the relevant request header?
• Does the CDN know about the format negotiation?
• Can fallback clients receive a supported image?
• Are page caches storing rewritten markup for all users?
• Is the fallback path tested after cache warmup?

If the team cannot answer these questions, explicit .webp and fallback URLs may be easier to maintain.

GetWebP's server rewrite documentation shows why this matters: the Apache/LiteSpeed rules can serve .avif or .webp siblings from an original JPEG/PNG URL when the request Accept header allows it, and the Vary: Accept header is used so shared caches can keep format variants separate.

Watch HTML Rewriting#

Cache and optimization plugins may rewrite <img> tags, srcset attributes, lazy-loading placeholders, or picture elements. This can break a carefully reviewed template if the rewrite catches more markup than intended.

Inspect the final public HTML. Confirm that:

• alt text remains present
• srcset candidates are not duplicated
• picture source order is preserved
• fallback img remains valid
• dimensions are not removed
• important hero images are not delayed unexpectedly

Caching should not erase accessibility or layout details.

Use the public HTML, not the editor preview, as the source of truth. For a GetWebP setup using picture insertion, the fallback img should still point to the original image path while AVIF and WebP sources appear above it. For a direct src rewrite, confirm that the rewritten URL has a valid generated sibling on disk or in synced storage.

Test Warm and Cold Cache States#

A cold cache and a warm cache can behave differently. After a purge, the first visitor may trigger generation of optimized variants. Later visitors may receive cached files. Both states need to work.

Test:

• first request after purge
• repeat request
• mobile viewport
• desktop viewport
• fallback-capable path if used
• logged-out visitor session

WordPress admin sessions can bypass caches, so use a visitor-like test whenever possible.

The WordPress troubleshooting guide is a useful failure checklist here: stale page cache, CDN cache, browser cache, missing .webp siblings, and custom upload directories can produce different symptoms. Keep those cases separate in the test record instead of labeling all of them "cache issue."

Keep a Compatibility Note#

For each site, write down:

Page cache plugin: enabled
Image rewrite: WebP via picture element
CDN cache: enabled
Purge order: plugin page cache, image cache, CDN
Negotiation: no, explicit WebP URLs
Known exception: homepage hero excluded from lazy loading

This note saves time during future image changes.

A stronger note includes the actual evidence:

Last reviewed: 2026-02-19
Page tested: /products/travel-bag/
Delivery mode: picture insertion
Warm cache request: passed
Cold cache request after purge: passed
Header check: image/webp returned for WebP-capable request
Fallback check: original JPEG path remained valid
Vary: Accept required: no, explicit variant URLs in HTML
CDN purge path: single product page + image folder
Failure found: one lazy-load plugin duplicated srcset on gallery thumbnails
Action: disabled that plugin's image rewrite for product galleries

That kind of note is more valuable than a general list of cache plugins because it captures the site's actual delivery path.

Cache plugins can make WebP delivery faster and easier, but they also add hidden state. A practical compatibility pass checks headers, rendered HTML, cache order, warm-cache behavior, and fallback paths before calling the migration complete.