X078 How Content-Hashed Filenames (app.8f92a.js) and Cache-Control: immutable Make Repeat Visits Load in 0ms
The 304 Revalidation Tax: Why Your “Cached” Website is Still Slow
Web performance discussions are obsessed with initial page load metrics: Time to First Byte (TTFB), First Contentful Paint (FCP), and Largest Contentful Paint (LCP). Teams spend weeks optimizing bundle sizes and tuning CDN edge locations.
Yet for any successful SaaS application, e-commerce storefront, or content publication, over 70% of daily pageviews come from repeat visitors.
What happens when a repeat visitor clicks a link or hits the refresh button on your site?
If your server delivers assets with naive caching headers like Cache-Control: max-age=3600, the browser does not load the page instantaneously. Instead, it enters a round-trip negotiation with your server known as conditional revalidation:
THE 304 NOT MODIFIED CONDITIONAL TAX
- Repeat Visitor Clicks “Refresh” (F5): Browser Has /assets/app.js in local disk cache (Expires in 45 minutes)
- Browser Thinks: “Did the file change on the server? I must revalidate!”
- Browser GET /assets/app.js (If-None-Match: “etag-9182a”) → Nginx
- Nginx inspects disk inode → Matches ETag → Emits HTTP 304
- Browser → HTTP/2 304 Not Modified (Incurs 45ms Network RTT!)
- Repeat visit took 150ms just waiting for 20 unnecessary 304 round-trips!
Even though the payload body was not retransmitted, the browser still waited for a full network round-trip time (RTT) for every single stylesheet, JavaScript chunk, and SVG icon on the page. On a mobile connection with 80ms latency, 15 asset revalidations delay page rendering by hundreds of milliseconds.
The deterministic engineering solution is pairing Content-Hashed Filenames with Cache-Control: public, max-age=31536000, immutable.
At our engineering studio, our high-performance websites and fast static websites implement this dual caching architecture to deliver genuine 0ms repeat page loads.
The Two-Tier Caching Architecture: Mutable HTML vs. Immutable Assets
To achieve zero-millisecond reloads without risking stale code caching, you must divide your web assets into two strictly segregated categories:
THE DUAL-TIER CACHE SPLIT PATTERN
- TIER 1: THE ENTRYPOINT (index.html)
- Header: Cache-Control: no-cache
- Always revalidates with server (Takes ~10ms for tiny 5KB HTML)
- References the latest hashed bundles:
[+] [ INDEX_DIRECTORY ] 15 topics ▼
- The 304 Revalidation Tax: Why Your “Cached” Website is Still Slow
- The Two-Tier Caching Architecture: Mutable HTML vs. Immutable Assets
- How the Contract Works:
- What Happens During a Production Deployment?
- Configuring Nginx for 0ms Immutable Caching
- Edge CDN Integration: Cloudflare & Reverse Proxies
- Audit Your Cache in DevTools: The “from disk cache (0 ms)” Proof
- Author
- Frequently Asked Questions
- What is content hashing in modern frontend build tools?
- What does the immutable directive in Cache-Control actually do?
- Why must index.html NEVER be served with Cache-Control: immutable?
- How does immutable caching reduce server CPU and bandwidth on Nginx?
- Related Nodes
- Path Sequence
[ SYSTEM.FAQ ]Frequently Asked Questions
What is content hashing in modern frontend build tools?
Content hashing is the build-time technique of calculating a cryptographic checksum (such as SHA-256 or xxHash) of a file's compiled contents and appending that digest directly into the filename (e.g., `main.c83a1b.js`). If a single byte of source code changes, the filename changes; if the source code is untouched, the filename remains identical across deployments.
What does the immutable directive in Cache-Control actually do?
Introduced in RFC 8246, `Cache-Control: public, max-age=31536000, immutable` instructs the web browser that the file's contents will never change during its valid lifetime. Even when a user clicks the browser 'Refresh' button (F5), the browser completely bypasses the network, serving the asset directly from disk or memory cache in 0ms without sending conditional `If-None-Match` (304) requests.
Why must index.html NEVER be served with Cache-Control: immutable?
The entry HTML document (`index.html`) contains the script tags referencing the content-hashed asset filenames. If `index.html` is cached immutably, visitors will never receive updated links to new releases, permanently locking them into obsolete versions. The HTML must always be served with `Cache-Control: no-cache`.
How does immutable caching reduce server CPU and bandwidth on Nginx?
When browsers send 304 revalidation requests (`If-Modified-Since` or `If-None-Match`), Nginx must still parse TLS records, evaluate disk inodes or calculate ETags, and emit an HTTP header response. Immutable caching eliminates these revalidations entirely, reducing server connection overhead to zero for repeat visitors.
[ RELATED_NODES ]
> START_PROJECT
Need a website that earns trust, ranks in search, and gives your business a stronger digital presence? Start the conversation here.