CDN refreshed, why are some users still seeing the old page?

When the CDN has been refreshed but users still see the old page, most of the time the problem is not the refresh action itself. It is that old copies are spread across several cache layers, and only one layer was cleared. In common 2026 projects, the same “page not updated” symptom can come from any of these layers: browser strong caching, CDN edge nodes, Service Worker, or a mini program local package. A fixed check order is recommended: “response headers of the entry HTML → whether static asset filenames carry a content fingerprint → CDN refresh and prewarm records → client-side cache layer version.” Following this order usually identifies the issue on the release day, without first suspecting the code.

Why can the old page still appear after refreshing the CDN?

The entry HTML filename stays fixed even though its content changes on every release; assets such as JS, CSS, and images usually distinguish versions through a content fingerprint in the filename. If these two types of files use the same cache rule, the chance of “refreshed but still old page” rises noticeably.

• Browser HTTP cache: when a strong cache hit occurs, no request goes back to the origin; only negotiated caching sends a validation request.
• CDN edge nodes: each keeps a copy according to its TTL; when there are many nodes, the effective window is fragmented.
• Service Worker: on sites that have installed offline caching, an old worker may respond with old files first.
• Mini program local packages and App built-in pages: mini programs have a local package update mechanism, while H5 pages embedded in an App follow the App version.
• User local storage: if configuration or gray release toggles are stored locally and the key has not changed, the behavior may still look like the old version.

The verification methods for these layers are completely different: for the browser layer, look at response headers; for the CDN layer, switching networks or devices can reproduce the difference; for the client-side layers, users need to update. Using the same “rebuild and upload” action to cover all symptoms is a major source of rework.

Checking from entry to assets saves more time than rebuilding

Check the entry first because it determines which files users will request next. If the entry still points to old assets, no amount of downstream refreshing will help. In delivery work, this order is usually more time-saving than digging through code directly.

1. Check the response headers of the entry HTML: look at Cache-Control and CDN rules. A common delivery practice is for the entry to use negotiated caching or a very short strong cache, with an experience range on the order of 0–5 minutes, ensuring a validation on every visit.
2. Check static asset fingerprints: JS, CSS, and images are named by content hash; when the filename changes, it is a new asset, so a long cache can be safely applied, with a typical range of 30 days to 1 year. At this step, confirm that build outputs really carry hashes—many people assume they do, but the filenames are actually fixed.
3. Check CDN refresh and prewarm: confirm whether the release process includes refreshing a directory or specified URLs. The time for a refresh to take effect is, by experience, on the order of minutes; projects with broad node coverage take longer.
4. Check client-side cache layers: whether the Service Worker version number has changed, whether the mini program triggers a version update prompt, and whether the App built-in package changes with the release.

Acceptance criteria can be defined this way: visit once in an incognito window, then visit again on a different network; only if both visits get the new version is this layer considered passed. Seeing the new version after refreshing only on your own computer cannot be the basis for declaring the release complete.

Effective windows and costs of several release configurations

There is no universal answer for cache strategy; the trade-off is mainly between “how quickly changes reach users” and “how fast repeat visits are.” The three approaches below are relatively common in 2026 projects and can be chosen according to how version-sensitive the business is.

• Negotiated caching for the entry + long caching for hashed assets: suitable for websites and H5 pages with frequent iterations and sensitivity to content freshness. By experience, the effective window after release is mostly on the order of 0–5 minutes; the cost is one extra negotiated request per visit.
• Short cache site-wide: suitable for early-stage projects with low release frequency that do not yet want to maintain asset hashes. The effective window is on the same order as the configured max-age, usually a few minutes; during that time, some users will still see the old page.
• Long cache site-wide + manual CDN refresh at release: suitable for teams with a fixed release window that can write the refresh into the process. Whether it takes effect depends on whether the refresh was actually done; if missed once, the old version may stay live for an experience range of several hours to several days, and that is where the risk concentrates.

The criterion is not which one is faster, but how long after release all users can get the new version without slowing down first paint. If the team does not yet have a release checklist, add the checklist first and then refine cache headers; reversing the order makes changes easy to lose control of.

Delivery scene: the cost of one old version staying live for two days

Similar situations are not rare in delivery work: budget and schedule are tight, the release script is carried over from the previous version, only the build directory is changed, and the cache headers of the entry HTML are not adjusted at the same time. After launch, users report that the page is not updated one after another. The frontend first suspects the build, rebuilds and releases again, but the symptom remains; only later, when the response headers show that the HTML still has a long strong cache time, is the root cause found. The cost is usually two meaningless releases, rework on the order of one to two days, and a batch of repeated communication on the customer service side, which falls within the typical range. Later, cache headers, asset hashes, CDN refresh, and client update prompts were written as four fixed items in the release checklist and executed in the same step as build and upload; this kind of issue largely stopped appearing in clusters in subsequent versions.

Applicable scenarios and boundaries

Cache layering pays off most clearly in projects that release to multiple clients at the same time and also use a CDN. For businesses where users are sensitive to “whether they are seeing the latest content,” such as campaign pages, price pages, and order and inventory pages, it is worth refining this chain.

• Suitable for: multi-client releases across website/H5/mini program/App built-in pages; has a CDN; relatively high iteration frequency; has requirements for gray release and rollback.
• Not necessary: one-off campaign pages, internal tools, small user bases with very low release frequency, or teams that currently do not have the energy to maintain release scripts.

The boundary can be understood this way: the value of a cache strategy is to make what should update update and what should be reused be reused. If the business itself is not sensitive to versions, or the content barely changes, the return on investing effort in checking four layers is limited; handle it with a simplified approach instead of standardizing for standardization’s sake.

Frequently asked questions

You see the new version locally, but users say it is not updated. What should you check first?

First visit once in an incognito window and once on another network. If both still get the old version, then check CDN refresh records and client-side cache layers.

Will negotiated caching for the entry HTML slow down first paint?

The impact is limited. When negotiated caching hits 304, the transfer size is very small, by experience mostly on the order of tens of milliseconds, usually smaller than the effect of differences in asset size.

After a mini program release, users still see the old interface. Is that also a cache issue?

The mechanism is different but related. Mini programs have local packages and version update policies, and users often need to restart or wait for the update. You can put a version prompt and a manual update entry in the page.

If static assets do not carry content fingerprints, is relying only on CDN refreshes enough?

It can work in the short term, but it easily leads to rework in the long term. When the filename does not change, old and new files have the same name, and the browser may continue to use the old copy. It is recommended to add content fingerprints during the build stage.

Write “cache headers, asset hashes, CDN refresh, client update prompts” into the release checklist and check them item by item on every release; this is usually more time-saving than investigating problems afterward. If the project is only a single-page static site without a CDN or offline caching, a simplified approach is enough. After launch, verify once in an incognito window and once on another network to confirm that the new version has really reached users.