DEV Community: Abhijeet Srivastava

Why useCallback alone didn't make my React app faster — and what it's actually for

Abhijeet Srivastava — Sat, 25 Jul 2026 22:31:39 +0000

Almost every explanation of useCallback says something like this:

"Wrap your functions with useCallback to improve performance and prevent unnecessary re-renders."

Naturally, I believed that simply adding useCallback would make my React components render less often.

So I decided to verify it.

I built a tiny React example expecting to see fewer renders and better performance.

Instead...

Nothing changed.

The component still rendered after every click. The UI behaved exactly the same.

At that point I realized I wasn't asking the right question.

The better question was:

If useCallback doesn't stop components from rendering, what problem is it actually solving?

To answer that, I built three progressively more realistic examples.

We'll start with the simplest one.

Experiment 1: What does `useCallback` actually return?

Before talking about performance, let's ignore optimization completely and focus on one thing:

What does useCallback actually give us?

Here's a small component.

import { useCallback, useEffect, useState } from 'react'

export default function App() {
  const [count, setCount] = useState(0)

  const increment = () => {
     setCount((c) => c + 1)
  };

  useEffect(() => {
    console.log('increment reference changed')
  }, [increment])

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>Increment</button>
    </div>
  )
}

Now open the browser console. Click Increment five or six times. You'll notice two things.

The component re-renders after every click (the count updates as expected).
increment reference changed appears after every render, because a brand new increment function is created each time.

Now wrap increment function with useCallback like this:

  // useCallback returns the same function reference
  // until one of its dependencies changes.
  const increment = useCallback(() => {
    setCount(c => c + 1)
  }, [])

Now you will notice the message increment reference changed appears only once.

So what changed? The rendering? No. The UI? No.

Only the function reference.

You can visualize it like this.

Without useCallback

Render #1
increment ───► Function A

Render #2
increment ───► Function B

Render #3
increment ───► Function C

Every render creates a new function object.

With useCallback

Render #1
increment ───► Function A

Render #2
increment ───► Function A

Render #3
increment ───► Function A

The component still renders. But React keeps reusing the same function object.

So... did we actually improve performance?

Not really.

The component still re-renders after every click. The button still behaves exactly the same. Nothing feels faster.

At this point, all we've proven is this:

useCallback doesn't stop React from rendering. It simply keeps a function reference stable between renders.

And that immediately raises another question.

If the function reference stays the same, who actually benefits from that?

Right now... nobody.

The component isn't using that stable reference for anything. So the optimization doesn't translate into any visible performance improvement.

That might sound disappointing, but it's actually the key to understanding why useCallback exists.

Key takeaways

useCallback doesn't prevent a component from re-rendering.
It doesn't make the UI magically faster.
Its primary job is to preserve a function's identity across renders.
On its own, that stable function reference usually doesn't provide any measurable performance benefit.

So where does it become useful? The answer lies in another React optimization: React.memo. That's where a stable function reference suddenly matters a lot.

Experiment 2: `React.memo`

Let's set up an employee management screen. Each employee gets their own row, showing the employee's name, role, and a Promote button.

We'll use this example to see where React.memo helps—and where it surprisingly doesn't.

import React, { useState } from 'react';

const initialEmployees = [
  { id: 1, name: 'Aditi', role: 'Frontend Engineer' },
  { id: 2, name: 'Rohan', role: 'Backend Engineer' },
  { id: 3, name: 'Priya', role: 'Product Manager' },
  { id: 4, name: 'Karan', role: 'DevOps Engineer' },
  { id: 5, name: 'Sana', role: 'UX Designer' },
];

// EmployeeRow is a normal component.
// Whenever EmployeeTable re-renders, every EmployeeRow renders again.
const EmployeeRow = ({ employee }) => {
  console.log('Rendering row:', employee.name);

  return (
    <tr>
      <td>{employee.id}</td>
      <td>{employee.name}</td>
      <td>{employee.role}</td>
    </tr>
  );
};

