Frontend Beauty
ESC

Type to search the knowledge base.

Streaming and Suspense Boundaries

Stream HTML/RSC payloads with Suspense in Next.js: loading.tsx, nested boundaries, and faster first paint.

advanced3 min read
  • nextjs
  • streaming-and

Streaming sends UI to the browser progressively as server work finishes, instead of waiting for every fetch. In the App Router, Suspense boundaries (including loading.tsx) define the chunks.

Docs: Loading UI and Streaming.

Nested boundaries

// app/product/[id]/page.tsx
import { Suspense } from 'react';

export default async function ProductPage({ params }) {
  const { id } = await params;
  const product = await getProduct(id); // critical
  return (
    <div>
      <h1>{product.title}</h1>
      <Suspense fallback={<ReviewsSkeleton />}>
        <Reviews productId={id} />
      </Suspense>
      <Suspense fallback={<RelatedSkeleton />}>
        <Related productId={id} />
      </Suspense>
    </div>
  );
}

async function Reviews({ productId }) {
  const reviews = await getReviews(productId); // slow
  return <ReviewList reviews={reviews} />;
}

Shell and product title can stream first; reviews fill in later — better perceived LCP/TTFB tradeoffs.

loading.tsx

A route segment’s loading.tsx is an implicit boundary around page content. Deeper Suspense refine which panels wait independently.

What blocks streaming

  • Awaiting everything in the parent before returning JSX.
  • Dynamic APIs forcing full dynamic render without boundaries.
  • Client JS that must hydrate before meaningful paint (minimize with Server Components).

Interview out-loud

“Streaming sends completed RSC/HTML chunks as Suspense resolves. I await critical data in the page shell and wrap slow panels in Suspense or loading.tsx so users see structure early. Nested boundaries isolate failures and delays.”

Further reading

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Quick self-test

Explain the concept in 60 seconds, write a minimal code sample from memory, name one footgun, and point to the primary docs. If any of those fail, reread the worked example and rebuild it in a scratch file until the model sticks under interview pressure.

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides