A senior engineer’s guide to React’s `useMemo`. We cut through the confusion to explain when to use it, when to refactor instead, and how to avoid the performance traps of premature optimization.

To `useMemo` or Not to `useMemo`: A Senior Engineer’s Take on React Performance

I remember a Monday morning a few years back. The on-call pager was screaming. Our main production monitoring dashboard, the one every engineer had open all day, was sluggish to the point of being unusable. Clicks took seconds to register. Charts were frozen. It had been fine on Friday. After a frantic half-hour of digging, we found the culprit: a junior dev, trying to be helpful, had added a new “filter by user” feature. The problem wasn’t the feature itself; it was that on every single keystroke in the filter input, the component was re-filtering and re-processing a massive, multi-megabyte JSON object pulled from our `prod-log-aggregator-01`. The entire app re-rendered, again and again, for every letter typed. This, right here, is the battleground where hooks like `useMemo` live or die.

The “Why”: Referential Equality and The Endless Re-Render

Before we jump into fixes, you need to understand the root cause. It’s not really React’s fault; it’s how JavaScript works. In JavaScript, primitive types like strings and numbers are compared by their value. But objects and arrays? They’re compared by reference.

This means that every time your component re-renders, any object or array you define inside it gets a brand new identity in memory. So, even if the data inside is identical, the new object is not strictly equal (===) to the old one. React sees this “new” object as a changed prop and dutifully re-renders the child component that receives it, even if nothing visually needs to change. `useMemo` is a way to tell React: “Hey, don’t re-create this expensive thing unless its ingredients have *actually* changed.”

The Fixes: From Scalpel to Sledgehammer

I’ve seen teams go to two extremes: either they `useMemo` absolutely everything, cluttering the code and sometimes even making performance worse, or they never use it and wonder why their apps crawl. Here’s my playbook for handling it sanely.

Solution 1: The Tactical Strike (Using `useMemo` Correctly)

This is the quick fix, the scalpel. You use `useMemo` to wrap a specific, computationally expensive operation. The key word is expensive. Don’t wrap a simple array map unless that array has thousands of items. The overhead of the hook itself can be more costly than just re-running the simple calculation.

Let’s fix that dashboard problem from my story:

function LogDashboard({ massiveLogArray, userFilter }) {

  // The expensive part: filtering a huge array
  const filteredLogs = useMemo(() => {
    console.log('--- EXTREMELY EXPENSIVE FILTERING RUNNING ---');
    return massiveLogArray.filter(log => log.user.includes(userFilter));
  }, [massiveLogArray, userFilter]); // <-- The Dependency Array!

  return <DisplayLogs logs={filteredLogs} />;
}

The magic is the dependency array: `[massiveLogArray, userFilter]`. React will now only re-run that filtering function if `massiveLogArray` or `userFilter` changes its reference or value. If the component re-renders for another reason (like a parent’s state changing), React will just return the previously calculated, “memoized” value for `filteredLogs`. Quick, clean, and effective for targeted problems.

Darian’s Pro Tip: The dependency array is not optional. If you pass an empty array (`[]`), the memoized value will be calculated once and never again for the life of the component. This is a common source of bugs where you expect a value to update and it doesn’t.

Solution 2: The Architectural Fix (Rethinking Component Structure)

Often, the need for `useMemo` is a symptom of a larger architectural problem. Before you wrap everything in hooks, ask yourself: “Can I just prevent the re-render from happening in the first place?” One of the most powerful patterns for this is component composition, especially with the `children` prop.

The “Bad” Way:

function App() {
  const [searchTerm, setSearchTerm] = useState('');

  // Every time searchTerm changes, HeavyStaticComponent re-renders for no reason!
  return (
    <div>
      <input value={searchTerm} onChange={e => setSearchTerm(e.target.value)} />
      <HeavyStaticComponent /> 
    </div>
  );
}

The “Good” Way (Composition):

// This component now only knows about its own state.
function SearchContainer({ children }) {
  const [searchTerm, setSearchTerm] = useState('');

  return (
    <div>
      <input value={searchTerm} onChange={e => setSearchTerm(e.target.value)} />
      {/* React knows `children` hasn't changed, so it doesn't re-render it */}
      {children} 
    </div>
  );
}

function App() {
  // We pass the heavy component IN. It gets rendered once.
  return (
    <SearchContainer>
      <HeavyStaticComponent />
    </SearchContainer>
  );
}

In the second example, `HeavyStaticComponent` is created once inside `App` and passed down. When `SearchContainer`’s internal state changes, React sees that the `children` prop it received is still the same component from before, so it skips re-rendering it entirely. No `useMemo` needed. This is my preferred solution when applicable; it leads to cleaner, more decoupled components.

Solution 3: The Nuclear Option (`React.memo`)

Sometimes, you can’t change the architecture, and the props being passed down are complex objects or functions that are re-created on every parent render. The child component is “pure”—it would render the exact same output if you gave it the same props. This is when you bring out the heavy artillery: `React.memo`.

`React.memo` is a Higher-Order Component (HOC) that wraps your entire component and tells React: “Don’t re-render this component unless its props have actually changed.” It does a shallow comparison of the props.

import React from 'react';

// A component that's expensive to render, maybe an SVG chart.
function DataChart({ dataPoints }) {
  // ... very complex rendering logic here ...
  return <svg> ... </svg>
}

// Wrap it in React.memo
export const MemoizedDataChart = React.memo(DataChart);

Warning: This is a sledgehammer, not a scalpel. Do NOT wrap every component in `React.memo`. The shallow prop comparison it performs on every render has a cost. Only use it when a) the component is genuinely expensive to render, b) it renders often, and c) it usually renders with the same props. Profile first, then memoize.

My Final Take: A Quick Decision Guide

When you’re staring at a performance issue, here’s the thought process I go through.

At the end of the day, don’t guess. The React DevTools Profiler is your best friend. It will show you exactly why a component is re-rendering and how long it’s taking. Start with clean architecture, use `useMemo` for specific bottlenecks, and save `React.memo` for the truly heavy hitters. Happy coding.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions