Streaming with Suspense in the App Router

The plain-language idea

Without streaming, a server has to finish rendering the entire page before it can send any of it — one slow query anywhere on the page blocks everything, even parts that had nothing to wait on. Streaming changes this: the server sends HTML in multiple chunks over the same connection as they become ready, using chunked transfer encoding. The browser starts painting the first chunk immediately instead of waiting for the last one.

The App Router streams around <Suspense> boundaries. Everything above or outside a <Suspense> boundary — layouts, navigation, a boundary's own fallback UI — forms the static shell, sent as the very first chunk. Whatever's inside a boundary streams in as a separate chunk once its async work (a data fetch, a slow query) resolves. Each boundary is independent: a boundary that resolves in 200ms doesn't wait on a sibling boundary that takes 3 seconds.

See it in a real thing: a dashboard where one widget is slow

// app/dashboard/page.tsx
import { Suspense } from "react";
import { Revenue } from "./revenue";
import { SlowRecommendations } from "./slow-recommendations";

export default function Dashboard() {
  return (
    <div>
      <h1>Dashboard</h1>
      <Revenue />
      <Suspense fallback={<p>Loading recommendations…</p>}>
        <SlowRecommendations />
      </Suspense>
    </div>
  );
}

A request comes in. The server starts rendering the static shell — everything outside any Suspense boundary, plus that boundary's fallback.

BackNext

<h1> and <Revenue /> render as part of the static shell and paint instantly, because nothing above them awaits anything. <SlowRecommendations /> is wrapped in <Suspense>, so its fallback ships with that same first chunk, and its real content streams in as a second chunk once its data resolves — the rest of the page is already visible and interactive by then. Dropping a loading.tsx file next to page.tsx gets you this same behavior automatically for the whole page, wrapped in one implicit <Suspense> boundary — useful when nothing on the page can render meaningfully until data resolves, but coarser than placing boundaries by hand.

What people usually miss

Watch out

• This is server-side HTTP streaming, not client-side code-splitting. React's React.lazy() + <Suspense> for a lazy-loaded component defers downloading a JS bundle in the browser; the App Router's streaming defers server-rendered HTML behind a data fetch. Same component, different problem.
• loading.tsx wraps the whole page in one boundary. It's a shortcut for a full-page skeleton, not a substitute for placing <Suspense> around just the slow section — the latter lets more of the real page ship in the static shell instead of a generic loading state.
• Once a fallback has flushed, the HTTP status code is locked at 200. A notFound() or redirect() that fires after streaming has started can't rewrite the response headers — Next.js falls back to a client-side redirect or a noindex meta tag instead of a real HTTP 4xx. Put existence checks before any await or <Suspense> boundary if you need a real status code.
• A buffering proxy, CDN, or compression layer defeats streaming even though the server generated it progressively. The HTML can be leaving the server in chunks and still arrive at the browser as one blob if something in between collects it first — this is a real infra thing to check, not something you can verify by reading the component code alone.

Why this matters in interviews

"A dashboard has a fast widget and a widget backed by a slow third-party API — how do you keep the slow one from blocking the fast one?" tests whether a candidate reaches for a targeted <Suspense> boundary around just the slow piece, and can explain that this is server HTML arriving in pieces, not a client-side loading spinner they're already used to from plain React.