What is caching?

What is caching?

Caching is the practice of saving a reusable copy of data so a later request can be answered faster and with less work. On the web, the cached item might be an image, stylesheet, script, HTML page, API response, redirect, rendered page fragment, database result, or object stored by an application. A cache can live in a browser, a mobile app, a reverse proxy, a CDN, an origin-side web server, an application process, or a data store client.

The basic tradeoff is simple: reuse can improve speed and reduce origin load, but only when the reused response is still appropriate for the request. Good caching is therefore not just a performance trick. It is a set of rules about freshness, variation, ownership, invalidation, and evidence.

Where caching happens

Browser caches reduce repeat downloads for the same user. They are especially useful for versioned assets such as CSS, JavaScript, fonts, icons, and images. Browser caching is controlled by HTTP headers, but each browser still makes decisions about storage limits, eviction, and revalidation.

Shared caches serve many users. CDN and reverse proxy caches sit between users and origins, so they can reduce latency across regions and absorb traffic spikes before they reach the application. They are powerful because one stored response can serve many users, but that same sharing makes policy mistakes more serious.

Application caches sit closer to business logic. They might cache database queries, product recommendations, session metadata, feature flags, or rendered fragments. These caches can be precise because the application understands the data, but they need clear invalidation paths when the underlying state changes.

Freshness, validation, and cache keys

HTTP caching usually starts with response headers. Cache-Control can define whether a response is public, private, reusable, revalidatable, or not stored at all. ETag and Last-Modified allow a cache to ask the origin whether a stored response is still valid instead of downloading the full body again. Expires is an older freshness signal that can still appear in legacy systems.

A cache also needs a cache key: the request properties used to decide whether two requests are equivalent. The simplest key might be scheme, host, path, and query string. Real applications often need more nuance. A response might vary by Accept-Encoding, language, device class, authentication state, selected currency, or a small number of application cookies.

The cache key should be intentional. If it ignores an input that changes the response, users can receive the wrong content. If it includes too many inputs, the cache fragments into many rarely reused entries and the hit rate falls. Query strings are a common example: tracking parameters often should not create new variants, while search filters or product options often should.

What should and should not be cached

Static assets are usually the safest candidates. When filenames include a version hash, they can often be cached for a long time because a content change creates a new URL. Public documentation, marketing pages, product images, and generated category pages may also be good candidates if updates are tied to a purge or revalidation workflow.

Authenticated pages need more care. Account pages, checkout flows, admin interfaces, private API responses, and anything containing personal information should normally be marked private or no-store unless a specific design proves safe partitioning. A response that depends on Authorization headers or session cookies should not be stored in a shared cache by accident.

Dynamic pages are not automatically uncacheable. Many high-traffic pages are dynamic at build time or origin time but identical for many users. The useful question is whether the response is public, how often it changes, what makes it vary, and how quickly a bad or stale copy can be removed.

Operational checks

Teams should classify routes before writing cache rules. A practical inventory groups static assets, public HTML, public API reads, authenticated pages, transactional endpoints, redirects, and error responses. Each group should have an owner, a freshness policy, a variation policy, and a purge or revalidation approach.

Measure cache behavior with more than a single hit ratio. Review cache status by route, response code, method, byte volume, object type, country or region, query string pattern, and origin. A high hit ratio is not useful if it comes from trivial assets while expensive pages still miss. A low hit ratio is not always bad if the missed routes are intentionally private or transactional.

Test with realistic request variants. Compare anonymous and logged-in requests, language choices, mobile and desktop headers, selected currencies, compression options, and common query parameters. Confirm that a purge reaches every relevant cache layer and that a rollback can restore a known good asset or page.

Security implications

The most damaging caching failure is shared storage of sensitive data. This can happen when an authenticated response lacks defensive headers, when a reverse proxy ignores Authorization context, or when a route that looks static actually returns user-specific content. Security review should include header inspection and request replay, not just route naming.

Cache poisoning is another risk. An attacker may try to influence a cached response through untrusted headers, host values, query parameters, or path parsing differences between the cache and origin. Defensive design normalizes inputs, rejects ambiguous hostnames, avoids caching responses influenced by untrusted request components, and keeps error caching conservative.

Cache deception attacks work in the other direction: a dynamic page is made to appear like a static asset so a shared cache stores it. Applications should be consistent about URL routing, content type, authentication checks, and cache headers, especially where frameworks serve both static files and dynamic routes.

Common misconceptions

Caching does not mean content is stale by definition. Revalidation, short freshness windows, event-driven purge, and versioned URLs can keep cached delivery accurate. It also does not mean every page should be cached. A healthy strategy leaves some routes deliberately uncacheable.

Another misconception is that cache policy belongs only to infrastructure teams. Application developers decide what data changes a response, release teams decide how assets are versioned, security teams decide which responses are sensitive, and operations teams need evidence during incidents. Caching works best when those decisions are explicit and reviewed as the application changes.

Related learning

• What is a CDN?
• What is CDN Security?
• What is a Reverse Proxy?