Let’s talk about something that happens to all of us online. You click a link, and then you wait. You stare at a blank screen or a spinning icon. Nothing seems to happen until, suddenly, the entire page snaps into place at once. This experience is common, especially on pages that need a lot of data. The page can’t show you anything until it has fetched everything. It’s like waiting for a chef to cook a five-course meal before you get even a piece of bread.

I used to build applications this way. We all did. We’d fetch data on the server, wait for all the database calls and API requests to finish, render the complete HTML, and then send it to the browser. It was efficient for the server, but for the person waiting, it felt slow. The browser was idle, just waiting for that big blob of HTML to arrive. This is the problem.

Now, imagine a different approach. What if we could send the bread out of the kitchen as soon as it was ready, then the soup, then the main course? You’d start eating much sooner, and the meal would feel faster and more responsive. This is the core idea behind streaming data with React Server Components. We send parts of the page to the user as soon as they are ready, not after everything is done.

React Server Components, particularly within frameworks like Next.js, let us do this. They allow the server to render our React components and then send that rendered output to the browser in chunks, as it becomes available. This isn’t about loading JavaScript; it’s about streaming the actual HTML content progressively. The browser can start painting the screen much earlier.

The technical magic behind this is a combination of two things: asynchronous components and something called Suspense. In the past, React components on the server were synchronous. They ran and returned JSX. Now, they can be async functions. They can await data. This small change is what enables streaming.

Here’s a simple mental model. You have a product page. The product title and price are crucial. The customer reviews and “frequently bought together” items are important but secondary. With traditional rendering, you’d wait for all four pieces of data before sending the page. With streaming, you can send the title and price immediately. While the user is reading that, the server is still fetching the reviews. When they’re ready, the server sends that HTML chunk, and it slots into place.

Let’s look at code. This is how you might structure a product page to stream.

// This is a Server Component. It runs on the server.
async function ProductPage({ productId }) {
  // Fetch critical product info immediately.
  const product = await fetchProduct(productId);
  
  // START fetching secondary data, but don't wait for it.
  // These are now Promises, not awaited results.
  const reviewsPromise = fetchReviews(productId);
  const relatedPromise = fetchRelatedProducts(productId);

  return (
    <div>
      {/* Render critical data straight away. */}
      <h1>{product.name}</h1>
      <p>{product.price}</p>
      <img src={product.imageUrl} alt={product.name} />
      
      {/* Wrap the slower sections in Suspense. */}
      <Suspense fallback={<div>Loading reviews...</div>}>
        {/* Pass the Promise to a component that knows how to wait for it. */}
        <ReviewsSection reviewsPromise={reviewsPromise} />
      </Suspense>
      
      <Suspense fallback={<div>Loading related products...</div>}>
        <RelatedProductsSection relatedPromise={relatedPromise} />
      </Suspense>
    </div>
  );
}

The Suspense component is the key. It’s a boundary you set up in your React tree. It tells React: “Everything inside me might take time to load. While it’s loading, show the fallback content I provided.” When the data inside resolves, React swaps the fallback for the real content. This happens via the streamed HTML.

The components that receive Promises need to handle them. They are also async.

// This component receives a Promise and waits for it.
async function ReviewsSection({ reviewsPromise }) {
  // This `await` will suspend the component until the Promise resolves.
  // React and the streaming renderer understand this.
  const reviews = await reviewsPromise;
  
  return (
    <section>
      <h2>Customer Reviews</h2>
      {reviews.map(review => (
        <div key={review.id}>
          <strong>{review.author}</strong>
          <p>{review.text}</p>
        </div>
      ))}
    </section>
  );
}

This pattern changes how you think about data fetching. You design your pages with priority in mind. What does the user need to see first? That becomes your initial, non-suspended content. What can come later? That goes inside Suspense boundaries.

The setup on the server side is crucial. You need a server that can render React to a stream. If you’re using Next.js with the App Router, this is built-in and configured for you. You simply create app/page.js or app/product/[id]/page.js as an async component, and Next.js handles the streaming automatically.

For a custom setup, it’s more involved. You need to use React’s renderToReadableStream function instead of the older renderToString.

// A very basic example of a custom server using Node.js and Express.
import { renderToReadableStream } from 'react-dom/server';
import React from 'react';
import App from './App.js';

app.get('*', async (req, res) => {
  // Create a stream of the rendered React app.
  const stream = await renderToReadableStream(
    <App url={req.url} />,
    {
      // Scripts to bootstrap the React app on the client.
      bootstrapScripts: ['/client.js'],
    }
  );

  // Set headers for streaming HTML.
  res.setHeader('Content-Type', 'text/html; charset=utf-8');
  
  // Pipe the React stream directly into the HTTP response.
  stream.pipe(res);
});

On the client side, you use hydrateRoot to attach interactivity to this streamed HTML.

// In your client-side entry point (e.g., client.js)
import { hydrateRoot } from 'react-dom/client';
import App from './App.js';

