After a release the homepage updated but detail pages still look old — is it an un-purged CDN or unchanged filenames?

After a release, the homepage has already changed, but clicking into a detail page still shows the old styles — don't rush to purge the CDN first. Based on 2026 project delivery experience, when the entry HTML has a new version but secondary pages still show old styles, it's usually not that users failed to clear their cache manually; more often the static asset filenames referenced by that page don't change with the content, or the page bypasses the main build pipeline, so the browser and edge nodes keep hitting the old copy. The order of diagnosis should move from the layer closest to the user toward the server: first check whether the request is even being sent and what the response headers say, then decide whether the CDN needs purging.

1. First determine which layer the homepage vs. secondary page difference comes from

When the same style bundle is referenced by all pages, a release should take effect site-wide. When only a few pages look old, there are three common sources of the difference: first, route-level code splitting, where the secondary page corresponds to its own chunk whose filename carries no content hash; second, the secondary page is a legacy standalone static file that never entered the build pipeline at all; third, the page separately pulls in a third-party script or font that got held by that layer's cache.

Another easily misjudged case: the secondary page's data comes from an API, and the API response is cached by the browser or gateway — the page structure is new but the content is old. To tell them apart, check element-level styles first, then the text content; the two can distinguish a resource caching problem from an API caching problem.

• Styles and content both old: most likely HTML or a whole bundle hit strong cache.
• Styles changed, content old: investigate the API response cache and gateway proxy_cache.
• Only one specific page old: first check whether that page's chunk carries a content hash and goes through the build.

2. Strong caching vs. revalidation caching: first determine which type applies

Strong caching is controlled by Cache-Control's max-age or Expires. Once hit, the browser uses the local copy directly within the validity period, requests never reach the server, and there's no trace in server logs. Revalidation caching is controlled by ETag and Last-Modified: the browser sends a request every time, and the server returns 304 before the local copy is reused.

For release-not-taking-effect issues, the trouble with strong caching is that the server cannot revoke it within the validity period. Based on common 2026 practice:

• Content-hashed assets: CSS, JS, images and fonts can use long strong caching, typical range 30 days to 1 year; when content changes, the filename changes.
• Entry HTML: use no-cache, or keep max-age within 0–60 seconds, so each visit can fetch fresh asset references.
• API responses: don't apply long strong caching by default; when needed, control it with a business version field rather than relying on Cache-Control alone.

One more reminder: filenames that don't change are harder to deal with than long cache times. If the content changed but the filename is still app.js, both the browser and the CDN treat it as the same file and keep using the old copy until the strong cache naturally expires. As long as the filename changes with the content hash, even a very long cache time is fine — the next time the user loads the new HTML, it will reference the new files.

3. Locate layer by layer in a five-layer order

This order goes from closest to the user to farthest, and each layer has a verification method, so you avoid starting with the most expensive operation. Most projects can pinpoint the cause at layer two or three; you don't have to walk all five.

1. Browser HTTP cache: have the user open an incognito window, or check disable cache in DevTools. If it looks normal, the problem is the local strong cache — go back and fix the asset policy itself.
2. Service Worker or offline cache: if the site has registered a Service Worker, it intercepts requests and returns its own cached copy, and clearing the browser cache may not help. You need to bump the cache version in code and handle uninstalling the old version.
3. CDN edge nodes: accessing over a different network or from a different region producing different results means node caches are inconsistent. Submit a purge according to the CDN console rules, and note that purges often take several to a dozen minutes to take effect.
4. Intermediate Nginx or gateway cache: check whether proxy_cache is enabled and whether the cache key includes a version or hash. Enabling cache without an invalidation condition is an easily overlooked layer.
5. Backend template or SSR output: server-rendered HTML can also output stale structure if it's written into a local cache or fragment cache; verify whether the rendering layer invalidates by version.

The key to diagnosis is confirming whether the request actually reaches the server. Skipping steps usually means purging caches in circles while the problem remains.

