React Server Components in Production: 2026 Lessons

React Server Components are now the default in the two biggest React frameworks. After shipping them across a dozen production apps, the pattern is clear: RSC is a bundle-size and data-locality win, not a general-purpose speed-up — and the failure modes are all at the boundary.

What genuinely improved

• Bundle size. Moving markdown rendering, date libraries, syntax highlighting, and validation schemas to the server routinely cuts 30–60% of client JavaScript. That is real TTI improvement on mid-range mobile.
• Data locality. Fetching next to the component that renders it removes an entire class of prop-drilling and waterfall bugs.
• Secrets. API keys stay on the server by construction, not by convention.
• Streaming. Suspense boundaries around slow sections let the shell paint immediately instead of blocking on the slowest query.

What got harder

• The mental model split. Every developer on the team must know which side each file runs on. Ambiguous files are where bugs live.
• Caching. Multi-layer caches — request memoisation, data cache, full route cache, client router cache — mean "why is this stale?" is now a four-layer investigation.
• Third-party libraries. Anything touching window, localStorage, or context at import time breaks server rendering. The error messages point at the wrong file surprisingly often.
• Debugging. Server component errors surface as serialisation failures, not stack traces at the real cause.

The five boundary rules

1. Push the client boundary down. Make the interactive leaf a client component, not the page. A "use client" at the top of a page pulls its entire subtree into the bundle.
2. Pass serialisable props only. Dates, class instances, and functions do not cross. Serialise deliberately at the boundary.
3. Never import a server-only module from a shared file. Shared utilities are the most common leak path — one import chain drags database code into the browser bundle.
4. Children as props. A client component can render server-rendered children passed as props, which keeps heavy content out of the bundle even inside an interactive wrapper.
5. Read browser state in effects. A typeof window check in a state initialiser still produces a hydration mismatch.

Where RSC is the wrong tool

Highly interactive surfaces — editors, canvases, dashboards with live filtering — are almost entirely client components. Forcing RSC there adds boundary complexity for no payoff. Use it for content-heavy and data-fetch-heavy routes; use plain client components where interaction dominates.

Measuring the win

Track client bundle bytes per route and Interaction to Next Paint, not Lighthouse scores. On the marketing and content routes of a recent build, moving to server components took first-load JS from 312KB to 118KB and INP from 240ms to 90ms. On the app's editor route, the same migration changed nothing and cost a week.