Optimizing React Suspense: How Concurrent Mode Handles Data Fetching and Rendering

You know that awkward moment when your Suspense fallback flashes on the screen for just a split second before your real content pops in? Sometimes it feels like the loading spinner is playing peekaboo, and you wonder if you’re doing something wrong.

Spoiler: React’s Concurrent Mode isn’t broken. Suspense is designed to juggle data fetching and rendering in a way that feels smooth , if you understand what it’s doing behind the scenes.

The familiar pain: flickering loading states

Imagine you have a React component that fetches user data. You wrap it in a <Suspense fallback={<Spinner />}>. When the data isn’t ready, the spinner shows. When the data arrives, the real UI replaces it.

But sometimes you see the spinner flash, then the content appears, then maybe the spinner shows again briefly. This flicker isn’t just a UI glitch , it’s React’s scheduler at work.

Why?

React’s Scheduler and Priorities: The secret sauce

Concurrent Mode introduced a sophisticated scheduler inside React. Instead of rendering everything synchronously, React breaks work into small units and assigns priorities.

When data fetching suspends, React marks that work as low priority. It shows the fallback immediately , because that’s the quickest thing to do. Meanwhile, React keeps trying to fetch data and prepare the real UI.

The scheduler can pause, resume, or even abandon work if higher priority tasks come in (like user input). This flexibility lets React keep the app responsive, but it also means your Suspense fallback might show or hide multiple times as React juggles work.

How Suspense boundaries manage concurrent rendering

Suspense boundaries are like gates controlling what the user sees. When a component suspends (e.g., waiting for a Promise), React doesn’t throw an error , it throws the Promise up the tree to the nearest Suspense boundary.

That boundary catches it and shows the fallback UI.

But here’s the catch: React doesn’t block the entire tree. With Concurrent Mode, it continues working on other parts of the UI that don’t depend on the suspended data.

This means multiple Suspense boundaries can show independent loading states, and content can appear incrementally.

Data fetching under the hood: how React knows when to show what

React Suspense for data fetching usually relies on throwing Promises from your components , a pattern popularized by libraries like Relay and React Cache.

When a component tries to read data that isn’t ready, it throws a Promise. React catches it, shows the fallback, and retries the render when the Promise resolves.

This retry is scheduled with the scheduler’s priority rules. If the Promise resolves quickly, React can skip showing the fallback at all, resulting in zero loading flicker.

If it takes longer, the fallback shows up to give the user feedback.

Why Suspense fallback flickers , and how to fix it

The flicker often happens because the Promise resolves just after React commits the fallback UI.

React can’t know for sure if the data will be ready immediately or soon, so it shows the fallback first. Then it re-renders the content. This is a tradeoff between showing feedback early and avoiding unnecessary spinners.

To reduce flicker:

• Use techniques like delayMs and timeoutMs in libraries like React Suspense’s experimental helpers to avoid showing fallback UI for very fast loads.

• Cache data aggressively so that components can read synchronous results immediately.

• Break your UI into smaller Suspense boundaries so React can show partial content as soon as it's ready.

• Use startTransition from React 18 to mark data loading as low priority, allowing React to prioritize user interactions.

What actually happens during a Suspense update

Let’s walk through a concrete example:

1. Your component tries to read user data.
2. The data isn’t ready, so it throws a Promise.
3. React catches this, marks the component as suspended, and shows the fallback.
4. The Promise resolves.
5. React schedules a low priority update to retry rendering the component.
6. React renders the component with the data, replaces the fallback.

Step 3 → step 6 can happen quickly or with noticeable delay, depending on network and cache.

Concurrent Mode juggling multiple updates

Concurrent Mode also means React can interrupt a render mid-way.

If a high priority update arrives (like user input), React can pause the Suspense update, respond to the user, then resume rendering.

This behavior makes apps feel snappy but adds complexity to Suspense timing.

Why Suspense is still evolving

React Suspense and Concurrent Mode are a work in progress. The React team continuously improves the scheduler heuristics to minimize flicker and improve perceived performance.

Meanwhile, understanding these internals helps you design data fetching and UI boundaries that fit React’s model.

Wrapping up

Next time your Suspense fallback flashes unexpectedly, don’t panic. It’s React juggling priorities to give your users the best experience.

With some tuning , smarter caching, strategic Suspense boundaries, and startTransition , you can help React show your UI at just the right moment.

Suspense isn’t magic, but it’s a clever balancing act. Knowing what happens under the hood is the first step to mastering it.