如何强制缓存的 web 页面资产在 2023 年重新加载

Question

Old Cache Buster techniques I have found to date are:

1. Query String in the link src: /mstylesheet.css?cache_buster=12345
2. Change the filename each time: /mstylesheet-12345.css
3. Apache: Cache-Control "must-revalidate" in conjunction with no-cache

I've noticed problems with all of these where stubborn Browser caches refuse to get updated assets?

If I've understood correctly, the browser cache appears to treat the following URLs as completely different entities?

• /mstylesheet.css
• /mstylesheet.css?cache_buster=12345
• /mstylesheet.css?cache_buster=54321

So the question is: Would the following javascript work to force an existing stylesheet, linked via a link tag, without a cache buster query string, to be updated in the browser cache?

fetch("/mstylesheet.css",{ method: "GET",headers: {"Cache-Control": "no-cache"}});

(I'd want to have this run a one off every now and then. Not on every page load).

Answer 1

From Referrer and cache control APIs for fetch() , you want either reload or no-store to bypass the locally stored cache:

  // Download a resource with cache busting, to bypass the cache
  // completely.
  fetch("some.json", {cache: "no-store"})
    .then(function(response) { /* consume the response */ });

  // Download a resource with cache busting, but update the HTTP
  // cache with the downloaded resource.
  fetch("some.json", {cache: "reload"})
    .then(function(response) { /* consume the response */ });

This is still valid in 2023. However, the real question is whether you want to support older browsers or older or misbehaving servers which may not support these directives. A server can choose to ignore these headers or a service worker can choose to not forward your request to the server in the first place. Presumably, you're in control of both of these, so they wouldn't be an issue, but it's still worth mentioning that these standards always rely on all parts of your app and stack using them correctly.

If I've understood correctly, the browser cache appears to treat the following URLs as completely different entities?

This is correct. At the very least, the full URL is used as the cache key. Other things may be added to the key and Chrome implemented cache partitioning meaning that different origins usually don't share their cache, even if it's the exact same URL.