Networking, caching & HTTP for UIs

Frontend networking is product behavior. The same cache header that makes a page fast can leak stale personalization, hide failed mutations, or make an incident hard to roll back. Senior frontend engineers can explain both browser mechanics and ownership rules.

Core details

Cache policy examples:

Cache-Control: public, max-age=31536000, immutable

Use for content-hashed JS, CSS, and image assets. Never reuse the same URL for different bytes.

Cache-Control: private, no-store

Use for sensitive personalized responses where browser or proxy storage would be unsafe.

Cache-Control: s-maxage=60, stale-while-revalidate=300

Use carefully at a CDN for shared, non-sensitive data where brief staleness is acceptable and purge/revalidation ownership is clear.

CDN ownership: dynamic edge caching needs a purge story: surrogate keys, path bans, tag invalidation, deploy ordering, and an incident command to bypass cache quickly.

Understanding

Most win comes from changing what ships and in what order, not from squeezing bits. Hash-versioned static assets can safely live at long TTLs; HTML and personalized responses almost never should without strict keying and purge discipline. GET APIs cached for “speed” can lie to the UI about business truth—pair caches with explicit freshness contracts and user-visible cues when data may be stale.

HTTP caching has three separate audiences:

1. Browser cache: helps one user avoid repeat downloads.
2. CDN/shared cache: reduces origin load and global latency but must not mix users or tenants.
3. Application/data cache: controls business freshness and often needs explicit invalidation after mutations.

Do not collapse these into one “cache is fast” bucket. A product page image, a logged-in account page, and a cart count have different correctness contracts.

The visual model below separates those contracts: immutable hashed assets can live long, personalized HTML needs private or keyed handling, and API mutations must invalidate the UI state they make stale.

Practical examples

Request cancellation: use AbortController when a newer request supersedes an older one. Otherwise slow responses can overwrite newer UI state.

const controller = new AbortController();

fetch(`/api/search?q=${encodeURIComponent(query)}`, {
  signal: controller.signal,
});

return () => controller.abort();

Senior understanding

Third-party weight: escalate marketing injectables through risk review—SLO-aware loading, deferred consent-aware activation, kill switches—not “marketing exception” culture.

Failure modes

• Caching personalized HTML as public without Vary, user/tenant keying, or purge discipline.
• Using stale-while-revalidate for data where stale values cause user harm.
• Preloading many assets and delaying the actual LCP resource.
• Retrying non-idempotent POST requests after a timeout without an idempotency key.
• Letting old async responses win races against newer user input.

Interview drill

Question: "After deploy, logged-in users sometimes see stale account data. How do you debug the cache stack?"

Model answer structure:

1. Identify the stale surface: HTML, RSC/server payload, API response, client query cache, CDN, or browser cache.
2. Inspect response headers, cache keys, Vary, authentication signals, and whether the route is static or dynamic.
3. Check mutation flow: what cache boundary is invalidated, by whom, and whether old responses can race newer state.
4. Apply a correctness-first fix: private/no-store for sensitive HTML, safe keying, tag/path invalidation, or shorter stale budget.
5. Add regression guardrails: release-tagged logs, cache header tests, and an incident bypass/purge command.

Follow-ups to expect:

• "Why is CORS not the same as authorization?"
• "When is stale-while-revalidate unsafe?"
• "How would you cache a public product page differently from a dashboard?"

Diagram

See also

• Bundling & code-splitting
• Web security, CORS & XSS
• Media, fonts & Core Web Vitals
• /frontend