Fetch Waterfalls Across Nested Components

The plain-language idea

A fetch waterfall happens when a parent Server Component awaits its own data before it renders its children — and one of those children also fetches data. The child's fetch physically cannot start until React begins rendering the child, and React can't render the child until the parent's await resolves and the parent function returns JSX. Two requests that had nothing to do with each other end up running back to back anyway, purely because of where they live in the tree.

This is a different problem from writing sequential awaits inside a single function (covered in the parallel-fetching lesson) — no Promise.all inside the parent fixes it, because the second fetch isn't even in the parent's code.

See it in a real thing: a layout that blocks its own child

// app/dashboard/layout.tsx
async function getUser() {
  const res = await fetch("https://api.example.com/me");
  return res.json();
}

export default async function DashboardLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  const user = await getUser(); // blocks everything below

  return (
    <div>
      <Sidebar userName={user.name} />
      {children}
    </div>
  );
}

// app/dashboard/page.tsx
async function getStats(userId: string) {
  const res = await fetch(`https://api.example.com/stats/${userId}`);
  return res.json();
}

export default async function DashboardPage() {
  // This can't start until getUser() in the layout has resolved,
  // even though it doesn't need `user` — it just needs *a* user id
  // it happens to get from a separate call.
  const stats = await getStats("current");
  return <StatsPanel stats={stats} />;
}

The getStats call has no data dependency on getUser — it's blocked purely by nesting order: React can't start rendering DashboardPage until DashboardLayout finishes awaiting and returns.

The real fix is to start the fetch as early as possible, independent of where it's awaited — often by kicking it off at the top of the tree (or in a shared request-scoped cache) and only consuming the result deeper down, so the two requests overlap on the wire even though they resolve in different components.

What people usually miss

Watch out

• Promise.all can't fix a cross-component waterfall. It only helps when the multiple fetches live in the same function you control. Once one of them is inside a child component's own render, you need to restructure where the fetch happens, not just how it's awaited.
• A genuine data dependency isn't a waterfall bug. If the child truly needs a value the parent's fetch returned (an id, a token), the sequencing is correct and unavoidable — the fix is to shrink what the parent awaits before rendering, not to eliminate the dependency.
• Passing a promise down instead of an awaited value can defer the wait to where it's actually needed. A parent can call an async function without awaiting it, pass the resulting promise as a prop, and let a child component (or React's use() hook) await it later — letting the fetch start early while not blocking the parent's own render on it.

The genealogy: the component-tree cousin of a sequential-await bug

This is the same root cause as writing two independent awaits back to back in one function — needless serialization of work that could overlap — just expressed through component nesting instead of statement order. Wherever you see slow, staggered network requests in a Next.js app, check both: are the awaits in one function sequential when they don't need to be, and does the component tree itself force one fetch to wait on an unrelated one.