export default function EmployeeTable() {
  const [employees, setEmployees] = useState(initialEmployees);

  const promoteEmployee = (id) => {
    setEmployees(prev =>
      prev.map(employee =>
        employee.id === id
          ? { ...employee, role: `${employee.role} (Lead)` }
          : employee
      )
    );
  };

  return (
    <table>
      <thead>
        <tr>
          <th>ID</th>
          <th>Name</th>
          <th>Role</th>
          <th>Action</th>
        </tr>
      </thead>

      <tbody>
        {employees.map(employee => (
          <React.Fragment key={employee.id}>
            <EmployeeRow employee={employee} />

            <tr>
              <td colSpan={4}>
                <button onClick={() => promoteEmployee(employee.id)}>
                  Promote {employee.name}
                </button>
              </td>
            </tr>
          </React.Fragment>
        ))}
      </tbody>
    </table>
  );
}

Open the browser console and click Promote for any employee. You'll see:

Rendering row: Aditi
Rendering row: Rohan
Rendering row: Priya
Rendering row: Karan
Rendering row: Sana

Every single employee row renders.

React re-runs a component's function every time its parent re-renders — regardless of whether that component's props actually changed.

Here's the chain of events:

You click a button → setEmployees updates state in EmployeeTable.
State change → EmployeeTable re-renders (its function body runs again).
During that render, React reaches employees.map(...) and creates a fresh <EmployeeRow employee={employee} /> element for every row.
For each of those elements, React calls the EmployeeRow function to get its output → your console.log('Rendering row:', ...) fires 5 times.

That feels like a problem. Each row represents an independent employee. If one employee changes, why should every other row render again? That's exactly what React.memo is designed to solve.

Wrap the row:

// React.memo compares the current props with the previous ones.
// If the employee prop hasn't changed, React skips re-rendering this row.
const EmployeeRow = React.memo(function EmployeeRow({ employee }) {
  console.log('Rendering row:', employee.name);

  return (
    <tr>
      <td>{employee.id}</td>
      <td>{employee.name}</td>
      <td>{employee.role}</td>
    </tr>
  );
});

Now, when you click Promote, only the row that changed logs a re-render.

React.memo wraps the component and inserts a shallow prop comparison before re-rendering.

On a parent re-render, React does:

Compare the new employee prop with the previous one using Object.is.
Same reference? → skip the function call → no console.log.
New reference? → re-run → console.log fires.

The Twist: Moving Promote into `EmployeeRow`

The promote button logically belongs inside each row, not the parent — promoting is a per-employee action. Let's move it.

Just two things change:

EmployeeRow now accepts an onPromote prop and renders its own Promote button.
EmployeeTable simply passes promoteEmployee to each row.

const EmployeeRow = React.memo(function EmployeeRow({ employee, onPromote }) {
  console.log('Rendering row:', employee.name);

  return (
    <tr>
      <td>{employee.id}</td>
      <td>{employee.name}</td>
      <td>{employee.role}</td>
      <td>
        <button onClick={() => onPromote(employee.id)}>
          Promote {employee.name}
        </button>
      </td>
    </tr>
  );
});

// Inside EmployeeTable, replace the <React.Fragment> block with:
{
  employees.map(employee => (
    <EmployeeRow
      key={employee.id}
      employee={employee}
      onPromote={promoteEmployee}
    />
  ));
}

At first glance this should still work — EmployeeRow is memoized, and only one employee object reference changes per click. Let's test it.

Open the browser console. Click Promote on any employee.

Rendering row: Aditi
Rendering row: Rohan
Rendering row: Priya
Rendering row: Karan
Rendering row: Sana

Every single employee row renders again. That's not what we expected — we already have React.memo, and only one employee object changed.

Why didn't React.memo prevent those re-renders?

The real culprit

Each row receives two props:

<EmployeeRow
  key={employee.id}
  employee={employee}
  onPromote={promoteEmployee}
/>

employee — only one employee object changed. No problem here.

onPromote — this is where it breaks down.

Render #1
promoteEmployee ───► Function A

Render #2
promoteEmployee ───► Function B

Render #3
promoteEmployee ───► Function C

JavaScript creates a brand-new function object every time the parent component renders. To us, those functions look identical. To React, they're completely different objects.

