Re-Renders Explained: What Actually Happens When Frontend State Changes

One of the most common pieces of advice in frontend development is:

Avoid unnecessary re-renders.

You hear it when working with React, when discussing component performance, and when someone suggests memo, useMemo, or useCallback; eventually, it can start sounding as though re-rendering is inherently bad, but it isn’t.

Re-rendering is how modern UI frameworks keep the screen synchronized with application state.

Consider a simple counter:

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

The browser initially displays:

Count: 0

Then the user clicks the button.

Count: 0
    │
    │ click
    ▼
setCount(1)

The component re-renders.

Eventually, the browser displays:

Count: 1

That process sounds simple, but there are several steps hidden in between.

React doesn’t immediately replace the entire DOM.

The browser doesn’t repaint the entire page just because a state variable changed.

Instead, the framework performs work to determine what the UI should now look like, compares that result with what existed before, and updates only the parts of the real DOM that actually changed.

A simplified mental model looks like this:

State Change
    │
    ▼
Component Re-renders
    │
    ▼
New UI Description
    │
    ▼
Compare With Previous Result
    │
    ▼
Determine Actual Changes
    │
    ▼
Update DOM
    │
    ▼
Browser Rendering Pipeline

Understanding this process is important because it helps separate two ideas developers often confuse: React rendering and browser rendering, which are not the same thing.

---

React Rendering Is Not Browser Rendering

In the first article in this series, we explored the browser rendering pipeline:

DOM
 │
 ▼
Style
 │
 ▼
Layout
 │
 ▼
Paint
 │
 ▼
Composite
 │
 ▼
Pixels

That process belongs to the browser.

React’s rendering happens before that.

React decides what the DOM should look like.

The browser decides how that DOM becomes pixels.

Conceptually:

Application State
      │
      ▼
     React
      │
      ▼
DOM Changes
      │
      ▼
   Browser
      │
      ▼
Layout / Paint / Composite

This distinction matters.

A React component can re-render without causing any DOM update at all.

And if the DOM doesn’t change, the browser may have very little visual work to do.

---

What Happens When State Changes?

Let’s use a slightly larger example.

function Profile() {
  const [name, setName] = useState("Billy");

  return (
    <section>
      <h1>Hello, {name}</h1>

      <button onClick={() => setName("William")}>
        Change Name
      </button>
    </section>
  );
}

Initially, React produces a UI description conceptually similar to:

section
├── h1
│   └── "Hello, Billy"
└── button
    └── "Change Name"

After:

setName("William");

React renders the component again.

Now the result looks like:

section
├── h1
│   └── "Hello, William"
└── button
    └── "Change Name"

Most of the structure is identical.

Only one text value changed.

So React does not need to rebuild the entire DOM.

It only needs to update:

"Hello, Billy"
       ↓
"Hello, William"

The process can be understood as three broad stages:

Render
   │
   ▼
Reconciliation
   │
   ▼
Commit

Let’s look at each one.

---

The Render Phase

When a component re-renders, React executes the component function again.

That point is worth emphasizing.

Consider:

function Counter() {
  console.log("Counter rendered");

  const [count, setCount] = useState(0);

  return <p>{count}</p>;
}

Whenever React renders Counter, the function executes.

That means:

console.log("Counter rendered");

runs again.

So rendering does not mean React simply reuses the previous function result.

The component runs again to determine what the UI should look like for the current state and props.

Conceptually:

State = 0

Counter()
   │
   ▼
<p>0</p>

Then:

State = 1

Counter()
   │
   ▼
<p>1</p>

React now has a new description of the UI.

But no DOM changes necessarily happened yet.

That distinction becomes very important.

---

Reconciliation

Once React has the new result, it compares it with the previous one.

This process is known as reconciliation.

Suppose before:

<div>
  <h1>Products</h1>
  <p>3 items</p>
</div>

and after:

<div>
  <h1>Products</h1>
  <p>4 items</p>
</div>

The structure did not change.

