Caching & Perf Budgets

1The frame — fast forever, not fast once

Lessons 01–07 made the page fast. But two forces erode that:

1. Repeated work — re-downloading the same JS, re-fetching the same data, re-rendering the same view. The cure is caching: do the work once, reuse the result (§2–§3).
2. Silent regression & decay — the next PR quietly adds 200 KB; a memory leak makes a long session slow. The cure is guardrails: budget it in CI and watch real users (§4), and don't leak memory (§5).

2The caching stack — three layers

“Cache” isn't one thing; it's a stack, and a Lead names the layer. The same request can be served from any of these, closest-and-cheapest first: [web.dev]

(A fourth, the Service Worker + Cache API, gives you a programmable cache for offline — that's Lesson 20, with the security headers.)

The browser HTTP cache — and the hashed-asset pattern

Cache-Control is the control surface. The handful you must know cold:

The pattern that powers every modern build (Lesson 05's content hashes pay off here):

// Hashed static assets — the hash IS the cache key. Cache forever.
app.a8f3c2.js   →  Cache-Control: max-age=31536000, immutable

// HTML — short-lived, so a new deploy is picked up promptly.
index.html      →  Cache-Control: no-cache   // revalidate every load

Because the filename changes when the content changes (app.a8f3c2.js → app.b1d9e0.js), you can cache assets for a year and still ship instantly: the new HTML simply references new filenames, and old ones are never requested. That's how you get cache-bust on deploy without ever serving stale code. [web.dev]

Revalidation — ETag / 304

When something might have changed, the browser revalidates: it sends If-None-Match: "<etag>"; if the server's ETag matches, it replies 304 Not Modified with no body. You still pay the round trip, but save the download. [MDN]

3stale-while-revalidate & app-level data caching

stale-while-revalidate is the “best of both” caching move: serve the stale cached copy instantly, and refresh it in the background for next time. The user never waits, and the data converges to fresh. It exists both as an HTTP directive and as the core idea behind modern data libraries: [web.dev]

Cache-Control: max-age=600, stale-while-revalidate=3600
// 0–10 min: fresh. 10–70 min: serve stale instantly + refetch in background.

The third cache layer lives in your app. Server state — data you fetch from an API — is fundamentally different from client/UI state: it's shared, it goes stale, and many components want it. Libraries like TanStack Query (React Query) and SWR cache it in memory and give you, by default: request deduplication, stale-while-revalidate refetching, background updates, and cache invalidation on mutation. [TanStack]

4Perf budgets & guardrails — stop the regression

Caching makes it fast; budgets keep it fast. A performance budget is a hard limit on a metric that fails the build if exceeded — so a regression is caught in review, not in production. [web.dev] Three kinds:

The two halves of the guardrail — one before merge, one after deploy:

• Pre-merge (lab / CI): a bundle-size gate (size-limit) and Lighthouse CI (lhci) run on every PR and fail the build over budget. The regression literally can't merge. [Lighthouse CI]
• Post-deploy (field / RUM): lab can't catch everything (real devices, networks, third-party tags vary). Instrument RUM with the web-vitals library (Lesson 04), watch p75 LCP/INP/CLS on a dashboard, and alert when a release moves the curve. [web.dev]

5Memory leaks — staying fast within a session

An SPA doesn't reload between routes, so memory that's allocated and never freed accumulates over a long session — and a travel user keeps that tab open for hours across many searches. The page gets slower, then the tab crashes. The usual culprits in a SPA: [MDN]

• Un-removed event listeners — added on mount, never removed on unmount.
• Live timers / intervals — a setInterval that's never clearInterval'd keeps its closure (and everything it references) alive.
• Detached DOM nodes — you removed a node from the page but a JS variable still references it, so it can't be collected.
• Subscriptions / observers — store subscriptions, IntersectionObserver, WebSocket handlers not torn down.
• Unbounded growth — a global array/Map/cache you keep pushing into and never evict.

In React these almost always reduce to a missing cleanup: every useEffect that subscribes, times, or listens must return a cleanup function that undoes it.

useEffect(() => {
  const id = setInterval(poll, 5000);
  window.addEventListener('resize', onResize);
  return () => {                 // ← cleanup: the leak fix
    clearInterval(id);
    window.removeEventListener('resize', onResize);
  };
}, []);

Finding them: Chrome DevTools Memory panel → take a heap snapshot, exercise the flow (navigate away and back a few times), take another, and compare — objects/nodes that keep growing are leaking. Filter by “Detached” to spot orphaned DOM. The Performance monitor shows the JS heap and DOM-node count climbing in real time. [Chrome DevTools]

6The Lead framing

7Check yourself — scenario quiz

Pick an answer; instant feedback. Push-back style, like the round.