Element Optimization
Hand React the same element, or props that compare equal, and it skips the render: reuse, element props, useMemo and memo.
ReadModule 5 of 7
"There's nothing faster than not doing anything at all." Most React performance work is making React skip work it can prove is unnecessary, and React's proof is almost always Object.is: the same element, the same props, the same context value. When work can't be skipped, the other options are to make it interruptible (concurrent rendering), load less of it (code splitting), move it off the main thread (Web Workers), or do less of it (windowing).
The notes, in the order to read them:
memo on list rows, and what defeats it.Every number here (render lists, render counts, milliseconds to the next frame, rows in the DOM) was recorded by running the product store in Chrome (examples/product-store/src/lessons/performance). Timings come from one machine and vary between runs; compare them with each other, not with your own app.
Measure before and after. The React DevTools Profiler ("Highlight updates when components render") and the browser's Performance panel show where time actually goes, and profile a production build: development React does extra work.
Read them in order. Each one builds on the ones before it.
Hand React the same element, or props that compare equal, and it skips the render: reuse, element props, useMemo and memo.
ReadMemoize the value, move state into a provider component, split state from setters: who re-renders after each.
ReaduseDeferredValue + memo keeps typing instant over a slow grid; without memo it does nothing (recorded).
Readlazy and Suspense load a feature’s code on demand; prefetch on hover; a transition avoids the fallback.
ReadMeasure, cache with useMemo, or move the work to a Web Worker and read the result with use.
Readmemo on 500 list rows, why one changing prop defeats it, and fixing that with a comparator or primitive props.
Read