Why `React.memo` can't help

React.memo performs a shallow comparison of props. Since onPromote is a different reference on every render, React assumes the component might produce different output — so it re-renders the row, every time, for every row.

This explains why wrapping a component with React.memo isn't always enough.

The component is memoized. The data didn't change. But one prop keeps getting a brand-new reference every render, and that's enough to invalidate the memoization.

Key takeaways

React.memo can only skip rendering when all of a component's props stay the same.

The employee objects stayed the same. The callback didn't — and that single changing reference was enough to force every row to render again.

Doesn't that sound familiar? In Experiment 1, we learned that useCallback exists to keep a function reference stable. At the time, that didn't seem useful. Now we're looking at a component where a changing function reference is actively breaking React.memo.

Could these two ideas be connected?

Experiment 3: The piece we were missing

We now know exactly why React.memo wasn't helping. Every employee object except the promoted one kept the same reference, but onPromote received a brand-new function reference on every parent render. Every parent render created a new promoteEmployee function reference, and React.memo's shallow comparison detected that change every time.

The fix is just one line of code: keep that callback's reference stable across renders. That's exactly what useCallback was built for.

One line changes: wrap promoteEmployee with useCallback.

import { useCallback } from 'react';

// Replace the previous implementation with:
const promoteEmployee = useCallback((id) => {
  setEmployees(prev =>
    prev.map(employee =>
      employee.id === id
        ? { ...employee, role: employee.role + ' (Lead)' }
        : employee
    )
  );
}, []);

Notice that this is the only change. EmployeeRow, the JSX, and the table structure all remain exactly the same.

The dependency array is intentionally empty because setEmployees uses a functional updater (prev => ...). React automatically provides the latest state as prev, so promoteEmployee doesn't need employees as a dependency.

Click Promote on any employee now.

This time, only the promoted employee logs a re-render. The other four employee objects never changed reference — setEmployees only creates a new object for the promoted employee, the rest of the array entries are untouched — and promoteEmployee itself never changes reference either, so React.memo's comparison finally has stable ground to stand on.

Final code

If you'd like to run the finished version yourself, here's the complete component with both React.memo and useCallback applied.

import React, { useCallback, useState } from 'react';

const initialEmployees = [
  { id: 1, name: 'Aditi', role: 'Frontend Engineer' },
  { id: 2, name: 'Rohan', role: 'Backend Engineer' },
  { id: 3, name: 'Priya', role: 'Product Manager' },
  { id: 4, name: 'Karan', role: 'DevOps Engineer' },
  { id: 5, name: 'Sana', role: 'UX Designer' },
];

// EmployeeRow receives a callback prop (onPromote).
// React.memo only skips rendering when ALL props are shallowly equal.
// useCallback keeps the onPromote function reference stable so React.memo
// can recognize that unchanged rows don't need to render again.
const EmployeeRow = React.memo(function EmployeeRow({
  employee,
  onPromote,
}) {
  console.log('Rendering row:', employee.name);

  return (
    <tr>
      <td>{employee.id}</td>
      <td>{employee.name}</td>
      <td>{employee.role}</td>
      <td>
        <button onClick={() => onPromote(employee.id)}>
          Promote {employee.name}
        </button>
      </td>
    </tr>
  );
});

export default function EmployeeTable() {
  const [employees, setEmployees] = useState(initialEmployees);

  // The functional updater always receives the latest state,
  // so this callback doesn't need `employees` as a dependency.
  //
  // Without useCallback, every parent render would create a new
  // function reference, causing React.memo to re-render every row.
  const promoteEmployee = useCallback((id) => {
    setEmployees(prev =>
      prev.map(employee =>
        employee.id === id
          ? { ...employee, role: `${employee.role} (Lead)` }
          : employee
      )
    );
  }, []);

  return (
    <table>
      <thead>
        <tr>
          <th>ID</th>
          <th>Name</th>
          <th>Role</th>
          <th>Action</th>
        </tr>
      </thead>

      <tbody>
        {employees.map(employee => (
          <EmployeeRow
            key={employee.id}
            employee={employee}
            onPromote={promoteEmployee}
          />
        ))}
      </tbody>
    </table>
  );
}

