HTTP Caching Demystified: Strong Cache, Negotiated Cache, and Front-End Caching Strategies

In the previous article on HTTP evolution, we mentioned the two cache validation mechanisms introduced in HTTP/1.1 — Last-Modified / If-Modified-Since and ETag / If-None-Match. But the focus there was on "the evolution of the HTTP protocol itself" — caching was only mentioned in passing.

In practice, however, caching may be the only aspect of HTTP you directly interact with on a daily basis. User reports that "the page didn't update" after a deployment? Nine times out of ten, the caching configuration is wrong. Filename hashes in your build tool output? They're not for aesthetics — they exist to make caching work correctly. CDN purging, hard reloads, force refreshes — all of these everyday actions are about wrestling with HTTP caching.

This article starts from the browser's complete cache decision tree and systematically breaks down the two-tier HTTP caching system — strong cache and negotiated cache — along with their practical applications in front-end engineering.

• Understand the complete browser cache decision flow — when does the browser skip the request entirely, and when does it send a request but skip the body
• Master the two implementations of strong caching: Cache-Control and Expires
• Master the two implementations of negotiated caching: ETag / If-None-Match and Last-Modified / If-Modified-Since
• Understand the difference between no-cache and no-store — the single most confusing interview question on this topic
• Master the relationship between front-end build tool (Webpack/Vite) filename hash strategies and caching
• Use Chrome DevTools to determine which caching strategy a resource is using

• Understand HTTP/1.1's basic request-response model and header field mechanism

You've deployed a new React project to production. A user visits app.example.com for the first time, loading main.js, vendor.js, and style.css. They leave the page, then return five minutes later. This time, are those three files re-downloaded, or are they served from the local cache?

The answer depends on your caching configuration. If you haven't configured anything (no Cache-Control header), the browser uses heuristic caching — estimating freshness lifetime based on the difference between the Last-Modified time and the current time. This essentially means "behavior varies by browser," and you shouldn't rely on it.

A more common scenario: your CI/CD pipeline adds a content hash to every JS filename (e.g., main.abc123.js). The user downloads main.abc123.js on their first visit. You fix a bug, redeploy, and the filename becomes main.def456.js. The user visits again — is the old abc123 still usable from cache? How does the new def456 get loaded? This is the core challenge of front-end caching strategy.

Let's start with the browser's cache decision flow.

When the browser is about to initiate an HTTP request, it first checks the local cache. Here's the decision process:

Two major branches:

• Strong cache: The cached copy is still fresh — don't even send a request, just use the local copy. Appears as 200 (from disk cache) or 200 (from memory cache).
• Negotiated cache: The cached copy has expired, but send a conditional request asking "has this resource changed?" If unchanged, the server returns 304 Not Modified (no body). If changed, it returns 200 with the new content.

The core idea of strong caching: for a certain period, this resource definitely won't change — don't bother asking me.

Cache-Control was introduced in HTTP/1.1 and is the standard way to control caching today. The vast majority of caching behavior on the web is defined by it.

Core directives:

no-cache vs no-store — the most confusing interview question:

A handy way to remember: no-cache = "cache with revalidation"; no-store = "don't cache at all."

Real-world use cases:

Why should the HTML entry file use no-cache? Because the HTML references main.abc123.js. If you change your code, the JS filename becomes main.def456.js — but if the user's browser has the old HTML cached (still referencing abc123), they'll never load the new JS. no-cache makes the browser ask the server every time: "Has the HTML changed?" If yes, it gets the new HTML (referencing def456, then the browser downloads the new JS). If unchanged, it uses the local copy.

Expires is a relic from the HTTP/1.0 era, using absolute timestamps:

It has one fatal flaw: it depends on clock synchronization between client and server. If the user's computer clock is one hour behind the server's, this cache "lives" an extra hour. In contrast, Cache-Control: max-age=N uses relative time (N seconds), independent of clock drift, making it far more reliable.

When both Cache-Control and Expires are present, Cache-Control takes precedence.

Open Chrome DevTools → Network panel, look at the Size column:

• (disk cache) / (memory cache): strong cache hit — no request was made
• A specific number (e.g., 245 KB): data went over the network — either a negotiated cache hit (304) or a full download (200)

You don't need to control memory cache vs disk cache — the browser decides where to store resources. Rough rule of thumb: large resources like images and fonts go to disk cache; Base64 inline images and small JS snippets go to memory cache.

The problem with strong caching: if you set max-age=86400 (one day) but push an emergency bug fix mid-day, all users with unexpired caches won't get the fix.

Negotiated caching solves this: let the cache expire, but don't throw it away — take its "fingerprint" to the server and ask: "Is the version matching this fingerprint still valid?"

ETag (Entity Tag) is a content-based version identifier. The server assigns a unique string to each version of a resource:

ETag generation strategy depends on the server implementation:

• Nginx: defaults to hashing the file's last-modified time + content-length
• Apache: defaults to using the file's inode + size + last-modified
• Express (etag middleware): defaults to an MD5 hash of the content

Key point: ETag depends on content, not time. If you change a file's content and then revert it (e.g., git checkout to an older version), the ETag reverts too. Last-Modified can't do that — if the file gets touched, the timestamp changes even though the content didn't.

Another negotiation mechanism, based on time rather than content:

Last-Modified has two shortcomings:

1. Second-level precision only: if a file is modified twice within the same second (e.g., automated deployment writes two versions within 1s), Last-Modified can't distinguish them, and the browser may serve stale content.

2. False modification triggers cache invalidation: the file content hasn't changed, but the mtime (modification time) has — for example, when CI re-clones a repository, all file mtime values get updated. The browser thinks the files changed when they actually didn't.

This is why ETag is the recommended approach for negotiated caching, with Last-Modified as a fallback. When both are present, the browser sends both conditional headers, and the server prioritizes ETag for the decision.

Combining strong cache and negotiated cache, here's the complete flow for a resource request:

1. Browser checks local cache → if no cache → direct request (200)
2. If cached → check Cache-Control: max-age or Expires
3. If strong cache hit (still fresh) → use directly, no request (200 from cache)
4. If strong cache miss (expired or no-cache) → send conditional request
5. Server checks ETag / Last-Modified
   • Resource unchanged → 304 Not Modified, browser uses local cache, refreshes freshness
   • Resource changed → 200 OK, returns new resource, browser updates cache

Front-end build tools (Webpack, Vite, esbuild) offer three hash modes:

Recommendation: [contenthash] — only when the file's own content changes does its hash change. This is the foundation of immutable caching:

The key logical chain:

1. JS filename carries content hash → URL changes with content
2. Resources with unchanged content have an eternal URL → safe to set max-age=31536000 (one year)
3. Resources with changed content get a new URL → browser treats it as a brand-new request, never serves stale cache

This is the standard combination in modern front-end deployment:

Why is this combination safe?

• HTML is not cached aggressively: users always get the latest HTML, and the JS/CSS URLs referenced inside are always correct (because hashes change with content)
• JS/CSS are cached forever: when the URL changes, the browser automatically re-downloads (the old URL with the old version is never referenced again, so the stale cache naturally evaporates)
• No "page didn't update" bugs: HTML → new JS URL → browser downloads new JS (even if the old JS is still in cache, nobody references it anymore)

A CDN sits as a caching layer between users and your origin server. When coordinating your assets with CDN caching:

• Content-hashed filenames → high CDN cache hit rate (same URL always returns same content)
• No content hash → requires fine-grained CDN cache rules and purge strategies
• When purging CDN caches, send Cache-Control headers to update browser caching behavior as well

1. Open Chrome DevTools → Network, visit a popular website. Identify which resources hit (disk cache) / (memory cache) and which resulted in 304 requests.
2. Use curl -I https://example.com/main.css to inspect response headers and identify Cache-Control, ETag, and Last-Modified configurations.
3. Build a simple Express server. Configure Cache-Control: max-age=60 and ETag separately, then observe behavioral differences on the second and third visit in the browser.
4. In a Webpack or Vite project, set output.filename to [name].js and [name].[contenthash].js respectively, deploy, and observe the caching behavior differences.
5. Thought experiment: why can't index.html use immutable? What would happen if your SPA entry HTML were cached for a year?

• Browser caching has two tiers: strong cache (no request sent) and negotiated cache (request sent, but body may be skipped)
• Cache-Control: max-age=N is the standard way to implement strong caching; Expires is obsolete
• no-cache ≠ don't cache — it means "cache but validate every time"; no-store truly means "don't cache"
• For negotiated caching, prefer ETag / If-None-Match (content-based) over Last-Modified (second-level precision only)
• Front-end best practice: HTML with no-cache, JS/CSS with content hash + max-age=31536000, immutable
• Filename hashing is the prerequisite for safely using permanent caching — content changes → URL changes → automatic new version loading

This article focused on the core practice of HTTP caching in the browser and in front-end engineering. But there's another crucial piece to the caching puzzle — CDN and reverse-proxy layer caching, including s-maxage, stale-while-revalidate, the practical uses of the Vary header, and how the Service Worker Cache API lets front-end developers take full control of caching logic.

In the next article, we dig deeper into caching — CDN and reverse-proxy layer caching strategies, including how s-maxage issues different directives to CDN vs. browser, how stale-while-revalidate enables "serve stale while refreshing", the Vary header for response differentiation, and how the Service Worker Cache API lets front-end developers take full control of caching logic.