[Atomic Glue](atomicglue.co)
PERFORMANCE
Home › Glossary › Performance· 400 ·

Streaming SSR

/ˈstriːmɪŋ ɛs ɛs ɑːr/n.
Filed underPerformanceArchitectureFront End
In brief · quick answer

A server-side rendering technique that sends HTML to the browser in chunks as they become available, rather than waiting for the full page to render. Dramatically improves FCP and Time to First Byte.

§ 1 Definition

Streaming SSR (Server-Side Rendering) uses the HTTP transfer-encoding: chunked or HTTP/2 server push to send HTML progressively to the browser. Instead of waiting for all data (database queries, API calls, component rendering) to complete before sending any HTML, the server sends the page shell (layout, navigation, above-fold content) immediately, then streams in dynamic content as it resolves. Streaming SSR is supported natively in React 18+ (renderToPipeableStream), Next.js App Router, and other modern frameworks.

§ 2 How It Works

The server begins rendering the page and flushes the HTML shell as soon as the initial markup is ready. Asynchronous data (API calls, database queries, heavy components wrapped in Suspense) completes later, and the resulting HTML is streamed to the client and injected into the DOM. The browser can start painting the shell and fetching subresources (CSS, images) while waiting for the rest of the page. This overlaps backend processing with network delivery.

§ 3 Common Misunderstandings

Streaming SSR does NOT make the server faster. It makes the page appear faster by sending content before all processing is done. TTFB may actually increase slightly because the server must begin rendering before flushing. Streaming also does NOT replace client-side interactivity: the streamed HTML still needs hydration for full interactivity. Also, streaming requires careful error handling: if a streamed component fails to render, the page shell is already delivered and cannot be replaced with an error page.

§ 4 Implementation

In React 18+: use renderToPipeableStream with Suspense boundaries to define what streams and what blocks. In Next.js: the App Router uses streaming SSR by default. Wrap slower data-fetching components in <Suspense> boundaries with fallback UI. Use the loading.js convention for route-level Suspense boundaries. Avoid wrapping small components individually (creates too many chunks). Test streaming behavior with DevTools network throttling.

§ 5 Note

Streaming SSR requires framework support. It is most beneficial for pages with slow data dependencies (auth checks, CMS API calls, personalization). Pages that are purely static or fully cached do not benefit.

§ 6 In code

// React 18 streaming SSR
import { renderToPipeableStream } from 'react-dom/server';

const { pipe } = renderToPipeableStream(<App />, {
  bootstrapScripts: ['/main.js'],
  onShellReady() {
    response.setHeader('content-type', 'text/html');
    pipe(response);
  }
});

// Next.js App Router: streaming by default
export default function Page() {
  return (
    <Layout>
      <Header />  {/* Streams immediately */}
      <Suspense fallback={<Loading />}>
        <SlowComponent /> {/* Streams when data arrives */}
      </Suspense>
    </Layout>
  );
}

§ 7 Common questions

Q. Does streaming SSR work with CDN caching?
A. Yes for the shell. The initial shell can be cached at the edge. The dynamic streamed portions are typically not cacheable.
Key takeaways
  • Sends HTML progressively as chunks.
  • Improves FCP by delivering shell immediately.
  • Requires Suspense boundaries in React.
  • Does not replace hydration for interactivity.
  • Best for pages with slow data dependencies.
How Atomic Glue helps

Atomic Glue implements streaming SSR in React and Next.js applications, identifying optimal Suspense boundaries and fallback UI strategies. Web Development services.

Get in touch
# Streaming SSR

A server-side rendering technique that sends HTML to the browser in chunks as they become available, rather than waiting for the full page to render. Dramatically improves FCP and Time to First Byte.

Category: Performance (also: Architecture, Front End)

Author: Atomic Glue Performance Team

## Definition

Streaming SSR (Server-Side Rendering) uses the HTTP transfer-encoding: chunked or HTTP/2 server push to send HTML progressively to the browser. Instead of waiting for all data (database queries, API calls, component rendering) to complete before sending any HTML, the server sends the page shell (layout, navigation, above-fold content) immediately, then streams in dynamic content as it resolves. Streaming SSR is supported natively in React 18+ (renderToPipeableStream), Next.js App Router, and other modern frameworks.

## How It Works

The server begins rendering the page and flushes the HTML shell as soon as the initial markup is ready. Asynchronous data (API calls, database queries, heavy components wrapped in Suspense) completes later, and the resulting HTML is streamed to the client and injected into the DOM. The browser can start painting the shell and fetching subresources (CSS, images) while waiting for the rest of the page. This overlaps backend processing with network delivery.

## Common Misunderstandings

Streaming SSR does NOT make the server faster. It makes the page appear faster by sending content before all processing is done. TTFB may actually increase slightly because the server must begin rendering before flushing. Streaming also does NOT replace client-side interactivity: the streamed HTML still needs hydration for full interactivity. Also, streaming requires careful error handling: if a streamed component fails to render, the page shell is already delivered and cannot be replaced with an error page.

## Implementation

In React 18+: use renderToPipeableStream with Suspense boundaries to define what streams and what blocks. In Next.js: the App Router uses streaming SSR by default. Wrap slower data-fetching components in <Suspense> boundaries with fallback UI. Use the loading.js convention for route-level Suspense boundaries. Avoid wrapping small components individually (creates too many chunks). Test streaming behavior with DevTools network throttling.

## Note

Streaming SSR requires framework support. It is most beneficial for pages with slow data dependencies (auth checks, CMS API calls, personalization). Pages that are purely static or fully cached do not benefit.

## In code

// React 18 streaming SSR
import { renderToPipeableStream } from 'react-dom/server';

const { pipe } = renderToPipeableStream(<App />, {
  bootstrapScripts: ['/main.js'],
  onShellReady() {
    response.setHeader('content-type', 'text/html');
    pipe(response);
  }
});

// Next.js App Router: streaming by default
export default function Page() {
  return (
    <Layout>
      <Header />  {/* Streams immediately */}
      <Suspense fallback={<Loading />}>
        <SlowComponent /> {/* Streams when data arrives */}
      </Suspense>
    </Layout>
  );
}

## Common questions

Q: Does streaming SSR work with CDN caching?

A: Yes for the shell. The initial shell can be cached at the edge. The dynamic streamed portions are typically not cacheable.

## Key takeaways

## Related entries


Last updated July 2026. Permalink: atomicglue.co/glossary/streaming-ssr

Schedule a call

30 min · Video call

1
Date
2
Time
3
Details