// The HTML is already there, streamed from the server.
// Now we "hydrate" it with event listeners and state.
hydrateRoot(document.getElementById('root'), <App />);

What about errors? In a streamed world, an error in one section shouldn’t break the whole page. If the reviews API is down, the user should still see the product details. We combine Suspense with Error Boundaries.

An Error Boundary is a React component that catches JavaScript errors in its child tree. You can wrap your streaming sections with them.

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    // Update state so the next render shows the fallback UI.
    return { hasError: true };
  }

  render() {
    if (this.state.hasError) {
      // You can render any custom fallback UI.
      return this.props.fallback;
    }

    return this.props.children;
  }
}

// Using it in our page.
function ProductPageStreaming() {
  return (
    <div>
      <ProductDetails />
      
      <ErrorBoundary fallback={<p>Could not load reviews right now.</p>}>
        <Suspense fallback={<ReviewsSkeleton />}>
          <ProductReviews />
        </Suspense>
      </ErrorBoundary>
    </div>
  );
}

This is powerful. The Suspense boundary handles the loading state. The ErrorBoundary wraps it and handles any errors that occur during rendering or data fetching inside. The rest of the page remains untouched and interactive.

Let’s get more practical. Think of a complex dashboard. It has a welcome message, key metrics, a chart, a data table, and a notification panel. The user’s name and the key metrics are high priority. The chart and table, which might query a large dataset, are slower. The notification panel is the least critical.

Here’s how you might structure that.

async function DashboardPage({ userId }) {
  // Fetch high-priority user info immediately.
  const user = await fetchUser(userId);
  // Fetch key metrics immediately.
  const metrics = await fetchKeyMetrics();
  
  // Initiate, but don't wait for, slower data fetches.
  const chartDataPromise = fetchChartData();
  const tableDataPromise = fetchTableData();
  const notificationsPromise = fetchNotifications();

  return (
    <main>
      <header>
        <h1>Welcome back, {user.name}</h1>
      </header>
      
      <section className="metrics">
        {/* Render metrics instantly. */}
        <MetricCard value={metrics.sales} label="Sales" />
        <MetricCard value={metrics.users} label="New Users" />
        <MetricCard value={metrics.growth} label="Growth %" />
      </section>
      
      <section className="main-content">
        {/* Chart streams in later. */}
        <ErrorBoundary fallback={<ChartError />}>
          <Suspense fallback={<ChartPlaceholder />}>
            <SalesChart dataPromise={chartDataPromise} />
          </Suspense>
        </ErrorBoundary>
        
        {/* Table streams in later. */}
        <ErrorBoundary fallback={<TableError />}>
          <Suspense fallback={<TablePlaceholder />}>
            <DataTable dataPromise={tableDataPromise} />
          </Suspense>
        </ErrorBoundary>
      </section>
      
      <aside>
        {/* Notifications are low priority, stream last. */}
        <Suspense fallback={<NotificationsPlaceholder />}>
          <NotificationsPanel promise={notificationsPromise} />
        </Suspense>
      </aside>
    </main>
  );
}

For the user, this feels incredibly fast. The header and metrics appear almost instantly. They have meaningful content to look at. Then, a placeholder for the chart appears, which soon gets replaced by the real chart. The table follows. The notifications quietly fill in last. The page feels alive and responsive, not like a single, monolithic block.

You can take this further. You can preload data for sections that are likely to be viewed next. Since you’re working with Promises on the server, you can start fetching data for a component even before the component itself is rendered, if you know the user will need it.

One important note: streaming is about the initial page load. It’s about improving the First Contentful Paint and Largest Contentful Paint metrics. Once the page is loaded and hydrated, subsequent navigations can use client-side data fetching libraries. But that first impression is critical, and streaming makes it much better.

Is there a catch? There are considerations. You need to structure your data fetching logically. Not everything should be wrapped in Suspense. You need to identify the true critical path. Also, search engine crawlers and social media scrapers need to see the full content. The good news is that a well-configured streaming server will eventually send the complete HTML, so crawlers that wait will get the full page. You can also use strategies to pre-render the most important content for crawlers.

Another consideration is the user with a slow connection. With traditional rendering, they see nothing for a long time, then everything. With streaming, they see the core content quickly, and the rest fills in gradually. This progressive enhancement is a better experience for everyone, but it’s a dramatic improvement for those on slower networks.

From my experience, adopting this pattern requires a shift in mindset. You stop thinking about a page as a single unit of data. You start thinking about it as a composition of independent data dependencies, each with its own priority and loading sequence. It makes your application feel more resilient and performant.

The tools are here now. React Server Components provide the foundation. Frameworks like Next.js make it accessible. The result is web applications that are not just faster in measured milliseconds, but feel instantaneous to the people using them. You give them content to engage with immediately, and that changes the entire perception of speed and quality. It’s one of the most impactful changes in how we build for the web today.