So, should you wrap every function in `useCallback`?

Probably not.

Creating a new function during render is usually inexpensive. Using useCallback everywhere adds complexity and a small amount of overhead of its own, since React now has to store the callback and compare its dependencies on every render.

Instead, ask yourself one simple question:

Does anything actually care if this function changes?

If the answer is no, you probably don't need useCallback.

If the answer is yes — for example:

the function is passed to a component wrapped with React.memo
it's part of a useEffect dependency array
it's passed to a custom hook
a third-party library compares callback references

then useCallback is often the right choice.

A quick note about `useMemo`

If this reminds you of useMemo, that's because the underlying idea is similar.

useMemo memoizes values. useCallback memoizes function references. Both help React reuse the same identity across renders when their dependencies remain unchanged.

Final thoughts

When I started this experiment, I thought useCallback was a performance hook.

By the end, I realized it's really an identity hook.

It doesn't stop components from rendering. It doesn't magically make your application faster.

Its job is much smaller—and much more important. It gives React the ability to recognize that a function hasn't actually changed.

Sometimes that enables powerful optimizations. Other times, it changes absolutely nothing.

Understanding that difference is far more valuable than memorizing when to use useCallback.

How React.lazy() and Suspense Cut Bundle Size and Improve Performance

Abhijeet Srivastava — Sun, 12 Jul 2026 12:26:46 +0000

Recently, I was experimenting with React performance and wanted to answer a simple question:

How much can a single unused tab cost a React app on first load?

To find out, I built a small React application with an intentionally heavy tab and compared static imports with React.lazy(). The results were more significant than I expected.

Most websites ship more JavaScript than users actually need on first load.

A common example is a dashboard with multiple tabs:

Dashboard
Analytics
Reports
Settings

In a typical implementation, all four tab components are imported directly at the top of the file, so React can render whichever tab is active.
Here's the catch: if Analytics is imported statically, every user pays for that code on initial load, even if they never open that tab.

In this post, I’ll show:

the problem with static loading.
how to inspect bundle size and download time in DevTools.
how lazy loading splits bundles and reduces the first-load cost.
how the heavy analytics bundle gets loaded only when the user clicks the tab.

The Problem with Static Loading

For this example, I'll focus on just two of those tabs — Dashboard and Analytics — since that's enough to show the pattern clearly.

In the static version, the Analytics tab is imported like this:

import Dashboard from './tabs/Dashboard'
import Analytics from './tabs/Analytics'

export default function App() {
  const [tab, setTab] = useState('dashboard')

  return (
    <>
      <button onClick={() => setTab('dashboard')}>Dashboard</button>
      <button onClick={() => setTab('analytics')}>Analytics</button>

      {tab === 'dashboard' ? <Dashboard /> : <Analytics />}
    </>
  )
}

At first glance, this looks harmless.

But here’s the issue:

Analytics tab becomes part of the initial app bundle.
the browser downloads that code on first load.
any module-level initialization inside Analytics tab also runs immediately.
users who never click Analytics tab still pay the cost.

This is exactly the kind of hidden performance tax that accumulates in real apps.

The Example Setup

This example is built with Vite. I intentionally made the Analytics component heavy, so the difference would be clearly visible in the browser's Network tab.

It includes:

a large static payload bundled only with that tab.
module-level processing that runs as soon as the component loads.

A note on testing it locally:

Running it with yarn dev wouldn't have shown the real picture — Vite serves source modules individually in dev mode, which is fine for development but doesn't reflect actual production bundle sizes.

To see the real chunk sizes, I built and previewed the production version instead:

yarn build
yarn preview

I also kept Disable cache checked in Chrome DevTools' Network tab, so every screenshot reflects a genuine fresh network request rather than cached results.

That's what let me see the actual network behavior shown in the screenshots below.

Static Loading: What Happens

Here's what the static import version looks like in practice.

First, here's the production build output — the main bundle comes to 586.58 KB (280.86 KB gzip), and notice that the Analytics code is already part of it:

And here's the Network tab on initial page load — the Analytics code loads as part of the main bundle itself, before the user has ever opened that tab:

This has a few consequences:

the first bundle is larger as it includes Analytics code as well.
the initial download takes longer.
parsing and evaluating JavaScript takes longer.
users pay for optional UI up front, whether they use it or not.

This is the wrong tradeoff when the feature is not immediately needed.

That’s the key point:

The user has not clicked the Analytics tab yet, but the browser has already downloaded the code for it.

Fixing It with React.lazy() and Suspense

Here's the fix — instead of statically importing the Analytics tab, I deferred it using lazy():

import { lazy, Suspense, useState } from 'react'
import Dashboard from './tabs/Dashboard'

const Analytics = lazy(() => import('./tabs/Analytics'))

export default function App() {
  const [tab, setTab] = useState('dashboard')

  return (
    <>
      <button onClick={() => setTab('dashboard')}>Dashboard</button>
      <button onClick={() => setTab('analytics')}>Analytics</button>

      {tab === 'dashboard' ? (
        <Dashboard />
      ) : (
        <Suspense fallback={<div>Loading Analytics...</div>}>
          <Analytics />
        </Suspense>
      )}
    </>
  )
}

Here's the production build output with this change. Notice Analytics is no longer part of the main bundle — it's now its own separate chunk, and the main bundle has dropped to 194.06 KB (61.22 KB gzip):

And here's the Network tab on initial page load — only the Dashboard and core app code load upfront; the Analytics chunk isn't requested at all yet:

The moment I click the Analytics tab, the browser fetches that chunk on demand:

This changes behavior in an important way:

the initial bundle still includes Dashboard, but no longer includes Analytics.
the first-load download is smaller and faster, since Analytics isn't part of it.
the browser only requests the Analytics chunk when the user actually clicks that tab.

Build comparison

	Static	Lazy
Main bundle	586.58 KB	194.06 KB
Gzip	280.86 KB	61.22 KB

The result is a 66.9% reduction in the main bundle and a 78.2% reduction in the compressed JavaScript downloaded on first load.

That's the real value of lazy loading:

Reduce the JavaScript required for first paint, and defer optional feature code until the user actually needs it.

Why This Matters in Real Products

This pattern is useful whenever part of the UI is optional, secondary, or rarely visited.

It shows up not only in tabs like this, but also in components that live on specific routes — a heavy modal only reachable from a settings page, or a report screen that pulls in a heavy charting library only that page needs.

If the feature is not needed immediately, it usually should not be in the initial bundle.

One Important Caveat

Lazy loading is not magic.

It doesn't remove the cost of the code — it moves the cost from initial load to the moment the user actually needs that feature.

So the right question is not:

Can I lazy load this?

The right question is:

Should every user pay for this code on the first screen?

If the answer is no, lazy loading is often the right move.

Final Thought

React.lazy() and Suspense are really about one question:

Who should pay for this code, and when?

By default, every user downloads the code, whether they need the feature or not. Lazy loading shifts that cost to the moment it's actually needed, making the initial experience faster for everyone.

DEV Community: Abhijeet Srivastava

Why useCallback alone didn't make my React app faster — and what it's actually for

Experiment 1: What does useCallback actually return?

So... did we actually improve performance?

Key takeaways

Experiment 2: React.memo

The Twist: Moving Promote into EmployeeRow

The real culprit

Why React.memo can't help

Key takeaways

Experiment 3: The piece we were missing

Final code

So, should you wrap every function in useCallback?

A quick note about useMemo

Final thoughts

How React.lazy() and Suspense Cut Bundle Size and Improve Performance

The Problem with Static Loading

The Example Setup

Static Loading: What Happens

Fixing It with React.lazy() and Suspense

Why This Matters in Real Products

One Important Caveat

Final Thought

Experiment 1: What does `useCallback` actually return?

Experiment 2: `React.memo`

The Twist: Moving Promote into `EmployeeRow`

Why `React.memo` can't help

So, should you wrap every function in `useCallback`?

A quick note about `useMemo`