The div still exists.

The h1 is the same.

Only the paragraph text changed.

React can therefore conclude:

Keep div
Keep h1
Keep p
Update text

instead of:

Delete everything
Recreate everything

This is the heart of reconciliation.

React is determining the minimum DOM work needed to make the actual interface match the new component output.

---

The Commit Phase

Once React knows what needs to change, it performs those mutations during the commit phase.

This is where the real DOM is updated.

So the flow becomes:

State Change
    │
    ▼
Render Phase
Component functions run
    │
    ▼
Reconciliation
Compare old and new
    │
    ▼
Commit Phase
Update actual DOM

Only after actual DOM changes occur does the browser potentially need to perform its own rendering work.

React Commit
     │
     ▼
DOM Changed
     │
     ▼
Browser
     │
     ├── Style?
     ├── Layout?
     ├── Paint?
     └── Composite?

This connects directly to everything we learned about reflow and repaint.

---

Re-Rendering Does Not Mean DOM Mutation

This is one of the biggest misconceptions in React performance discussions.

Suppose:

function Greeting({ name }) {
  console.log("render");

  return <h1>Hello {name}</h1>;
}

React may execute this component again.

But if:

name = "Billy"

both before and after the render, the resulting UI may be identical.

React can determine:

Previous: <h1>Hello Billy</h1>

New:      <h1>Hello Billy</h1>

No meaningful DOM change is required.

So:

Component Render
      ≠
DOM Update

And:

DOM Update
      ≠
Full Browser Repaint

These are separate stages.

That is why the statement:

“This component rendered again!”

doesn’t automatically mean:

“We have a serious performance problem.”

The cost depends on what happens during that render and what actual work follows.

---

Why Child Components Re-Render

This is another area that confuses many developers.

Consider:

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

  return (
    <>
      <button onClick={() => setCount(count + 1)}>
        Increment
      </button>

      <Header />
    </>
  );
}

Header doesn’t use count.

Yet when App re-renders, Header may also render again.

Why?

Because Header is part of the component tree produced by App.

Conceptually:

App re-renders
    │
    ├── Button
    │
    └── Header

React walks through that subtree to determine what the updated UI should look like.

Again, this doesn’t necessarily mean the DOM represented by Header changes.

The component can execute again while producing exactly the same result.

---

Parent Re-Render Does Not Mean Everything Changed

Suppose:

function Header() {
  return (
    <header>
      <h1>My Store</h1>
    </header>
  );
}

Every time the parent renders, this may execute again.

But React compares:

Previous Header

<header>
  <h1>My Store</h1>
</header>

with:

New Header

<header>
  <h1>My Store</h1>
</header>

Nothing changed.

So no DOM mutation is required.

This is why React can tolerate far more component renders than developers often assume.

The framework is designed around the idea that rendering should generally be cheap.

Problems appear when rendering itself becomes expensive.

---

When Re-Renders Actually Become Expensive

Imagine a component does this:

function Analytics({ transactions }) {
  const report = generateComplexReport(transactions);

  return <ReportView report={report} />;
}

If generateComplexReport() processes hundreds of thousands of records, every render can become expensive.

Now suppose a parent re-renders frequently.

Parent changes
     │
     ▼
Analytics renders
     │
     ▼
Expensive calculation

Even if the resulting DOM doesn’t change, the expensive JavaScript already ran.

This is where unnecessary rendering becomes a real performance problem.

The issue isn’t:

DOM updated too much

It might instead be:

JavaScript executed too much

That connects directly to the Event Loop article.

Heavy component rendering occupies the main thread just like any other JavaScript.

---

A Simple Example of Expensive Rendering

Consider:

function ProductList({ products, search }) {
  const results = products
    .filter(product =>
      product.name
        .toLowerCase()
        .includes(search.toLowerCase())
    )
    .sort((a, b) => a.price - b.price);

  return (
    <ul>
      {results.map(product => (
        <li key={product.id}>
          {product.name}
        </li>
      ))}
    </ul>
  );
}

