Web Caching Basics: Terminology, HTTP Headers, and Caching Strategies

Introduction

HTTP caching is a fundamental technique for improving web performance and reducing server load. By storing responses for reuse, caches cut round trips and bandwidth between the origin server and end users. This guide explains core HTTP caching concepts, common caching strategies, and practical tips for setting HTTP cache headers so caches—from the browser cache to CDN and reverse proxy cache—behave predictably.

What is caching?

At its simplest, caching means keeping a copy of a previous response so later requests can be answered faster. Web caching is built into the HTTP protocol and enables intermediate systems and clients to serve content without recontacting the origin server. Proper HTTP caching removes unnecessary network hops and improves perceived responsiveness for users.

Benefits of HTTP caching

• Lower network costs: CDN caching and intermediary caches reduce traffic back to the origin, which lowers bandwidth and hosting costs.
• Faster page loads: Browser cache and edge caches serve assets locally or from a nearby node, cutting latency and improving user experience.
• Higher effective capacity: When static assets are cached, origin servers can handle more traffic without additional hardware.
• Resilience during outages: With appropriate caching policies, clients can continue to receive content for short interruptions at the origin.

Key terminology

• Origin server: The authoritative source for your content and the component that sets HTTP cache headers.
• Cache hit ratio: Percentage of requests served from a cache versus requests that reach the origin. Increasing this ratio is central to good caching strategies.
• Freshness lifetime: The period a cached item is considered fresh and can be served without revalidation.
• Stale content: Content past its freshness window. Stale entries usually require validation or must be fetched again from the origin.
• Validation: Techniques (ETag, Last-Modified) used to check whether a cached resource is still valid without re-downloading the complete asset.
• Invalidation: Explicitly removing or expiring cache entries (for example after a deploy) so clients and intermediate caches stop serving outdated content.

What can be cached?

Not every response is a good candidate for caching. Typical candidates include static assets and resources that change infrequently:

• Logos, icons, and static images
• Stylesheets and non-frequently changing JavaScript bundles
• Downloads and media files

Be cautious with caching for:

• HTML pages that change often or are user-specific
• User-authenticated responses or pages containing sensitive data
• Dynamic assets that depend on cookies or session state

Where content is cached

• Browser cache: The client-side cache stores resources locally to enable fast reloads.
• Intermediate caches and proxies: ISPs and on-path proxies may cache responses according to HTTP cache headers.
• Reverse proxy cache and CDNs: Edge caches and reverse proxies (e.g., Varnish, CDN caching) cache content close to users and often implement s-maxage-aware policies.

Caching headers and how they work

HTTP cache headers tell caches what they may Netalith with a response. The most important HTTP caching headers explained include:

• Cache-Control: Modern, flexible directives (max-age, s-maxage, public, private, no-cache, no-store, stale-while-revalidate, must-revalidate).
• ETag: A validator used for cache validation; paired with If-None-Match to support conditional requests.
• Last-Modified: A timestamp that can be used with If-Modified-Since for validation.
• Expires: Older mechanism that sets an absolute expiry time; see Expires vs Cache-Control header differences for details.
• Vary: Instructs caches to consider additional request headers (commonly Accept-Encoding) when storing and matching cached entries.

An aside on the Vary header

The Vary header lets you store multiple representations of a resource keyed by request headers. Use it for Accept-Encoding to separate compressed and uncompressed responses. Avoid varying by volatile headers such as User-Agent, which can fragment the cache and reduce cache hit ratio. For CDN caching and reverse proxy cache configurations, normalize inputs where possible to limit unnecessary variations.

How Cache-Control flags affect caching

The Cache-Control header is the primary tool to shape cache behavior. Common directives include:

• no-cache: Requires revalidation with the origin before serving, but allows storing the resource.
• no-store: Prevents any caching; appropriate for highly sensitive responses.
• public / private: Control whether intermediate caches can store a response.
• max-age: Sets freshness lifetime in seconds (up to one year).
• s-maxage: Like max-age but applies only to shared caches such as CDNs or reverse proxies.
• must-revalidate / proxy-revalidate: Force strict adherence to freshness; prevents serving stale content without validation.
• no-transform: Tells caches not to alter the payload (for example, by recompressing or transcoding).

# Examples
Cache-Control: public, max-age=31536000, immutable
Cache-Control: s-maxage=3600, max-age=60, public
Cache-Control: no-cache, must-revalidate

Developing an HTTP caching strategy

A practical caching strategy balances long-lived static assets with frequently refreshed HTML and robust validation when needed. Use fingerprinting and far-future caching for static files, and shorter lifetimes or validation for HTML.

Common problems to plan for

• Stale variants of assets remaining in caches after deploys.
• Inadvertently caching user-specific or sensitive content at shared caches.
• Poor cache hit ratios caused by inconsistent URLs or unnecessary URL parameters.

General recommendations

• Organize static assets into predictable directories and use consistent URLs so caches can consolidate entries.
• Fingerprint static files (hash in filenames) so you can set long freshness lifetimes and avoid forced invalidation.
• Allow browsers to cache user-specific resources (private) while preventing shared caches from storing them when appropriate.
• Always provide validators (ETag and Last-Modified) to support conditional requests like If-None-Match and If-Modified-Since.
• For CDN caching and reverse proxy cache tiers, use s-maxage and normalized headers to control shared-cache behavior separately from browser cache.
• Set long freshness for static supporting files (images, CSS, JS) and short freshness for parent HTML so pages reflect updates while supporting assets remain cached.

Conclusion

HTTP caching is a powerful lever to speed up sites, cut costs, and scale infrastructure. Combining clear HTTP cache headers, validators like ETag, and practical caching strategies—fingerprinting static assets, choosing appropriate max-age and s-maxage values, and using Vary sparingly—will give you predictable cache behavior across browser cache, CDNs, and reverse proxy cache layers. Thoughtful caching policies increase cache hit ratio and improve the user experience with minimal operational overhead.