Performance and Memoization

React.memo skips a re-render caused by the parent, and only when every new prop is the same as the old one by a shallow comparison. Its own state updates, a context change it reads, or any changed prop still re-render it.

React.memo caches a component's rendered output and skips re-running it when its props are unchanged. useMemo caches one value inside a component that still re-renders. One avoids a render; the other avoids a computation during a render.

The React Compiler is a build-time Babel plugin that rewrites components to cache their derived values and their JSX in per-instance slots, reusing them when inputs are unchanged. It replaces most hand-written useMemo, useCallback and React.memo.

Rebuilding query in the component body creates a new object on every render, and React compares each dependency with Object.is, so the effect re-runs, sets state, renders again, and loops. Depend on the primitive fields instead.

React.memo re-renders whenever a prop differs by Object.is. The inline object, array and arrow are created fresh during each parent render, so all three are new references every time and the shallow comparison always reports a change.

Move the state down: extract the input and its useState into a small child component, so a keystroke re-renders only that child instead of the whole page. Lift only the committed or debounced value back up if the table truly needs it.

A React component re-renders when its own state changes, when its parent re-renders, or when a context it reads publishes a new value. Changed props are a consequence of the parent rendering, not a separate trigger.

Windowing renders only the rows that intersect the scroll viewport plus a small overscan, so dozens of row elements exist instead of ten thousand. An inner spacer element sized to the full content height keeps the scrollbar and every scroll offset accurate.

Record the typing with the Profiler, with "record why each component rendered" enabled. Count the commits per keystroke, open the worst one, use Ranked to check for a hot component and Flamegraph for a wide cascade, read the reason on the highest re-rendering component, then re-record after the fix.

The state lives too high, so every keystroke re-renders the whole page subtree including the chart and table. Confirm before fixing: profile a single keystroke and check whether the cost is many cheap renders or one expensive component's render body.

It flashes a coloured outline around each region of the page whose component just re-rendered, with the colour shifting as a region updates more often. It is a zero-setup way to see which parts of the screen react to an interaction, but it gives no timings.

React's Profiler component renders its children unchanged and emits no DOM of its own. Its only job is to call your onRender callback after every commit in which that subtree rendered, passing the id you gave it plus timing numbers for that commit.

A function component's body runs again on every render, so the array literal is evaluated again and produces a brand-new array. Move it to a module-level constant outside the component and every render passes the identical array.

No. React's StrictMode deliberately calls component functions twice in development to expose impure renders. Production builds render once, so measure a production build before drawing any performance conclusion from the doubling.

Calling lazy during render creates a brand-new component type on every render. React sees a different type at that position, unmounts the old subtree and mounts a fresh one, which loses state and suspends again. Move the lazy call to module scope.

Keep the loader in a named function, pass it to React.lazy, and also call it from the button's onMouseEnter and onFocus handlers. The module registry caches by specifier, so React's later call to the same loader resolves from cache instead of fetching again.

No single component is slow — the 48 ms is the sum of many cheap renders, so this is a breadth problem, not a hot-component problem. Look at the Flamegraph to see how much of the tree re-rendered and find the highest component in the coloured region.

Flamegraph draws a commit as the component tree, where a bar's width covers that component plus its subtree and components that did not re-render are greyed out. Ranked flattens the same commit into a list of components sorted by their own render time.

With that setting on, selecting a component inside a profiled commit shows why it rendered: it was mounting for the first time, specific props changed, its state or hooks changed, context changed, or its parent rendered. The extra bookkeeping makes the profiling session slower.

No. On every render React still allocates the arrow function and the dependency array and compares each dependency, which costs about as much as one multiplication. Write the plain expression instead and save useMemo for expensive work or for a reference that must stay stable.

actualDuration is the time React really spent rendering the profiled subtree for this update; baseDuration is the estimated time to render that whole subtree from scratch with nothing skipped. When the two stay nearly equal on updates, almost nothing is being skipped.

The children element is created in the parent's render, not inside the stateful component. When only that component's state changes, its children prop is the same object as the previous render, so React bails out and reuses that subtree.

Overscan renders extra rows just beyond each edge of the viewport. Those buffer rows hide blank flashes during fast scrolling, but each one is real DOM and real render work, so a large overscan gives back the win virtualization bought.

The old tab requests a hashed chunk that the new deploy removed, so the loader's promise rejects and React.lazy throws during render. Suspense handles pending loads only — an error boundary above the lazy component catches it, and recovery normally means reloading the page.

Return true when the props should be treated as equal, which tells React to skip the re-render — the opposite of the old shouldComponentUpdate convention. Hand-written comparators go wrong by ignoring props that matter, which freezes stale data on screen, or by deep-comparing large objects for more cost than the render saved.

React disables profiling in its standard production build because the timing instrumentation costs time and memory on every commit. Real production numbers require building against React's profiling-enabled build, which reintroduces that overhead for every user you ship it to.

The React Compiler removes only wasted re-rendering of pure components whose inputs did not change. Genuinely changed inputs, expensive DOM volume, data-fetching waterfalls, bundle size, and slow effects or event handlers all cost exactly what they did before.

The React Compiler assumes rendering is pure: same inputs produce the same output, and props, state and rendered values are never mutated during render. When it can detect a violation it skips that component and leaves it uncompiled; undetectable violations can cache a stale value and show stale UI.

It works only for small plain objects whose keys are always written in the same order. Reordered keys re-run the effect needlessly, and values JSON drops can make genuinely different objects serialize identically. Stabilize the object where it is created instead.