HTTP Cache-Control and ETag: A Practical Caching Guide

HTTP caching can reduce latency, bandwidth, and origin load, but the wrong policy can serve stale or private data. Cache-Control defines who may store a response and how long it is fresh. Validators such as ETag and Last-Modified let a client revalidate without downloading the full representation again.

Caching should be selected by content class. Fingerprinted static assets, public documents, personalized dashboards, and authentication responses need different policies. One global header rarely fits safely.

What the topic means

Freshness allows a cache to reuse a response without contacting the origin. Revalidation asks the origin whether the stored response is still current, often producing 304 Not Modified. Shared caches include CDNs and proxies; private caches are associated with an individual user agent. no-store restricts storage, while no-cache permits storage but requires revalidation before reuse.

Core principles

Classify responses first

Mark content as versioned static, public dynamic, personalized, sensitive, error, redirect, or API data before choosing directives.

Use immutable names for immutable assets

Hash filenames for CSS, JavaScript, fonts, and images so long freshness can coexist with immediate updates through a new URL.

Vary only when necessary

Vary tells caches which request headers change the representation. Excessive variation fragments the cache; missing variation can mix content.

Test every response path

Success, error, redirect, authentication, preview, and compressed responses may receive different headers from frameworks or proxies.

Step-by-step workflow

1. Inventory content classes. List representative URLs, users, request headers, update frequency, sensitivity, and intended cache layer.
2. Choose freshness. Set s-maxage for shared caches where appropriate, max-age for user caches, and short or zero freshness for rapidly changing data.
3. Add validators. Generate stable ETags or Last-Modified values that change when the selected representation changes. Avoid validators that vary unpredictably by server.
4. Configure variation. Include only representation-changing headers such as accepted encoding or language and handle authorization or cookies explicitly.
5. Test conditional requests. Send If-None-Match or If-Modified-Since and verify 304 responses include the headers needed to update cached metadata.
6. Observe production behavior. Measure hit ratio, age, origin requests, stale responses, 304 rate, and cache keys while checking that private data never becomes shared.

Practical example

A site serves app.4f2c.css with Cache-Control: public, max-age=31536000, immutable because the filename changes with content. A public article uses a short shared freshness window and an ETag. An authenticated account response uses private, no-store because it contains sensitive, user-specific data.

How to test the control

Test this workflow in a controlled environment before relying on it in production. Begin with “Inventory content classes” and create three cases: an expected success, a safe rejection, and a degraded or unavailable dependency. Continue through “Choose freshness” and “Add validators,” recording timestamps, identifiers, logs, and the operator decision. Repeat the exercise after meaningful changes to providers, permissions, dependencies, or architecture. A control is operational only when another team member can follow the documented process and obtain the expected result without hidden knowledge.

Metrics and review cadence

Measure completion and outcome separately. For this topic, track evidence that “Each content class has a policy,” “Private responses cannot enter shared caches,” and “Static assets use versioned URLs” remain true, then pair those checks with operational signals such as unexpected changes, denied actions, stale ownership, error volume, recovery time, or unreviewed exceptions as appropriate. Review trends rather than celebrating a single pass. A growing exception count may show the workflow is too difficult, while zero alerts may mean the detection path is not functioning.

Operating this in production

Performance controls sit on a trust boundary because proxies and browsers reuse responses. Cache behavior must be explicit, testable, and aligned with authentication and content variation. Faster delivery is valuable only when the correct user receives the correct representation. Review the workflow after incidents, major releases, access changes, and meaningful growth. Assign an owner and keep evidence that the control works instead of recording only that it exists.

Common mistakes

• Using no-cache when no-store is required.
• Caching personalized content as public.
• Giving unhashed assets a one-year lifetime.
• Changing compression without correct Vary behavior.
• Testing only origin headers and ignoring CDN modifications.

Duck Cloud tools for the workflow

Inspect public caching headers with the HTTP Header Checker, verify status and timing using the Website Status Checker, trace cached redirects with the Redirect Checker, and look up 304 and related responses in the HTTP Status Code Lookup.

Review checklist

• [ ] Each content class has a policy
• [ ] Private responses cannot enter shared caches
• [ ] Static assets use versioned URLs
• [ ] Freshness matches update needs
• [ ] Validators change with representations
• [ ] Vary is minimal and correct
• [ ] Errors and redirects are tested
• [ ] CDN and browser behavior is observed

Conclusion

HTTP Cache-Control and ETag becomes valuable when it is repeatable, owned, and verified. Start with the highest-impact boundary, document the expected state, test realistic failure cases, and fix the gaps that evidence reveals. Small controls maintained consistently are more reliable than a large policy that nobody exercises.