React Performance Interview Questions

How do you find out what is actually slow?

Measure before you change anything — and say so before you propose a fix, because the most common failure in this round is a candidate reaching for `useMemo` before knowing what is slow. React DevTools has a Profiler that records a commit and shows which components rendered, why, and how long each took. Turning on "Highlight updates when components render" is even faster for a first look: interact with the page and watch what flashes that had no reason to.

The distinction that makes your answer credible is between a render problem and a load problem. If the app is slow to appear, the bundle and the network are the suspects and the Network panel plus a Lighthouse run will tell you. If it is slow while you use it, the Profiler is the tool. Naming which one you are diagnosing, and therefore which tool you would open, is a stronger opening than any specific optimisation.

Why does React.memo often do nothing?

Because it compares props with `Object.is` — a shallow, reference-based check — and JSX creates fresh objects, arrays and functions on every render. An inline arrow function, an object literal, an array literal or children passed as JSX are all new references each time, so the comparison always reports a change and the memo never bails out. Wrapping a component in `React.memo` while the parent passes any of those is a no-op that costs you an extra comparison.

There is a second reason memo appears not to work, and it is worth knowing because it is the follow-up. `React.memo` only blocks re-renders caused by a parent rendering. If the component has its own state, or consumes a context whose value changed, it re-renders regardless of how its props compare — the update reaches it through a different path entirely.

It is worth knowing why memoisation has to be unbroken to work. A `useCallback` whose dependency is itself an unstable function from the parent produces a new reference anyway, so the chain fails one level up and every layer below it is wasted work. That maintenance burden — every link having to hold — is the strongest practical argument for using memoisation deliberately and sparingly rather than as a default habit.

When should you use useMemo and useCallback?

For two distinct reasons, and being able to name both is the answer. The first is skipping genuinely expensive work — a sort or filter over thousands of items that would otherwise run on every keystroke elsewhere in the component. The second, and more common in practice, is keeping a reference stable so something downstream can rely on it: a memoised child, another hook's dependency array, or a context value.

The cost side matters too, and mentioning it unprompted reads well. Every memo allocates a dependency array, compares it on each render, and holds its result for the lifetime of the component. For a sum or a string concatenation that bookkeeping costs more than the work it avoids, and it makes the code harder to read. React also documents `useMemo` as a hint — it may discard cached values — so it must never be relied on for correctness.

A useful sanity check before adding any memo: ask what the child actually costs to render. Memoising a component that renders a handful of nodes usually loses, because comparing its props costs more than simply rendering it. Memoisation pays off at boundaries — the root of a large subtree, a list row rendered hundreds of times, a chart — and that is where an interviewer expects to see it applied.

How does state placement affect performance?

More than any hook. When state changes, React re-renders that component and everything below it, so state sitting near the root means the whole tree re-renders on every keystroke. Moving it down to the smallest component that needs it is usually a bigger win than any amount of memoisation, and it is a structural fix rather than a patch.

That second pattern surprises people and is a genuinely strong thing to know. Because `children` is created by the parent and passed in, re-rendering `Wrapper` does not recreate that element — React sees the identical object and skips the subtree. It is memoisation you get from composition rather than from a hook, and it is why "lift content out, pass it as children" appears so often in React performance advice.

How do you handle very long lists?

Virtualise them. Rendering ten thousand rows means ten thousand DOM nodes, which costs memory, makes every layout calculation slower and makes scrolling janky regardless of how well memoised the rows are. Virtualisation renders only the rows in the viewport plus a small overscan buffer, so the DOM node count stays constant no matter how long the list gets.

How do you reduce bundle size and improve load time?

Split by route first — it is the highest-return change and usually the easiest, because a user landing on the login page has no reason to download the dashboard's charting library. Then split heavy components that are not needed immediately: modals, editors, date pickers, anything below the fold. `React.lazy` with `Suspense` covers both, and any modern bundler handles the mechanics.

Then look at what is in the bundle rather than guessing. A bundle analyser regularly turns up a date library imported whole for one function, an icon set pulled in entirely for six icons, or two versions of the same dependency. Those are usually larger wins than any code you would write, and being able to say "I'd run the analyser before splitting anything" keeps the diagnosis-first framing consistent.

Bundle work has a second dimension people forget to mention: what the JavaScript costs to execute, not just to download. On a mid-range Android phone, parsing and running a large bundle can take longer than fetching it, which is why shipping less code beats compressing the same code. For an India-first product that is the constraint that actually decides how the app feels, and naming it shows you design for real devices rather than for a development laptop.

What are useTransition and useDeferredValue for?

Both let you mark work as low priority so the interface stays responsive while it happens. `useTransition` wraps a state update you are willing to have interrupted and gives you a pending flag. `useDeferredValue` takes a value and returns a version that lags behind, so an expensive component can render with the old value while the new one is prepared. Neither makes the work faster — they change what the user waits for.

The distinction from debouncing is a good follow-up to have ready. Debouncing delays when work starts, on a timer you pick; a deferred value starts the work immediately but at a priority React can interrupt. For a network request, debounce is what you want, because the goal is fewer requests. For an expensive render over data you already have, `useDeferredValue` is better, because there is no arbitrary delay to tune.

What does React Compiler change, and what does it not fix?

React Compiler inserts memoisation at build time, which removes most hand-written `useMemo`, `useCallback` and `React.memo`. In a project where it is enabled and not bailing out, the reference-identity problems described earlier largely disappear — which is genuinely a large share of everyday React performance work.

What it does not touch is everything structural. It will not virtualise a list, split your bundle, move state down the tree, remove a request waterfall, or stop a layout thrashing during scroll. It also cannot help components it bails out on, which is why not mutating props or state matters more once it is on. Saying that clearly is a strong close to any React performance answer, because it shows you know where the tool's boundary is.