Browser Default Cache Freshness | Things About Web Development

Browser caching is a powerful mechanism for improving web performance by storing copies of resources locally, reducing the need for repeated network requests. To manage caching behavior, developers commonly use headers like Cache-Control, ETag, and Last-Modified. These headers inform browsers whether a resource is "fresh" and when to fetch an updated version.

One critical concept in caching is cache freshness—the process by which browsers determine whether a cached resource is still valid. According to RFC 7234 Section 4.2.2, browsers use specific heuristics to calculate freshness when explicit caching rules are not provided.

cache freshness -- dealing with very old resources

How Browsers Determine Resource Freshness by Default

When a resource includes a Last-Modified header, browsers can use the time since the resource was last modified to compute a heuristic expiration time. RFC 7234 suggests the following approach:

If the response has a Last-Modified header, caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that time. A typical setting for this fraction might be 10%.

While this heuristic provides a simple guideline, the RFC emphasizes that it is a recommendation, not a mandate, and browser implementations can vary.

How Major Browsers Handle Cache Freshness

Here's how popular browsers implement cache freshness logic:

Chrome and Safari: Follow the RFC-recommended 10% rule.
Firefox: Also uses the 10% rule but applies a maximum cap of one week. This means that even if a file was last modified years ago, Firefox will treat it as fresh for no longer than one week.

The default behavior can pose challenges for developers, especially when updating resources that haven't been modified for a long time or are rarely changed. For instance:

A CSS file (style.css) modified 10 years ago might be considered fresh for up to 1 YEAR by Chrome and Safari. This could lead to users seeing outdated styles until the cache expires.
In Firefox, though the same file would be treated as fresh for a maximum of 1 week, it might still be too long in some scenarios.

Solutions to Control Cache Behavior

To address these challenges, developers often take explicit measures to ensure that updates reach users promptly. Here are some common techniques:

Versioned URLs: Append version identifiers or hashes to resource URLs. This creates unique URLs for updated resources, bypassing cached versions. Example:
```
<link rel="stylesheet" href="style.css?v=12345">
```
When the file changes, you update the version query parameter (e.g., ?v=12346).
Cache-Control Headers: Use explicit Cache-Control directives to control how long resources are cached. Examples:
- Prevent caching:
```
Cache-Control: no-cache
```
- Set a specific expiration time:
```
Cache-Control: max-age=3600
```
ETag Validation: Utilize ETag headers to allow browsers to validate cached resources with the server. Example:
```
ETag: "abc123"
```
The server sends a 304 Not Modified response if the resource has not changed.

Key Takeaway

When updating legacy or rarely modified resources, it is especially important to pay attention to those without explicit cache rules, as browser defaults may cause users to see outdated content for extended periods.