Request Waterfalls and How to Avoid Them

The plain-language idea

A request waterfall happens when a parent component fetches data, and only after that fetch resolves does a child component render and start its own fetch — which resolves before a grandchild starts its own. Each request waits for the previous one to fully finish before it even starts, even though several of them never actually needed data from each other. The total load time becomes the sum of every request's duration, when it could have been closer to the slowest single request if they'd run together.

This usually isn't a deliberate design choice — it's an accident of component structure: data fetching gets placed at the point in the tree where it's convenient to write, not at the point where it's actually required.

See it in a real thing: a profile page's three independent fetches

// Waterfall: each fetch only starts after its parent's fetch resolves
function ProfilePage({ userId }: { userId: string }) {
  const [user, setUser] = useState<User | null>(null);
  useEffect(() => {
    fetchUser(userId).then(setUser);
  }, [userId]);

  if (!user) return <Spinner />;
  return <ProfilePosts userId={user.id} />;
}

function ProfilePosts({ userId }: { userId: string }) {
  const [posts, setPosts] = useState<Post[] | null>(null);
  useEffect(() => {
    fetchPosts(userId).then(setPosts);
  }, [userId]);

  if (!posts) return <Spinner />;
  return <ProfileStats userId={userId} postCount={posts.length} />;
}
// ...ProfileStats fetches a third thing, only after posts resolve

// Parallel: independent requests fire together, awaited together
function ProfilePage({ userId }: { userId: string }) {
  const [state, setState] = useState<{ user: User; posts: Post[]; stats: Stats } | null>(null);

  useEffect(() => {
    Promise.all([fetchUser(userId), fetchPosts(userId), fetchStats(userId)]).then(
      ([user, posts, stats]) => setState({ user, posts, stats })
    );
  }, [userId]);

  if (!state) return <Spinner />;
  return <ProfileView {...state} />;
}

Three requests, waterfall style: user first, then posts only after user resolves, then stats only after posts resolves.

BackNext

fetchPosts and fetchStats never actually needed data from fetchUser in this example — they only needed the same userId the page already had. Firing all three together with Promise.all (or lifting the fetches to a shared parent, or using a data-fetching library's parallel-query capability) turns three sequential round-trips into one wait for the slowest of the three.

What people usually miss

Watch out

• The bug is structural, not obvious from any single component. Each individual component's fetch looks completely reasonable in isolation — the waterfall only becomes visible when you look at the whole tree's request timing together, which is exactly why the Network tab (not code review) is the tool that actually catches it.
• Not every sequential chain is a bug — some are real dependencies. If a later request genuinely needs data returned by an earlier one, that's not a waterfall to fix, it's a real dependency chain (covered in the next lesson on telling these two cases apart).
• Fetching at a higher level and passing data down is often simpler than juggling Promise.all manually. If a parent already needs to fetch for its own reasons, having it fetch the children's data too and pass it down as props sidesteps the child components needing their own effects at all.
• A data-fetching library's parallel-query capability solves this at the framework level. Instead of manually orchestrating Promise.all, some fetching libraries let multiple components each declare their own query and the library coordinates firing them concurrently without a shared parent effect.

Why this matters in interviews

"How would you find and fix a page that's loading slower than it should?" is a real, common performance question, and naming the Network tab's staircase pattern as the concrete diagnostic — then explaining the Promise.all or lift-and-pass-down fix — shows hands-on debugging experience, not just textbook knowledge of the term "waterfall."