React Performance Isn't About useMemo - It's About Render Boundaries
Briefly

React Performance Isn't About useMemo - It's About Render Boundaries
React performance problems often stem from weak render boundaries rather than forgotten hooks. Rerenders are normal because state changes trigger UI recalculation. The key question is why a component is involved in an update, not why it rerendered. Problems appear when small inputs cause large portions of the page to update, such as every keystroke propagating through a heavy component tree. Rendering triggers are rarely the core problem; the update scope is. Memoizing a calculation like filtering users may be appropriate or irrelevant if the underlying issue is that the calculation runs too often due to architectural design. A common failure is lifting state too high so a single parent owns too much, forcing widespread rerenders.
"Most React performance problems do not begin because someone forgot a hook. They begin because the application has weak render boundaries. A surprising amount of React optimization advice starts from a flawed assumption: rerenders are bad. They are not. React was built around rerendering. State changes. React recalculates UI. That is normal operation. The real question is not: "Why did this component rerender?""
"The better question is: "Why was this component involved in this update at all?" Performance problems usually appear when updates become: One input field changes. Half the page updates. Every keystroke propagates through a heavy component tree. Rendering triggers: The rerender itself is rarely the core problem. The update scope is."
"Perfectly fine: function Counter() { const [count, setCount] = useState(0) return ( <button onClick={() => setCount(c => c + 1)} > {count} </button> ) } Rerenders happen. Nothing is wrong. Optimization would solve nothing here. But it is not architectural medicine. A common mistake looks like this: const filteredUsers = useMemo( () => users.filter( user => user.name.includes(query) ), [users, query] )"
"This may be perfectly appropriate. Or completely irrelevant. The missing question is: why is this calculation running so often? If every keystroke causes: then memoizing one filter does not solve the architecture. It simply places a performance-shaped bandage over a broader design problem. One of the most common React performance failures is state lifted too high. A single parent component ends up owning everything. function Dashboard"
Read at Substack
Unable to calculate read time
[
|
]