For how much time can I cache API responses using the Cache API?

Hi, using the Workers Cache API, I’d like to cache responses permanently. Is that possible? Or is there a maximum of time?

How can I cache responses permanently?

    // Cache API respects Cache-Control headers.
    // Setting `s-maxage=10` will limit cache lifetime to 10 seconds
    // Any changes made to the response here will be reflected in the cached value
    response.headers.append("Cache-Control", "s-maxage=10");

Should I just basically do s-maxage=999999999999999999999999999 ?

if anyone interested: i read the maximum limit is 1 year

1 Like

Keep in mind that the cache setting really is a maximum of time it’s safe to cache something. It will most likely be evicted much earlier than that.

I’ve not seen anybody brag about a record amount of time something’s been cached here, but it’d certainly be interesting to find out.

1 Like

You can’t, CF will evict if the asset isn’t used eventually. You could set a long browser cache TTL and try to keep the asset in visitor’s browser cache. If you want more control in visitor’s browser cache, then look at service worker caching (not same as cf worker caching or browser HTTP cache) Essentially service worker would sit in visitor’s browser as a proxy in such instance if you configure the service worker using a cache first strategy and only travel over the network if you need to revalidate.

Service worker caching #

A service worker intercepts network-type HTTP requests and uses a caching strategy to determine what resources should be returned to the browser. The service worker cache and the HTTP cache serve the same general purpose, but the service worker cache offers more caching capabilities, such as fine-grained control over exactly what is cached and how caching is done


Additional benefits of service worker caching #

In addition to fine-grained control of caching logic, service worker caching also provides:

  • More memory and storage space for your origin: The browser allocates HTTP cache resources on a per-origin basis. In other words, if you have multiple subdomains, they all share the same HTTP cache. There is no guarantee that the content of your origin/domain stays in the HTTP cache for a long time. For example, a user may purge the cache by manually cleaning up from a browser’s settings UI, or triggering a hard-reload on a page. With a service worker cache you have a much higher likelihood that your cached content stays cached. See Persistent storage to learn more.
  • Higher flexibility with flaky networks or offline experiences: With the HTTP cache you only have a binary choice: either the resource is cached, or not. With service worker caching you can mitigate little “hiccups” much easier (with the “stale-while-revalidate” strategy), offer a complete offline experience (with the “Cache only” strategy) or even something in between, like customized UIs with parts of the page coming from the service worker cache and some parts excluded (with the “Set catch handler” strategy) where appropriate.