For:

50 products

this probably doesn’t matter.

For:

500,000 products

it might.

Now imagine an unrelated state change causes the component to render repeatedly.

Theme toggled
     │
     ▼
Parent re-render
     │
     ▼
ProductList executes
     │
     ▼
Filter 500,000 products
     │
     ▼
Sort 500,000 products

Even if the product list itself didn’t actually change, substantial work occurred.

This is where memoization can help.

---

What useMemo Actually Does

Consider:

const filteredProducts = useMemo(() => {
  return products.filter(product =>
    product.name.includes(search)
  );
}, [products, search]);

The goal of useMemo is not:

Make React faster.

Its purpose is more specific.

It says:

Recalculate this value only when these dependencies change.

Conceptually:

Render
  │
  ▼
Did products or search change?
      │
   ┌──┴───┐
   │      │
  Yes     No
   │      │
   ▼      ▼
Calculate  Reuse

If some unrelated state changes:

sidebarOpen

the component may still re-render.

But the expensive product filtering can be skipped.

This distinction is important.

useMemo doesn’t necessarily prevent rendering.

It prevents recalculating a memoized result when dependencies haven’t changed.

---

Do Not Memoize Everything

After learning about useMemo, it’s tempting to do this:

const name = useMemo(() => {
  return `${firstName} ${lastName}`;
}, [firstName, lastName]);

But calculating:

`${firstName} ${lastName}`

is extremely cheap.

Now we’ve added:

Memoization logic
Dependency tracking
Additional code
Mental overhead

to avoid a trivial string concatenation.

Optimization itself has a cost.

A useful rule is:

Memoize expensive computations or values whose identity meaningfully matters, not every expression in your component.

Measure before making everything more complicated.

---

React.memo

Now suppose the expensive work happens inside a child component.

function Dashboard() {
  const [sidebarOpen, setSidebarOpen] = useState(false);

  return (
    <>
      <Sidebar open={sidebarOpen} />
      <ExpensiveChart />
    </>
  );
}

When sidebarOpen changes:

Dashboard re-renders
      │
      ├── Sidebar
      └── ExpensiveChart

But ExpensiveChart receives no changing props.

We may wrap it:

const ExpensiveChart = React.memo(function ExpensiveChart() {
  return <Chart />;
});

Now React can compare its props and potentially skip rendering the component when those props haven’t changed.

Conceptually:

Parent re-renders
      │
      ▼
Check child props
      │
   ┌──┴───┐
   │      │
Changed  Same
   │      │
   ▼      ▼
Render   Skip

Again, the point isn’t that every child should use React.memo.

It is useful when:

• The component renders frequently
• Rendering is meaningfully expensive
• Its props often remain unchanged

Otherwise, the additional complexity may provide little benefit.

---

Why React.memo Sometimes Doesn’t Work

Consider:

const ProductCard = React.memo(function ProductCard({
  product,
  onSelect
}) {
  return (
    <button onClick={() => onSelect(product.id)}>
      {product.name}
    </button>
  );
});

The parent does:

<ProductCard
  product={product}
  onSelect={(id) => setSelectedId(id)}
/>

Every parent render creates a new function:

(id) => setSelectedId(id)

Even though the function does the same thing, its identity is new.

Conceptually:

Previous render:

onSelect = Function A

New render:

onSelect = Function B

So from a shallow prop-comparison perspective:

Function A !== Function B

and the memoized child may render again.

This is where useCallback enters the picture.

---

What useCallback Actually Does

You might write:

const handleSelect = useCallback((id) => {
  setSelectedId(id);
}, []);

Then:

<ProductCard
  product={product}
  onSelect={handleSelect}
/>

Now the function reference can remain stable across renders unless its dependencies change.

Conceptually:

Render 1
handleSelect = Function A

Render 2
handleSelect = Function A

Render 3
handleSelect = Function A

