2

With caching headers I can either make the client not check online for updates for a certain period of time, and/or check for etags every time. What I do not know is whether I can do both: use the offline version first, but meanwhile in the background, check for an update. If there is a new version, it would be used next time the page is opened.

For a page that is completely static except for when the user changes it by themselves, this would be much more efficient than having to block checking the etag every time.

One workaround I thought of is using Javascript: set headers to cache the page indefinitely and have some Javascript make a request with an If-Modified-Since or something, which could then dynamically change the page. The big issue with this is that it cannot invalidate the existing cache, so it would have to keep dynamically updating the page theoretically forever. I'd also prefer to keep it pure HTTP (or HTML, if there is some tag that can do this), but I cannot find any relevant hits online.

A related question mentions "the two rules of caching": never cache HTML and cache everything else forever. Just to be clear, I mean to cache the HTML. The whole purpose of the thing I am building is for it to be very fast on very slow connections (high latency, low throughput, like EDGE). Every roundtrip saved is a second or two shaved off of loading time.

Update: reading more caching resources, it seems the Vary: Cookie header might do the trick in my case. I would like to know if there is a more general solution though, and I didn't really dig into the vary-header yet so I don't know yet if that works.

Luc
  • 5,339
  • 2
  • 48
  • 48

1 Answers1

1

Solution 1 (HTTP)

There is a cache control extension stale-while-revalidate which describes exactly what you want.

When present in an HTTP response, the stale-while-revalidate Cache- Control extension indicates that caches MAY serve the response in which it appears after it becomes stale, up to the indicated number of seconds.

If a cached response is served stale due to the presence of this extension, the cache SHOULD attempt to revalidate it while still serving stale responses (i.e., without blocking).

cache-control: max-age=60,stale-while-revalidate=86400

When browser firstly request the page it will cache result for 60s. During that 60s period requests are answered from the cache without contacting of the origin server. During next 86400s content will be served from the cache and fetched from origin server simultaneously. Only if both periods 60s+86400s are expired cache will not serve cached content but wait for origin server to fresh data.

This solution has only one drawback. I was not able to find any browser or intermediate cache which currently supports this cache control extension.

Solution 2 (Javascript)

Another solution is usage of Service workers with its feature to make custom responses to requests. With combination with Cache API it is enough to provide the requested feature.

The problem is that this solution will work only for browsers (not intermediate caches nor another http services) and even not all browsers supports Services workers and Cache API.

Community
  • 1
  • 1
Tomas
  • 1,531
  • 1
  • 16
  • 22