Heuristic cache

Heuristic caching is the default behavior of browser caching (i.e., for responses without Cache-Control), which is not simply "not caching", but implicitly caching based on the so-called "heuristic cache". HTTP is designed to cache as much as possible, so even if Cache-Control is not specified, the response will be stored and reused if certain conditions are met. This is called heuristic caching.

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
Last-Modified: Tue, 22 Feb 2021 22:22:22 GMT

Cache duration

The formula for calculating the cache duration can be simplified as below

(Date - Last-Modified) * 0.1

• Date: The time of the current request.
• Last-Modified: The date when the resource was last modified on the server.

According to MDN, content that has not been updated for a whole year will not be updated for some time after that. Therefore, the client stores this response (even without max-age) and reuses it for a period of time. The length of time for reusing the response depends on the implementation, but the specification recommends storing it for approximately 10%(0.1 year in this case) of the time after it has been stored.

This means that if a resource has not been updated for ten days, it will be cached for one day. During this time, the browser requests will use the local cache, and beyond this time, the browser will request the resource from the server.

Heuristic caching is a solution that appeared before Cache-Control was widely adopted, and basically all responses should explicitly specify the Cache-Control header now.

Full understanding

This might be a bit confusing, so let's break it down. How long will the default caching time be, and how is it determined?

If a file has no cache strategy specified, the browser will use heuristic caching by default.

Next, we need to look at the Date and Last-Modified information in the response header of the file. These two times are the key factors that determine whether the browser will request the server or use the local cache after the next page refresh. Note that this is for the next request.

The response header of the current request (Date - Last-Modified) * 0.1 determines the length of time that the file will be cached. For example, if the difference between Date and Last-Modified is （2023-04-13 - 2023-03-09）35 days (ignoring the specific time of day), then the file will be cached for approximately 3.5 days. If the user requests this file within the next 3.5 days, the browser will retrieve it from the local cache. If it has been more than 3.5 days since the file was cached, the browser will request the resource from the server instead of using the cache.

As long as the Last-Modified (last modification time of the file) remains unchanged, the cached time of the resource will become longer as time goes on.

In cases where the difference between Date and Last-Modified is shorter, developers might experience confusion when testing heuristic caching. They might not be able to see the effect of heuristic caching. To properly analyze and judge heuristic caching, all you need to do is follow the calculation method mentioned above and break it down step by step.

Let's take the same file again. Suppose the server modifies the content of the file, and the difference between Date and Last-Modified is only 27 seconds. This means that the file will only be cached for 2.7 seconds. Since we just modified the content on the server, we need to force a refresh to get the latest file, which means that the request will be sent to the server instead of using the local cache. Therefore, we cannot see the effect of heuristic caching using a forced refresh. To see the effect, we need to modify the content of the file on the server again and then use a regular refresh to see if the file is using heuristic caching.

After modifying the server resource again and refreshing the page, we can see that config.js is still requesting the server resource. This means that it is not using the cache. If it were using the cache, the Size column would show disk cache or memory cache. This is because the Date and Last-Modified of the previous request determined whether the next request will use the cache. In this case, the previous request only cached the file for 2.7 seconds, and since we took more than 2.7 seconds to refresh the page after modifying the server resource, the browser had to request the file from the server again.

Therefore, when testing heuristic caching, it is important to try to increase the difference between Date and Last-Modified to see the effect.

For example, if we increase the difference to 16 minutes, the file will be cached for approximately 90 seconds (49 - 33) * 0.1.

During this period of time, if we modify the resource on the server and refresh the page, we will see that config.js is using the cached version instead of requesting the server resource. However, we should note that during this caching time, we will not be able to see the latest content on the server, so it is important to configure negotiated caching for system configuration files.