You're right that browser caching has a few tricky parts, which is why we do a some things differently. What you describe is an HTTP revalidation (If-None-Matc

You're right that browser caching has a few tricky parts, which is why we do a some things differently. What you describe is an HTTP revalidation (If-None-Match, If-Modified-Since) which the browser triggers in two cases: -if the TTL defined in the Cache Control header has expired -or if the user hits F5 In the normal case where a user revisits a site, the browser takes all the cached resources without doing a revalidation and that is the case one should optimize for. The cases you seemed to have in mind is explicit refreshes (F5), expired cache entries, or servers that respond with a max-age=0 header (which is useful in many situations). The most difficult part when caching dynamic data is purging stale content from browser caches. Because if the TTL is too high and the content changes ealier, users will see stale cached data. At Baqend we solve this problem by piggybacking a Bloom filter of potentially stale URLs to the client [1]. The client checks the Bloom filter to determine whether to do a revalidation or use the cache. In order for the Bloom filter to remain small, we have a learning TTL Estimator that calculates TTLs by approximating the expected time to the next write. [1] https://medium.baqend.com/announcing-availability-of-baqends-unique-client-caching-technology-dbd9b026dc20#.d2x2zbbfe https://medium.baqend.com/announcing-availability-of-baqends...