This can help when function identity matters, especially when passing callbacks into memoized child components.

But again:

useCallback does not magically make a function faster.

It memoizes the function reference.

If nothing depends on that identity, it may provide no practical benefit.

---

useMemo vs useCallback

The difference is simple.

useMemo memoizes a value.

const total = useMemo(() => {
  return calculateTotal(items);
}, [items]);

useCallback memoizes a function reference.

const handleSave = useCallback(() => {
  save(items);
}, [items]);

Conceptually:

useMemo
   │
   ▼
Remember result


useCallback
   │
   ▼
Remember function

Both are performance tools.

Neither should automatically appear everywhere.

---

Object Identity Causes Similar Problems

Suppose:

<Chart
  options=
/>

Every render creates a new object.

Render 1 → Object A

Render 2 → Object B

Even though:

Object A contents
      =
Object B contents

their references differ.

If Chart is memoized and relies on shallow prop comparison, it may still render again.

One solution can be:

const options = useMemo(() => ({
  showLegend: true,
  responsive: true
}), []);

<Chart options={options} />

Now the object identity remains stable.

But the same warning applies:

Only optimize where the identity actually causes meaningful work.

---

Keys and Reconciliation

Keys are another important part of how React reasons about changes.

Consider:

{products.map(product => (
  <ProductCard
    key={product.id}
    product={product}
  />
))}

The key helps React identify which item corresponds to which previous item.

Suppose:

Before

A
B
C

then:

After

A
X
B
C

With stable keys, React can understand:

A → same
X → new
B → same
C → same

Without useful identity, React has a harder time reasoning about which items moved, appeared, or disappeared.

This matters not only for performance but also for preserving component state correctly.

---

Why Array Index Keys Can Be Problematic

Consider:

items.map((item, index) => (
  <Row key={index} item={item} />
));

Suppose:

0 → Alice
1 → Billy
2 → John

Then Alice is removed.

Now:

0 → Billy
1 → John

React sees:

key 0 still exists
key 1 still exists

even though the underlying items associated with those positions changed.

This can cause surprising state behaviour in interactive lists.

Stable business identifiers are usually better:

<Row
  key={user.id}
  item={user}
/>

Keys are fundamentally about identity.

They tell React:

This element represents the same conceptual thing as before.

---

State Position Matters

React associates state with a component’s position and identity in the rendered tree.

Imagine:

{loggedIn ? (
  <Dashboard />
) : (
  <Login />
)}

When the condition changes, one component leaves and another enters.

Its state lifecycle changes accordingly.

Similarly, changing a component’s key can cause React to treat it as a new component.

For example:

<Profile key={userId} userId={userId} />

Changing:

userId = 1

to:

userId = 2

can intentionally reset Profile state because React treats the new key as a different identity.

This can be useful for cases such as resetting forms when switching records.

---

Render Phase vs Effects

Now consider:

function Profile({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetchUser(userId).then(setUser);
  }, [userId]);

  return <ProfileView user={user} />;
}

The effect doesn’t run in the middle of calculating the component’s JSX.

Rendering determines what the UI should look like.

Effects are for synchronizing with things outside the pure render calculation, such as:

Network
Browser APIs
Subscriptions
Timers
Third-party libraries

This distinction helps explain why render functions should ideally remain pure.

Given the same state and props:

same input
   │
   ▼
same UI description

That makes React’s rendering model much easier to reason about.

---

Why Side Effects During Render Are Dangerous

Imagine:

function BadComponent() {
  fetch("/api/analytics");

  return <div>Hello</div>;
}

Every render triggers a network request.

If the component renders three times:

Render 1 → request

Render 2 → request

Render 3 → request

Now application behavior depends on how often React happens to render.

That is fragile.

Rendering should describe UI, not perform unrelated side effects.

Those operations belong in appropriate event handlers, effects, or data-fetching mechanisms.

---

Strict Mode Can Make This More Visible

During development, React Strict Mode may intentionally invoke certain logic more than once to help expose impure rendering and incorrect effect handling.

