How does caching improve performance?

Caching stores copies of data or computed results closer to where they're needed, so future requests can be served faster without repeating expensive operations. On the web, caching happens at multiple layers — browser memory, HTTP cache, CDN edge nodes, application-level caches, and database query caches. Each layer trades freshness for speed, and the art is choosing the right cache strategy for each type of data.

A single web request can hit multiple cache layers before reaching the origin server. Each layer is progressively further from the user but closer to the source of truth. A cache hit at any layer short-circuits the rest of the chain.

The browser's HTTP cache is controlled by response headers from the server. These headers tell the browser how long to keep a response, whether to revalidate before using it, and whether intermediate caches (CDNs, proxies) can store it.

# Cache for 1 year (immutable static assets with hashed filenames)
Cache-Control: public, max-age=31536000, immutable

# Cache for 5 minutes, then revalidate with server
Cache-Control: public, max-age=300, must-revalidate

# Don't cache at all (sensitive data, real-time content)
Cache-Control: no-store

# Cache but always revalidate before using (API responses)
Cache-Control: no-cache
# (confusing name — it DOES cache, but checks freshness every time)

# ETag for conditional requests (revalidation)
ETag: "abc123"
# Browser sends: If-None-Match: "abc123"
# Server responds: 304 Not Modified (use cached version)

The most effective pattern for static assets: use content-hashed filenames (app.a1b2c3.js) with max-age=31536000, immutable. The hash changes when the file changes, so the browser caches forever and gets a new URL when there's an update. No revalidation needed.

Different types of data need different caching strategies. The right strategy depends on how often the data changes, how critical freshness is, and how expensive it is to regenerate.

Beyond HTTP caching, frontend applications implement their own caching layers. React Query and SWR maintain an in-memory cache of API responses. Memoization caches computed values. These application-level caches give you fine-grained control over freshness and invalidation.

// React Query: automatic caching + stale-while-revalidate
const { data } = useQuery({
  queryKey: ['user', userId],
  queryFn: fetchUser,
  staleTime: 5 * 60 * 1000,    // Fresh for 5 min (no refetch)
  gcTime: 30 * 60 * 1000,       // Keep in cache for 30 min
});

// Manual memoization for expensive computations
const expensiveResult = useMemo(() => {
  return heavyComputation(data);
}, [data]);

// Simple in-memory cache for repeated function calls
const cache = new Map<string, Response>();

async function cachedFetch(url: string): Promise<Response> {
  if (cache.has(url)) return cache.get(url)!;
  const response = await fetch(url);
  cache.set(url, response.clone());
  return response;
}

The hardest part of caching is knowing when to throw away stale data. Serve stale data too long and users see outdated content. Invalidate too aggressively and you lose the performance benefit. There are several approaches to invalidation, each with tradeoffs.

This question tests your understanding of web performance optimization at multiple levels. Interviewers want to see that you know the different cache layers (browser, CDN, server), understand HTTP cache headers and what they control, can choose appropriate strategies for different data types, and appreciate the cache invalidation challenge. It shows you think about performance holistically — not just code optimization but infrastructure and network-level improvements.