Post

This behavior made me think there was a perf regression when upgrading to React 19: github.com/facebook/rea.... Turns out it was because transitions weren't firing anymore (behavior change?) and then the 300ms fallback being shown made it look slow.

github.com[React 19] Suspense throttling behavior (`FALLBACK_THROTTLE_MS`) kicks in too often · Issue #31819 · facebook/reactReact 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 th...

The transitions not firing was interesting. In React 18 I had a transition start that was technically async (start transition -> iframe message -> get message back -> set state to trigger suspense). In React 19 that doesn't work anymore.

6/2/25, 11:13 am0 reposts3 likes

Yeah, this is a controversial one but I think the tradeoff off makes sense if you consider the UX without it.

The principle is that if you paint a loading state to the user, you should show it for a small amount of time so the user can at least see the fallback instead of seeing flickers in the UI.

As devs we care a lot about raw perf, but UX research shows that flickering is perceived as slower than showing a loading state (to a point). Slower is sometimes better. So yes the throttling is a perf tax, but it’s a UX gain.

It’s also not always slower. I’ve built some demos that show throttling can result in getting to the final content faster, because multiple commits of content can commit together (like two signings that suspend but resolve within 50ms of each other).