Render waterfalls
Slap yourself if
You think waterfalls are just ‘too many renders’ instead of a structural dependency problem.
Why this exists
Render waterfalls exist because UI rendering often encodes hidden sequential dependencies. Components wait on data, state, or effects that could have been resolved in parallel, but aren’t due to how the render pipeline is structured.
Mental model
A render waterfall is not slowness — it’s forced serialization. Each step blocks the next, even though the work itself isn’t inherently sequential.
- A parent render triggers a child render.
- The child blocks on data or state not yet available.
- That delay postpones rendering of deeper descendants.
- The UI progresses in stages instead of converging.
- Fetching data during render or effects without coordination.
- Conditional rendering that hides future dependencies.
- Component trees that encode data flow instead of layout.
- Assuming async work will naturally parallelize.
A render waterfall happens when rendering work is forced to resolve sequentially due to component or data dependencies, causing avoidable delays even though the underlying work could run in parallel.
- Nested loading states
- Effects that trigger more effects downstream
- Data fetching tied to component depth
- Progressive UI that feels slower than the network
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.