Rendering Performance

1The frame — it's all the main thread

JavaScript, layout, paint, and your event handlers all run on one thread. While that thread is busy, the page can't respond to a tap or render the next frame — that's jank and bad INP (Lesson 03). Any task over 50 ms is a "long task" that delays interaction. [web.dev] To hit 60fps the browser has ~16ms per frame; blow that budget and frames drop.

So every rendering-performance technique is one of three moves on that single thread:

1. Render less — skip work that doesn't change the output: cut needless re-renders (memo), and don't render rows nobody can see (virtualization).
2. Render rarely — collapse a storm of events into the work that matters: debounce / throttle inputs, coalesce visual updates to a frame with rAF, and de-prioritize non-urgent renders (transitions).
3. Render elsewhere — move CPU-heavy work off the main thread entirely: Web Workers / OffscreenCanvas, or yield so the browser can interleave input.

2Render less — kill needless re-renders

First, know what actually triggers a React re-render. A component re-renders when its state changes, its parent re-renders, or a context it consumes changes. [react.dev] The one people get wrong: props changing isn't an independent trigger — props change because the parent re-rendered, and a parent re-render re-renders all children by default, changed props or not.

A re-render isn't automatically a DOM update — React diffs the result and only commits real changes. But the render itself (running the function, building elements, diffing) still costs CPU, and across a big tree it adds up. Three tools, each for a different cause:

// Child re-renders every time Parent does — even if `row` is unchanged.
const Row = React.memo(function Row({ row, onPick }) { /* ... */ });

function Results({ rows }) {
  // stable identity → Row's memo actually holds
  const onPick = useCallback(id => selectHotel(id), []);
  return rows.map(r => <Row key={r.id} row={r} onPick={onPick} />);
}

Keys — the cheapest correctness-and-perf bug

React uses the key to match elements across renders. A stable, unique key lets it move a row instead of destroying and rebuilding it. Using the array index as a key on a list that reorders/filters is a classic bug: React mismatches items, so DOM state (input focus, checkbox, the wrong row's component state) sticks to the wrong data — and you lose the perf win because it can't reconcile efficiently. [react.dev]

3Render less — virtualize long lists

The biggest single win on a results page. If a search returns 1,000 hotels, the naive approach mounts 1,000 row components and 1,000× their DOM. Virtualization (windowing) renders only the ~visible rows plus a small overscan buffer, and recycles them as you scroll — so the DOM stays tiny no matter how long the list is. [web.dev] Libraries: TanStack Virtual, react-window, react-virtuoso.

// TanStack Virtual: render only what's in view
const v = useVirtualizer({ count: rows.length, getScrollElement: () => ref.current,
                          estimateSize: () => 96, overscan: 8 });
// v.getVirtualItems() → just the handful of rows on screen

4Render rarely — debounce, throttle, rAF, transitions

Some events fire in storms — input on every keystroke, scroll/resize/mousemove dozens of times a second. Doing full work on each one floods the main thread. Four tools to do less work for the same events:

Debounce vs throttle in one line: debounce fires once after activity stops; throttle fires regularly during activity. Search input → debounce. Scroll position readout → throttle (or rAF).

“If I use useDeferredValue, do I still need debounce?”

A favourite follow-up — and the answer is they're not substitutes; they fix different layers. useDeferredValue replaces debounce for the render, but not for the network.

The trap: useDeferredValue only changes render scheduling — it doesn't suppress effects. Derive a fetch from the deferred value and it still fires for every committed value. So a real type-ahead uses both: debounce the request (don't hammer the server per keystroke) and useDeferredValue to render the results smoothly. [react.dev]

Concretely — a hotel autocomplete with two separate values in flight: the query the user types (must be instant) and the expensive results render:

const [query, setQuery] = useState('');     // ① updates on EVERY keystroke
const [results, setResults] = useState([]);  // ③ server response — can be 500 rows

// ② DEBOUNCE the network — fetch only once typing pauses 300ms
useEffect(() => {
  if (!query) return setResults([]);
  const id = setTimeout(() => fetchHotels(query).then(setResults), 300);
  return () => clearTimeout(id);            // cancel pending fetch on next key
}, [query]);

// ④ DEFER the heavy render — list lags WITHOUT blocking the input
const deferredResults = useDeferredValue(results);
const isStale = results !== deferredResults;  // dim while new render pending

Type rome fast then keep typing: debounce collapses the 4 keystrokes into one fetch at the 300ms pause (and cancellation avoids out-of-order races); useDeferredValue lets the input paint the next keystroke immediately while the 500-row list renders at low priority. Remove each to see why you need both:

So debounce protects the server (throttles work going out, dropping intermediate queries); useDeferredValue protects the input (re-prioritizes work coming back, dropping no keystrokes). If the data is already in memory (no fetch), drop the debounce and use useDeferredValue alone — the composition only appears when a network call and an expensive render are both in play.

5Render elsewhere — get heavy work off the main thread

Sometimes the work is genuinely heavy — parsing a big JSON payload, sorting/filtering 50k records client-side, image processing, on-device search. No amount of memoizing makes a 200ms computation cheap; it just blocks. The move is to take it off the main thread:

• Web Workers — run JS on a separate thread. The worker has no DOM access; you talk to it via postMessage and it posts results back. Great for heavy compute that would otherwise freeze the UI. [MDN] (Comlink makes the messaging feel like a normal function call.)
• OffscreenCanvas — render <canvas> (a map, a chart) from a worker, so animation/drawing never competes with the UI thread. [MDN]
• Yield / break up the task — if you can't move it, chunk it and yield to the browser between chunks so it can handle input. await scheduler.yield() (or scheduler.postTask) is the modern way; setTimeout(0) the old fallback. This is the key INP fix for long tasks. [web.dev]

6How to diagnose & the Lead framing

Don't guess — measure, then pick the move. The workflow (Lesson 04):

• React DevTools Profiler → see which components re-render and why (enable "highlight updates" / "why did this render"). Confirms a re-render problem before you reach for memo.
• Performance panel → find long tasks (the red-flagged >50ms blocks) and what's in them — that tells you "render rarely" vs "render elsewhere."
• The list itself → 1,000s of nodes ⇒ virtualize. A storm of identical handlers ⇒ debounce/throttle/transition. One fat function ⇒ worker or yield.

7Check yourself — scenario quiz

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