Detailed Explanation of Browser Caching Mechanism and Caching Strategies

Browser caching is a crucial aspect of front-end performance optimization. It reduces network requests and improves page loading speed. This article will systematically explain the classification, working principles, and common strategies of browser caching.

1. The Role and Classification of Caching

1. Role

   • Reduce bandwidth consumption
   • Decrease server load
   • Accelerate page loading speed

2. Classification

   • Strong Cache: Uses local cache directly without sending a request to the server.
   • Negotiation Cache (Conditional Requests): Sends a request to the server to validate if the resource is stale. If not modified, the server returns a 304 status code, and the local cache is used.

2. Strong Cache Mechanism

Strong cache is implemented through the following two HTTP headers:

1. Expires (HTTP/1.0)

• Value is an absolute time (e.g., Expires: Wed, 21 Oct 2025 07:28:00 GMT).
• Disadvantage: Relies on client time; inaccurate time can cause cache invalidation.

2. Cache-Control (HTTP/1.1, takes precedence over Expires)

• Common directives:
  • max-age=3600: Cache the resource for 1 hour (relative time, solving the Expires issue).
  • no-cache: Disables strong cache, forcing negotiation cache.
  • no-store: Completely prohibits caching (used for sensitive data).
  • public: Allows proxy servers to cache the resource.
  • private: Only allows the browser to cache (default value).

Example Flow:

Browser requests resource → Checks Cache-Control's max-age  
    ↓  
If not expired → Uses cache directly (Status code 200 from cache)  
    ↓  
If expired → Proceeds to negotiation cache flow  

3. Negotiation Cache Mechanism

When the strong cache expires, the browser sends a request to the server with cache identifiers to validate if the resource has been updated.

1. Last-Modified and If-Modified-Since

• The server adds Last-Modified (last modification time) when returning the resource.
• The browser includes If-Modified-Since in subsequent requests. The server compares the times:
  • Times match → Returns 304 (Not Modified)
  • Times differ → Returns 200 with the new resource

2. ETag and If-None-Match (takes precedence over Last-Modified)

• The server generates a unique identifier (e.g., a hash) for the resource and returns it via ETag.
• The browser includes If-None-Match in subsequent requests. The server compares the ETags:
  • Match → Returns 304
  • Differ → Returns 200 with the new resource

Why is ETag needed?

• Addresses the limitations of Last-Modified:
  • File content unchanged but modification time changed (e.g., repeated saves).
  • Modifications on a sub-second scale cannot be detected.

4. Caching Strategy in Practice

1. Static Resources (e.g., JS, CSS, images)

• Set Cache-Control: max-age=31536000 (one year) for strong caching.
• Implement resource updates via filename hashing (e.g., app.a3b4c5.js), ensuring the URL changes when content changes, triggering a fresh fetch.

2. HTML Files

• Set Cache-Control: no-cache to prevent long-term caching of page structure.

3. Dynamic APIs

• Use Cache-Control: no-store for APIs requiring high data consistency.

5. Impact of User Actions on Caching

1. Normal Refresh → Triggers negotiation cache (may bypass strong cache).
2. Force Refresh (Ctrl+F5) → Ignores all caches and requests directly from the server.
3. Address Bar Enter/Return → Prioritizes using strong cache.

6. Summary

• Strong cache is controlled by Cache-Control and Expires, with the former having higher priority.
• Negotiation cache is implemented via Last-Modified/If-Modified-Since or ETag/If-None-Match.
• In real-world projects, caching strategies must be designed based on resource types, combined with filename hashing to solve cache update issues.