# The Hidden Cost of Rebuilds in Flutter

Imagine you’re in your house and you turn on the light in your bedroom … but somehow every single light in the house comes on — the kitchen, the bathroom, even the one outside that nobody uses. Nothing is technically broken; everything still works… but your electricity bill is quietly crying in the background. That’s exactly what happens in Flutter when rebuilds aren’t controlled — one small change ends up doing way more work than it needs to.

Flutter feels fast.

You update some data, call `setState()`, and everything just works.

The UI updates instantly.

At first, it feels like magic.

But as your app grows…

Things start to feel a bit off.

Not broken. Just… slower.

### The “Rebuilds Are Cheap” Idea

You’ve probably heard this:

> “Rebuilds in Flutter are cheap.”

And yes — they are.

Flutter is built to handle rebuilds efficiently.

* * *

But here’s the part people don’t talk about:

> Rebuilds are cheap… **until you start doing too many of them.**

### What Changes in Bigger Apps

In a small app:

*   only a few widgets rebuild
    
*   everything feels smooth
    

In a bigger app:

*   more widgets depend on the same state
    
*   more parts of the UI rebuild
    
*   updates start affecting larger sections
    

And slowly, you notice:

*   scrolling isn’t as smooth
    
*   taps feel slightly delayed
    
*   things just feel heavier
    

### The Real Problem

Rebuilds are not the problem.

The problem is:

> 👉 **rebuilding things that didn’t need to rebuild**

### A Simple Example

You update a counter:

```plaintext
setState(() {
  count++;
});
```

Looks simple.

But if that `setState` is high up in your widget tree…

👉 it can cause a large part of your UI to rebuild

Even widgets that didn’t change at all.

### What’s Really Going On

Flutter rebuilds widgets from the point where state changes.

So if your state is too high:

👉 everything below it gets rebuilt

That’s where the hidden cost comes from.

Not one rebuild.

But **too many unnecessary ones.**

### A Better Way to Think About It

Don’t try to avoid rebuilds.

Instead:

> 👉 **control where rebuilds happen**

### Simple Ways to Fix This

## 1\. Keep State Close to Where It’s Used

Don’t put all your state at the top.

Move it closer to the widgets that actually need it.

## 2\. Break Your UI Into Smaller Widgets

Smaller widgets = smaller rebuild areas

Even if it feels like “too many widgets” — it helps.

## 3\. Don’t Rebuild the Whole Screen

Only update what actually changed.

## 4\. Use Tools That Limit Rebuilds

Things like:

*   `ValueListenableBuilder`
    
*   `Selector`
    
*   Riverpod’s `select`
    

👉 help you rebuild only what matters

### Why This Matters More Over Time

In small apps, you won’t notice this.

In bigger apps:

*   Small inefficiencies add up
    
*   performance slowly drops
    
*   bugs become harder to track
    

### The Tricky Part

Rebuild issues don’t crash your app.

They don’t show errors.

They make your app feel:

*   slower
    
*   heavier
    
*   less smooth
    

### Key Takeaways

*   Rebuilds are not free forever
    
*   Too many rebuilds hurt performance
    
*   Most problems come from poor structure
    
*   Keeping state local helps a lot
    

### Final Thought

Flutter isn’t slow.

But your app can become slow if it’s doing more work than it needs to.

## 💬 Simple Way to Remember

> Don’t rebuild everything.  
>   
> Rebuild only what matters.