Developers sometimes see:

Why is this component rendering twice?

and assume React is broken.

But development behavior may deliberately stress-test assumptions.

That is another reason not to attach important side effects directly to render execution.

A component should remain safe to evaluate when React needs to understand what the UI should look like.

---

Re-Renders and Context

Suppose:

<AppContext.Provider
  value=
>
  <App />
</AppContext.Provider>

Many components consume this context.

Then:

notifications changes

The provider’s value changes.

Consumers may need to render again, including ones primarily interested in other parts of that context.

This is why very large contexts can sometimes become performance hotspots.

A better architecture might separate concerns:

UserContext

ThemeContext

CartContext

NotificationContext

or use a store with selector-based subscriptions.

Again, the principle from the previous state-management articles applies:

State distribution affects how much of your component tree responds when state changes.

---

Global State and Selectors

Imagine a store containing:

user
cart
theme
notifications
sidebar
products

A component needs only:

cart.length

A selector lets it subscribe to that specific information.

Conceptually:

Global Store
    │
    ├── Component A → user
    │
    ├── Component B → cart count
    │
    └── Component C → theme

Now:

user changes

doesn’t necessarily require the cart-count component to render.

This is one reason state architecture and rendering performance are deeply connected.

The question isn’t only:

Where do we store state?

It is also:

Which components are notified when that state changes?

---

Server State Can Trigger Re-Renders Too

From the previous article, we know server-state libraries maintain cached data.

Suppose:

const { data: products } = useQuery({
  queryKey: ["products"],
  queryFn: fetchProducts
});

The cache receives updated server data.

Old Products
      │
      ▼
Query Refetch
      │
      ▼
New Products
      │
      ▼
Subscribed Components Re-render

That is expected.

The important thing is that components interested in unrelated queries don’t need to respond.

Well-designed subscriptions help contain updates to the parts of the interface that actually care about them.

---

Rendering Large Lists

One place re-render costs become very visible is large collections.

Suppose:

{transactions.map(transaction => (
  <TransactionRow
    key={transaction.id}
    transaction={transaction}
  />
))}

For:

20 transactions

probably fine.

For:

100,000 transactions

you have a different problem.

Even if React efficiently reconciles the list, rendering and maintaining tens of thousands of DOM elements is expensive.

This is where virtualization becomes useful.

Instead of rendering every row:

Rows 1 → 100,000

render only the ones currently visible:

Rows 420 → 450

Conceptually:

Dataset

100,000 rows
     │
     ▼
Virtualizer
     │
     ▼
Visible viewport
     │
     ▼
~30 DOM rows

This reduces both framework rendering work and browser DOM/rendering work.

Libraries such as TanStack Virtual and react-window use this approach.

---

Component Boundaries Matter

Imagine one enormous component:

function Dashboard() {
  // 2,000 lines of state, calculations and JSX
}

Any state change causes that component’s render logic to execute again.

Breaking the interface into meaningful components can create clearer boundaries:

Dashboard
│
├── Header
├── BalanceCard
├── Transactions
├── SpendingChart
└── Goals

This does not automatically guarantee fewer renders.

But it creates opportunities for:

Independent state ownership
Memoization
Selective subscriptions
Smaller render workloads
Clearer architecture

Good component design is therefore partly about defining sensible rendering boundaries.

---

Should You Fear Re-Renders?

No.

This is probably the most important practical lesson in the article.

A component doing this:

function Name({ name }) {
  return <p>{name}</p>;
}

can execute extremely quickly.

Spending hours preventing that component from rendering again may make your code harder to maintain without producing any measurable user benefit.

Meanwhile, a single component containing:

Expensive calculations
Large lists
Complex charts
Heavy parsing

can create real problems.

So instead of:

How do I stop all re-renders?

ask:

Which renders are actually expensive?

That is a much healthier performance mindset.

---

The Wrong Way to Optimize

A codebase can quickly become:

const Component = memo(({ value }) => {
  const result = useMemo(() => calculate(value), [value]);

  const onClick = useCallback(() => {
    ...
  }, []);

  ...
});

everywhere.

Memoization becomes the default rather than a targeted optimization.

Now every developer has to reason about:

Dependencies
Stable references
Memoization boundaries
Stale closures
Prop identity

even when the underlying render takes microseconds.

You’ve optimized the framework workload while increasing human workload.

That’s not always a good trade.

---

Measure Before Optimizing

The browser and React both provide tools for identifying performance problems.

React DevTools includes profiling capabilities that can help answer questions such as:

Which component rendered?

How long did it take?

Why did it render?

Which parts of the tree were expensive?

Browser performance tools can then show what happened afterward:

JavaScript
     │
     ▼
DOM Commit
     │
     ▼
Layout
     │
     ▼
Paint

Combining the two gives you a much clearer picture.

Perhaps React rendering is expensive.

Perhaps React is fast and browser layout is the real problem.

Perhaps neither is the bottleneck and you’re waiting on a network request.

Optimization should follow evidence.

---

A Practical Example

Suppose a dashboard has:

function Dashboard() {
  const [sidebarOpen, setSidebarOpen] = useState(false);

  return (
    <>
      <Sidebar
        open={sidebarOpen}
        onClose={() => setSidebarOpen(false)}
      />

      <TransactionsTable />

      <LargeAnalyticsChart />
    </>
  );
}

Toggling the sidebar causes the dashboard to re-render.

If both TransactionsTable and LargeAnalyticsChart are cheap, stop there.

There may be nothing worth optimizing.

But suppose profiling reveals:

LargeAnalyticsChart render

180ms

every time the sidebar changes.

Now there is a measurable problem.

If the chart’s props remain unchanged, memoization may be appropriate:

const LargeAnalyticsChart = memo(
  function LargeAnalyticsChart({ data }) {
    return <Chart data={data} />;
  }
);

Perhaps chart data also requires an expensive transformation:

const chartData = useMemo(() => {
  return calculateAnalytics(transactions);
}, [transactions]);

Now the optimization has a reason.

Before

Sidebar toggle
     │
     ▼
Expensive analytics calculation
     │
     ▼
Chart render


After

Sidebar toggle
     │
     ▼
Cached analytics
     │
     ▼
Chart skipped / cheaper work

That’s much better than adding memoization everywhere “just in case.”

---

Rendering vs Committing

Another useful distinction is that React may perform rendering work that never reaches the DOM.

In modern React, rendering work can sometimes be interrupted, restarted, or discarded before it is committed.

That means:

Render work
    │
    ▼
Does React commit it?
    │
 ┌──┴───┐
 │      │
Yes     No
 │      │
 ▼      ▼
DOM    Discard

This is one reason render logic must remain pure.

React may evaluate a component without guaranteeing that the result becomes visible.

Side effects during rendering would therefore become unpredictable.

The commit phase is the point at which actual DOM changes are applied.

---

Re-Renders and the Event Loop

Everything we’ve discussed ultimately happens as JavaScript work on the main thread.

Suppose several expensive components render after one state update.

State Update
     │
     ▼
Component A     30ms
     │
Component B     40ms
     │
Component C     50ms
     │
     ▼
Total JS        120ms

The Event Loop article taught us what that means.

While this work runs:

User click       waiting
Animation        waiting
Rendering        waiting
Other JS         waiting

The issue isn’t merely that React “rendered too many times.”

The user-visible problem is that the main thread was occupied for too long.

That is why frontend performance concepts keep connecting back to one another.

---

Re-Renders and the Browser Rendering Pipeline

Now suppose React finishes reconciliation and commits:

width: 300px
      │
      ▼
width: 600px

React’s work is finished.

But the browser may now need:

Style
  │
  ▼
Layout
  │
  ▼
Paint
  │
  ▼
Composite

Alternatively, React might commit:

opacity: 0
     │
     ▼
opacity: 1

which may be handled much more cheaply.

So frontend performance has at least two separate dimensions:

Framework Work

Component rendering
Reconciliation
DOM updates

        +

Browser Work

Style
Layout
Paint
Composite

Optimizing only one side can leave the actual bottleneck untouched.

---

A Better Mental Model

When state changes, don’t imagine:

State changes
     │
     ▼
Entire page rebuilt

Think:

State changes
     │
     ▼
Affected component tree evaluated
     │
     ▼
New UI description
     │
     ▼
React reconciles
     │
     ▼
Actual differences identified
     │
     ▼
Necessary DOM mutations committed
     │
     ▼
Browser processes those changes

Every arrow represents a potential cost.

But none should automatically be assumed to be expensive.

---

Practical Rules for Re-Render Performance

A few principles go a long way: keep state as close as practical to the components that actually need it, avoid placing rapidly changing local state unnecessarily high in the tree, and avoid repeating expensive calculations on every render when memoization or restructuring can prevent that work.

Use stable keys for lists, apply memoization when profiling shows meaningful savings, design Context boundaries and global store subscriptions intentionally, virtualize genuinely large lists, and avoid side effects during render.

Above all, do not optimize purely based on how many renders a console statement reports.

A render is only a problem when the work involved is actually expensive enough to matter.

---

Bringing It All Together

A state update begins inside your application:

State
  │
  ▼
Re-render

That re-render produces a new description of the UI.

Component Function
       │
       ▼
New Element Tree

React compares it with what came before.

Previous Tree
      │
      ├────► Reconciliation
      │
New Tree

Only necessary changes are committed.

Difference
    │
    ▼
DOM Mutation

Then the browser takes over.

DOM
 │
 ▼
Style
 │
 ▼
Layout
 │
 ▼
Paint
 │
 ▼
Composite
 │
 ▼
Pixels

That gives us the full chain:

State Change
      │
      ▼
Component Render
      │
      ▼
Reconciliation
      │
      ▼
Commit
      │
      ▼
DOM Change
      │
      ▼
Browser Rendering
      │
      ▼
Updated Pixels

Once you understand those boundaries, performance discussions become much clearer.

You can ask:

Is the component render expensive?

Is reconciliation expensive?

Are we committing too many DOM changes?

Is layout the real problem?

Is painting expensive?

Is the main thread blocked?

Those are much better questions than simply asking:

Why is React re-rendering?

---

Final Thoughts

Re-renders have a reputation they do not entirely deserve: they are not bugs, they are not automatically performance problems, and preventing every possible render is not the goal of frontend engineering.

Rendering is how declarative UI frameworks work.

You describe:

What the UI should look like
for the current state.

Then the framework figures out how to get there.

The real performance question is not whether components render, but whether the amount of work happening during those renders prevents the application from delivering a smooth experience.

Sometimes the answer is yes: a large calculation runs repeatedly, a huge list is rendered unnecessarily, or a global state update wakes up hundreds of components, and those cases deserve optimization.

But often, rendering is already cheap, and in those cases adding layers of memoization can make the code harder to understand without making the application noticeably faster.

So the next time you see a component render again, don’t immediately ask:

“How do I stop this?”

Ask:

“What work is this render actually doing, and is that work expensive enough to matter?”

That is the question that leads to better frontend performance decisions.

---

What’s Next?

We’ve now explored how frontend state changes propagate through a component tree and eventually reach the browser.

Many of the expensive calculations we discussed share another important characteristic: sometimes the problem is not that the calculation is too slow, but that we are doing the same calculation repeatedly.

That brings us to another important frontend concept:

Memoization Explained: When Caching Computation Actually Helps

We’ll explore how memoization works, referential equality, memoized components, useMemo, useCallback, selectors, cache invalidation, and why adding memoization everywhere can sometimes make an application more complicated without making it any faster.

Because caching work is useful only when the work was worth avoiding in the first place.