CDN caching and cache invalidation for Cascade sites

You published the updated tuition page ten minutes ago. Your colleague sees the new figures. You still see last year's. Nothing is broken. You are looking at a cached copy, and the only question is which cache is holding it. A Cascade site usually has three: your browser, the content delivery network (CDN), and occasionally the web server. Each one is easy to check.

Why the CDN is there

A CDN keeps copies of your pages and files at edge locations near your visitors. Most requests are answered from the edge without touching your web server, so pages load faster and a surge of traffic on decision day does not reach the origin. The trade is freshness: an edge copy stays in place until it expires or is explicitly cleared. Cache invalidation is the act of clearing it. Done well, visitors get the speed of caching and the new content within moments of a publish.

A two-minute diagnosis

1. Private window or another device. If the page is correct in a private window or on your phone over cellular data, your own browser was holding the old copy. Nothing needs fixing.
2. Check the response headers.

   curl -sI https://www.example.edu/tuition/ | grep -iE "last-modified|cache-control|age|x-cache"

   • Last-Modified before your publish: the server has the old file. The publish did not deliver it. Check the publish report and republish.
   • Last-Modified after your publish, X-Cache showing a hit, and a large Age: the server is current and the CDN is serving an older copy. The edge needs invalidating.
   • X-Cache showing a miss or refresh with a recent Last-Modified: the CDN just fetched the new file. Anyone still seeing old content has it in their browser.
3. Check a second page that was part of the same publish. If one updated and another did not, the invalidation may have covered one path but not the other.

Cache rules that balance speed and freshness

Different kinds of files deserve different cache lifetimes. A sensible baseline for a Cascade site:

Versioning is the part editors and developers control. If your templates reference /css/site.css with no version, every stylesheet change depends on invalidation reaching every edge. If they reference /css/site.css?v=2026-09 or a fingerprinted file name, a new version is simply a new URL and no one ever sees a mismatched page. Ask your template developer whether your site does this.

What healthy looks like

• Most static files, 90 percent or more, served from the edge rather than the origin.
• Cached pages delivered to visitors in well under a second.
• Published changes visible to new visitors within a few minutes, without anyone asking for a manual cache clear.

If editors routinely ask for manual cache clears, invalidation is not wired to publishing, or cache lifetimes are longer than the content deserves.

How eWay configures caching for Cascade

eWay configures the CDN, CloudFront on AWS or Azure Front Door on Azure, specifically for Cascade's static output. When a publish completes, the affected paths are invalidated automatically. High-traffic pages are re-warmed after invalidation, so the first visitor after a publish does not pay the full trip to the origin, which matters when a big announcement goes out during peak traffic. eWay monitors cache hit ratio and origin load, and tunes cache rules per content type rather than using one lifetime for everything.

Common questions

• Can we just turn caching off for a while? You can, but every visitor then hits the origin, pages slow down, and a traffic spike lands directly on the server. Shorter lifetimes on HTML are almost always the better answer.
• Does invalidation cost anything? CDNs limit or charge for very large numbers of invalidation paths. Invalidating the specific folders a publish touched, rather than the whole site every time, keeps it fast and inexpensive.
• Why did the homepage update but a PDF did not? PDFs are often replaced under the same file name and cached for longer. If a document changes often, give it a new file name or make sure its folder is included in invalidation.

What to include in a support ticket

• The severity you would assign, P1 to P4 (see severity levels and response times)
• The URL that looks stale and the time you published it
• The header output from the check above
• Whether it looks wrong in a private window or on another device

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: how Cascade publishing reaches your live website and handling enrollment traffic spikes on Cascade sites. More at Cascade Website Hosting.