4. Comparing several approaches, chosen by project size

There's more than one way to handle this, and the cost difference is significant. Based on common 2026 delivery experience, mid-to-large public-facing sites suit a combination of short entry cache + asset content hashing + CDN purge; small projects or internal systems can get by with something simpler and don't need a full release chain.

• No entry cache + asset content hashing: suits public-facing sites, mobile H5 and single-page apps; the rework cycle is typically 1–3 person-days, involving build configuration and gateway cache headers; long-term maintenance cost is low, and it's the default approach in most cases.
• Version parameter in the URL: suits small sites with few static pages and a simple build process; the initial change is typically under half a day, but the version parameter must be maintained manually, and with many pages it's easy to miss updates.
• Directory-level switching: suits full-site redesigns or scenarios needing canary comparison; switching is clean, but the old directory must be kept, consuming storage, and a decommission date should be agreed in advance.
• In-page refresh prompt: only a fallback, not a primary solution; somewhat helpful for long-tail users unwilling to upgrade, but the experience is mediocre.

On delivery sites, the common situation is: budget and timeline are tight, the client wants one launch to solve all caching problems, but old pages have already gone out and old files are still on edge nodes. The more reliable approach is to first change entry HTML from long strong caching to revalidation caching, then add content hashes to asset filenames, and submit a CDN purge at the same time. The trade-off is keeping old files for a while for rollback, and verification and revisions within one release cycle will likely take about half an iteration; if CDN purges require an approval process, the release window has to be scheduled even earlier. When implementing this kind of change, Xiyue Company typically confirms the purge approval and rollback path first, then touches the cache headers.

5. When it applies, and when a complex solution isn't necessary

The premise of layered caching is that assets change frequently and the client-side version is uncontrollable. That premise holds for public-facing sites with a CDN, mobile H5, and pages hosted in WebViews. Conversely, a purely intranet management system has fixed users, releases can be scheduled, and it doesn't go through a CDN — having users do a hard refresh is enough; introducing a full hashing pipeline only adds release burden.

Two other categories are best kept simple: first, services centered on backend APIs don't produce static assets themselves, so cache governance focuses on API responses and the gateway, not front-end files; second, showcase sites with only a few static pages are easier to version manually in filenames than to wire up a build. The criterion can be simplified to one sentence: if the client-side version is uncontrollable and assets change frequently, do layering; if either is missing, record the current state first and only rework after real complaints appear — there's no need to build a complex chain in advance.

FAQ

Should entry HTML really be set to no-cache?

Use no-cache (revalidation caching), or keep max-age within 0–60 seconds. Setting a one-year strong cache means every release has to wait for user caches to expire.

Asset filenames have hashes, so why do some users still say the page didn't update?

Most often the entry HTML is still under strong caching, so users get the old HTML and naturally reference the old filenames. Check the entry file's cache headers first, then confirm the hash actually changes with content.

Opening in WeChat never updates — is that the same as browser caching?

Not exactly. The in-app browser's caching policy is more conservative and its entry is harder to clear, so the two basics — revalidation caching for entry HTML and content hashes in asset names — need to be solidly in place first.

After a problem, is one CDN purge enough to fix everything?

Not necessarily. A CDN purge only affects the edge node layer; strong-cached copies in the user's browser remain. Only when the entry is switched to revalidation caching will the next visit actually get the new entry.

Only the secondary page is old — can I purge just that page's cache?

Yes, but first confirm whether that page's assets carry content hashes. If the filenames haven't changed, the purge will quickly be cached back to the old content — that's a stopgap.

If your site has a CDN, releases frequently, and the client-side version is uncontrollable, prioritize switching entry HTML to short or revalidation caching, then fill in asset content hashes — these two steps cover most stale-page reports. If assets rarely change and users are concentrated in a controllable environment, record the current state first and rework after real complaints appear.