[React 19] Suspense throttling behavior (`FALLBACK_THROTTLE_MS`) kicks in too often

[uhyo]

React version: 19.0.0

Related Issues: #30408, #31697

This may be the intended behavior, but I'm opening this issue anyway because enough discussion hasn't been done in the related issues IMO and the current behavior still feels poor to me in that it makes it too easy to slow down actual user experience.

Steps To Reproduce

Code

const zero = Promise.resolve(0);

function getNumber(num) {
  return new Promise((resolve) => {
    setTimeout(() => resolve(num), 100);
  });
}

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

  const countValue = use(count);

  useEffect(() => {
    console.log("countValue =", countValue, Date.now());
  }, [countValue]);

  return (
    <button
      onClick={() => {
        console.log("click", Date.now());
        setCount(getNumber(countValue + 1));
      }}
    >
      count is {countValue}
    </button>
  );
}

In short, when a rerendering suspends, you always have to wait for 300ms even if underlying data fetching has finished sooner.

In the attached example, when user pushes the button, a new Promise is passed to use(), which triggers Suspense. Even though that Promise resolves exactly after 100ms, the UI is updated only after 300ms.

I experienced this issue when using Jotai, a Suspense-based state management library.

Given that the throttling behavior kicks in even in this simplest situation, it seems impossible to implement a user experience that involves Suspension and is quicker than 300ms regardless of, say, user's network speed.

Link to code example:

https://codesandbox.io/p/sandbox/4f4r94

The current behavior

Almost always need to wait for 300ms.

The expected behavior

Maybe some better heuristic for enabling the throttling behavior? It would also be very nice to make this configurable.

[eps1lon]

The alternative of quickly flashing the Suspense boundary fallback isn't better from our experience. In real apps, that would usually mean unmounting a large chunk of the screen for a very short period which doesn't make for a pleasant UX.

There isn't a correct number here since this is just a heuristic. 300ms felt like a good middleground between avoiding jank and feeling too sluggish.

A real-world example would help illustrate the issue.

Keep in mind, that you can always wrap the update in startTransition and display smaller fallback while isPending from useTransition is true.

[uhyo]

@eps1lon Thank you for the response. I have two questions now:

First, I understand that flashing UI isn't good user experience, but I still don't see any reason to make user wait for extra hundreds milliseconds, especially when the situation is this simple where there is only one ongoing suspension.

300ms at maximum isn't always a reasonable cost for making the UI look a bit less janky IMO.

Secondly, I see that useTransition could work. However if I understand correctly transitions are for non-blocking updates; in other words, state updates are marked as non-urgent if performed within a transition.

Using transitions for letting user see new data more quickly is quite counterintuitive to me. Am I getting anything wrong?

I don't have a truly real-world example but I think I can prepare something that looks more real-worldy if wanted.

[Tasin5541]

There are use cases where the suspense bound components are very small and can take less than 100ms to load (depends on the server as well). We used to not show anything as a fallback to avoid the jankiness. This is intentional, so that initial bundle size is low but end user also doesn't have to see these fallbacks for every little lazy loaded components. Now with this 300ms hold up, there's no other way than showing a fallback, which in turn feels like a worse UX. Instead of making this behavior the default, it should be opt in based.

[domarmstrong]

It appears that any time a lazy component is initialised it also kicks in the 300ms suspense, even if there is nothing that needs to load. We have our bundle split so we may have 10 or so lazy wrapped component (views) in one chunk, so the first time you hit one of the views the chunk is loaded, then switching between the views is instant. Now it seems that you have to wait 300ms and show a spinner even though nothing is being loaded after the initial chunk load, which is a notable degradation from an instant page change. After the lazy components initialise the changes are instant though on subsequent changes. But the artificial pause really isn't great.

[rossipedia]

Instead of making this behavior the default, it should be opt in based.

I'm fine with defaults, as long as there are escape hatches. This should 100% be configurable, with the option to disable it entirely. It's not really React's responsibility to make this kind of choice for every app.

[Janpot]

It appears that any time a lazy component is initialised it also kicks in the 300ms suspense, even if there is nothing that needs to load. We have our bundle split so we may have 10 or so lazy wrapped component (views) in one chunk, so the first time you hit one of the views the chunk is loaded, then switching between the views is instant. Now it seems that you have to wait 300ms and show a spinner even though nothing is being loaded after the initial chunk load, which is a notable degradation from an instant page change. After the lazy components initialise the changes are instant though on subsequent changes. But the artificial pause really isn't great.

Seeing similar behavior, but only under webpack. Reproductions in mui/material-ui#44920 (comment).

[domarmstrong]

So I can remove the 'always 300ms' fallback by using useDeferredValue in tandem with a use of useSyncExternalStore as noted here (which honestly makes no sense as a dev/lib user, sync updates cause an async fallback, but making it async avoids the async fallback to show, wat?) . Similarly you could wrap any state calls that cause lazy components to render in startTransition for a similar solution.

However, mixing the use of deferred values/transitions with any non deferred/transition code can easily cause bugs. It's also sadly very easy to do. You need to be aware of what the internals of some hook or util may be doing.

So the current situation seems to be:

• use deferred/transitions - lots of foot guns and potentially easy to have bugs. Also the whole team needs to suddenly be thinking about another concept that previously didn't exist and wasn't a problem (this really puts me off, we didn't have a problem before that this is solving).
• live with 300ms delays when there is no need for them

I'll take a bit of flicker sometimes to avoid either of these. So configurability would be greatly appreciated.

[oliviertassinari]

A Reddit discussion about this https://www.reddit.com/r/reactjs/comments/1hjoplz/react_19_scheduler_does_something_silly/