Delivery and caching

Optimized files that don't reach visitors.

This is the single most common "it didn't work" report, and it's almost never Inverity. The optimized file is already written back to your platform. Something between your platform and your visitor is still serving the old copy.

My optimized images aren't showing on my site

Your site or CDN is serving a cached copy. Clear your CDN or page cache; the optimized file is already in your platform.

Most stacks have more than one cache, and clearing one isn't enough. Work outward from the origin:

1. Platform-side image cache — Adobe Commerce generates one; WordPress caching plugins keep another; several DAMs cache derivatives.
2. Full-page cache — your CMS's own, or a plugin's.
3. CDN — Cloudflare, Fastly, Akamai, or your platform's built-in CDN.
4. Your browser — test in a private window, or hard-reload.

How to confirm what's actually being served

Open the image URL directly — not the page it's embedded in — in a private window, and check the file size your browser reports in its network panel.

• Small file → the optimized version is live, and whatever you were looking at before was cached.
• Original file size → a cache in front of your platform still holds the old copy, or you're looking at a different asset than you optimized.

Platform-specific notes

Shopify, BigCommerce, HubSpot serve images through their own CDN. Propagation follows their schedule rather than being instant.

Webflow serves the published site — you may need to publish before visitors receive the optimized files.

Contentful and Sanity may require an asset to be published before the delivery API serves it, depending on how your space or dataset is configured.

Adobe Commerce keeps its own generated image cache in addition to any CDN and full-page cache. Flush all of them.

WordPress sites usually have a caching plugin and a CDN. Clear both.

Cloudinary caches generated derivatives, which refresh on Cloudinary's own schedule after the source changes. See Cloudinary.

After a re-run

Same rules apply. A re-run produces a new file, and every cache in front of your platform still holds the previous one. Purge after re-runs, not just after the first run.

Why doesn't Inverity clear my cache?

Because it isn't in your delivery path. Inverity writes the optimized file back into your platform and stops there — it isn't a CDN, an image proxy, or a delivery service, so it has no access to purge caches it doesn't own. See How optimization works.