Streaming parts of a page with Suspense

When one slow widget holds the page hostage

loading.js has a blunt edge: it replaces the entire page until all of the page's data resolves. Real pages are rarely uniformly slow — a dashboard's header and nav render in milliseconds while one revenue chart waits two seconds on an analytics API. Making users stare at a full-page skeleton because of one widget is the problem streaming solves, and it is why production dashboards (Vercel's own included) feel fast even when their data is slow.

The tool is React's <Suspense> component, which you can place around any slow subtree yourself:

// app/dashboard/page.js
import { Suspense } from "react";
import RevenueChart from "./revenue-chart"; // async server component, slow fetch

export default function DashboardPage() {
  return (
    <>
      <h1>Dashboard</h1>
      <Suspense fallback={<p>Loading revenue…</p>}>
        <RevenueChart />
      </Suspense>
    </>
  );
}

The server sends the heading (and everything else fast) immediately, with the fallback in the chart's slot. When RevenueChart's data resolves, the server streams the finished HTML down the same response and React slots it in — no extra request, no full reload.

loading.js was Suspense all along

Now the Unit 4 picture completes: loading.js is just Next.js wrapping your whole page in one <Suspense> whose fallback is that file. Hand-placed <Suspense> is the same mechanism at finer grain.

Choosing between them:

• loading.js — the whole page depends on one main fetch (a blog post page). Zero extra code.
• <Suspense> islands — a mostly-fast page with one or two slow regions (dashboards, home pages with recommendations). Fast parts paint instantly.
• They compose: loading.js covers the navigation, inner <Suspense> boundaries cover the stragglers.

One discipline note: the slow fetch must live inside the wrapped component. If the page component itself awaits the data and passes it down as props, the whole page still waits before anything streams.