React Server Components and Client Bundle Size

This guide belongs to Hydration & Partial Rehydration Strategies in JavaScript Bundle Optimization & Code Splitting. React Server Components (RSC), the default in the Next.js App Router and supported by other frameworks, render on the server and send the browser a serialised description of their output — not their code. A server component that formats dates with a heavy library, renders markdown with a parser, or queries a database ships none of that code to the client. Only components marked with "use client" (and everything they import) become client JavaScript and hydrate.

That makes RSC one of the most effective bundle-reduction tools available to React applications — when the client boundary is placed well. Placed badly, a single "use client" near the top of the tree turns most of the page back into client code, and the app ships as much JavaScript as before, plus the RSC payload.

Rapid Diagnosis

• Read the build output. next build lists "First Load JS" per route; compare routes with similar UI.
• Search for "use client". Each occurrence is a boundary; boundaries in layouts, providers or large page components are suspects.
• Analyse the client bundle with @next/bundle-analyzer and look for libraries that only render static output (markdown, syntax highlighting, date formatting, icons).
• Check the RSC payload size. In the Network panel, RSC responses (?_rsc= requests or the inline flight data) can be large for data-heavy pages.

Root Cause Analysis

1. High client boundaries. Marking a layout or page as a client component to use one hook (useState for a menu, usePathname for active links) converts its entire subtree's imports into client code.

2. Context providers at the root. Providers must be client components; wrapping the whole app in a client provider is fine as long as children are passed as props (server components can be children of client components) — but importing server-only content into a provider file makes it client code.

3. Shared utility modules. A utility imported by both server and client components ships to the client with all its dependencies, even if the client uses one function.

4. Large serialised props. Passing big data objects from server to client components inflates the RSC payload and the hydration work for those components.

Step-by-Step Resolution

1. Push "use client" down to interactive leaves

// app/blog/[slug]/page.jsx — a server component (no directive).
import { renderMarkdown } from '@/lib/markdown';      // heavy parser stays on the server
import { LikeButton } from './LikeButton';            // small client component
export default async function Post({ params }) {
  const post = await getPost(params.slug);
  return (<article>
    <h1>{post.title}</h1>
    <div dangerouslySetInnerHTML={{ __html: await renderMarkdown(post.body) }} />
    <LikeButton postId={post.id} />
  </article>);
}
// LikeButton.jsx starts with "use client" and contains only the button logic.
// trade-off: splitting interactivity into leaf components adds files and props
// plumbing. Worth it for content-heavy pages; less so for highly interactive
// dashboards where most of the tree is genuinely client-side.

Expected outcome: the markdown library and the article rendering code disappear from the client bundle.

2. Pass server components as children of client providers

// app/layout.jsx (server component)
import { ThemeProvider } from './ThemeProvider';    // "use client" inside
export default function RootLayout({ children }) {
  return <html><body><ThemeProvider>{children}</ThemeProvider></body></html>;
}
// trade-off: anything the provider file itself imports becomes client code.
// Keep provider files small and import nothing but the context they provide.

Expected outcome: the provider is client-side; the pages inside it remain server components.

3. Split shared utilities by environment

Separate server-only utilities (import 'server-only') from client-safe ones so imports cannot leak heavy server code into client bundles, and so accidental imports fail the build.

4. Trim props crossing the boundary

Pass client components only the fields they render. Large objects serialised into the RSC payload cost bytes and parse time even though no component code ships.

Verification

Compare next build First Load JS per route before and after, and confirm in the bundle analyser that heavy libraries no longer appear in client chunks. In a throttled trace, hydration should be limited to small client components, and TBT should fall. Check the RSC payload size has not ballooned in exchange — if it has, trim props.

Worked Example: A Documentation Site Migration

A documentation site migrated from the Pages Router to the App Router but initially put "use client" in its docs layout to keep a sidebar's expand/collapse state. First Load JS stayed at 205KB per page, because the layout imported the MDX renderer, syntax highlighter and search index client-side. Moving the sidebar state into a small SidebarToggle client component and keeping the layout as a server component dropped First Load JS to 88KB; lab TBT on docs pages fell from 380ms to 120ms, and field INP p75 improved from 230ms to 150ms.

Common Mistakes

• Marking a page client-side to use one hook. Extract the hook's UI into a leaf component instead.
• Importing server utilities into client components. Use the server-only package to fail fast.
• Fetching on the client what could be fetched on the server. Client data fetching brings fetch libraries and loading states into the bundle.
• Ignoring the RSC payload. It is not free; very large payloads delay hydration and use bandwidth.

Edge Cases

Third-party components without directives. Libraries that use hooks but lack "use client" must be wrapped in your own client component before use in server components.

Context-heavy libraries. UI libraries that rely on React context throughout may force large client boundaries; prefer libraries that work with server components or isolate them to interactive regions.

Streaming and Suspense. Server components can stream with Suspense, improving TTFB and LCP; client components inside streamed regions hydrate when their code and data arrive.

Caching. Server components shift work to the server; without caching, TTFB can rise. Cache data and use static rendering where possible.

FAQ

Related

• Fixing long hydration tasks in Next.js App Router — hydration cost after boundaries are placed.
• Reducing Next.js first load JavaScript — other levers for the same metric.
• Islands vs full hydration for content sites — a related architecture outside React.