React Server Components Don't Make Your App Fast by Default

A Next.js app migrated from Pages Router to App Router. RSC throughout, use client pushed to the leaves. Lighthouse score went up. LCP in production got worse by 800ms.

The component tree was fetching data. Each server component called its own database query. They ran sequentially — one couldn't start until its parent finished. What was previously one getServerSideProps call became eight round trips before the page could render.

RSC reduces client JavaScript. That part works exactly as advertised. What it doesn't do is make data fetching faster, or eliminate the server-side work that now determines when your HTML actually arrives.

What RSC actually changes

Server components stay on the server. Their code never ships to the browser, they don't get hydrated, and anything they import doesn't touch the client bundle. For components that are genuinely static — content that renders from data and never responds to user interaction — this is a real win. The JavaScript savings from the previous article compound here: pushing use client to the leaves is how you maximize the RSC benefit.

Bundle size reduction is real. But LCP is determined by when the HTML arrives, not by how much JavaScript the client downloads afterward. If server components are slow, TTFB is slow, and LCP is slow — regardless of how small the client bundle is.

The waterfall that App Router makes easy to create

Pages Router's data fetching model had a structural advantage it rarely got credit for: getServerSideProps ran once, in one place, before the page rendered. Everything the page needed came from one function.

With RSC, each component can fetch its own data. This sounds cleaner — components are self-contained, colocated with their data requirements. The problem is that React renders the component tree top to bottom, and a child component's data fetch can't start until its parent has rendered and the child has mounted on the server.

// ParentComponent fetches its data first

async function ParentComponent() {

  const parent = await db.query('SELECT * FROM parent WHERE id = ?', [id]);

  return <ChildComponent parentId={parent.id} />;

}



// ChildComponent can't start until ParentComponent finishes

async function ChildComponent({ parentId }) {

  const children = await db.query('SELECT * FROM children WHERE parent_id = ?', [parentId]);

  return <>{/* render */}</>;

}

Two queries, sequential. If each takes 40ms, that's 80ms added to TTFB before the waterfall. Nest three or four levels of components that each need data, and you're looking at 200–400ms of sequential database round trips added to every page render.

This is the App Router waterfall. It's easy to create, easy to miss in development where database latency is near zero, and immediately visible in production.

Fetching in parallel

The fix is to hoist data fetching to the component that needs all the data, or to run independent queries in parallel:

async function ProductPage({ productId }: { productId: string }) {

  // These run in parallel — Promise.all starts both immediately

  const [product, reviews, inventory] = await Promise.all([

    db.products.findById(productId),

    db.reviews.findByProduct(productId),

    db.inventory.getStock(productId),

  ]);



  return (

    <>

      <ProductHeader product={product} />

      <InventoryStatus inventory={inventory} />

      <ReviewList reviews={reviews} />

    </>

  );

}

Three queries, one round trip's worth of latency. The child components receive data as props and render without fetching anything themselves.

This trades component colocation for speed. Sometimes that's the right tradeoff. For a page where TTFB matters — which is most pages — it usually is.

For queries that genuinely can't be parallelized because they depend on each other's results, React.cache at least prevents duplicate fetches across a single render when multiple components request the same data:

import { cache } from 'react';



const getUser = cache(async (userId: string) => {

  return db.users.findById(userId);

});



// Both components call getUser — only one database query executes

async function Header({ userId }) {

  const user = await getUser(userId);

  return <nav>{user.name}</nav>;

}



async function Sidebar({ userId }) {

  const user = await getUser(userId);

  return <aside>{user.role}</aside>;

}

cache deduplicates within a single request. It doesn't cache across requests — that's what unstable_cache or a proper caching layer handles.

TTFB is the new LCP bottleneck

With Pages Router, slow getServerSideProps was obviously the bottleneck because it was the one place data fetching happened. With App Router, the bottleneck is distributed across the component tree and harder to trace.

The signal to look for: LCP correlates with server response time in your field data, not with client-side metrics. If p75 LCP improves when you filter to users with fast connections, that's a client-side problem. If it's high regardless of connection speed, the server is slow.

Measuring TTFB separately from LCP in your RUM data makes this visible. If TTFB is 600ms and LCP is 650ms, the client is fine — the server is the problem.

new PerformanceObserver((list) => {

  for (const entry of list.getEntries()) {

    if (entry.entryType === 'navigation') {

      sendMetric({

        ttfb: entry.responseStart - entry.requestStart,

        page: location.pathname,

      });

    }

  }

}).observe({ type: 'navigation', buffered: true });

Tracking TTFB per page in production shows which routes have server-side performance problems. A product listing page with high TTFB is a data fetching problem. A marketing page with high TTFB is a different problem — probably server cold starts or lack of caching.

Where RSC genuinely helps

RSC is the right model for components that render server-side data without needing client interactivity. Static product descriptions, server-rendered markdown, navigation built from a CMS — these belong on the server. Moving them there reduces the client bundle and eliminates hydration cost, and that's a real performance improvement.

What RSC doesn't do is make database queries faster, fix slow APIs, or reduce TTFB if your data fetching is sequential. The performance benefit of RSC is realized at the component boundary — it removes cost on the client. Everything upstream of that boundary is still your problem.

The next article in this series covers streaming SSR — the actual mechanism that lets Next.js send HTML before all the server-side data is ready, and where it genuinely helps LCP versus where it creates new problems to manage.