React Server Components (RSC) are no longer experimental. They're shipping in production Next.js applications worldwide, and the mental model shift they require is significant. After delivering several large-scale RSC applications, here are the things that catch teams off-guard.
The Server/Client Boundary Is a Design Decision, Not an Afterthought
The biggest architectural mistake we see is treating the server/client split as something to figure out later. It isn't. Once you start building, the boundary propagates through your component tree in ways that are hard to refactor. Before writing a single component, map out which parts of your UI need interactivity, which need access to server-side data, and which are purely presentational. That map becomes your boundary plan.
Third-Party Libraries Often Don't Work Out of the Box
A significant portion of the React ecosystem was built assuming a browser environment. Components that rely on window, document, or browser APIs will break in Server Components. Before committing to RSC on a project, audit your key dependencies. The answer is often a dynamic import with ssr: false, but it's better to know this before you're in the middle of a sprint.
Streaming Is Powerful But Requires Careful Loading State Design
Suspense and streaming let you progressively load the page — fast shell first, data-heavy sections as they resolve. This is genuinely excellent for perceived performance. But it requires deliberate loading state design. Every Suspense boundary needs a fallback that matches the dimensions of the content it's replacing, or you get layout shift that hurts both UX and Core Web Vitals.
Caching Behaviour Will Surprise You
Next.js wraps fetch with aggressive caching by default in the App Router. This is great for performance and terrible for debugging when you can't understand why you're seeing stale data. Understand the four caching layers — request memoisation, Data Cache, Full Route Cache, and Router Cache — before you go to production. Knowing when to use cache: 'no-store' and revalidate will save you hours of confusion.
The Payoff Is Real
Despite the learning curve, RSC delivers. Reduced client-side JavaScript bundles, co-located data fetching, and elimination of client-side waterfalls produce measurably better performance. Our last RSC migration saw a 40% reduction in JS bundle size and a 1.2-second improvement in Largest Contentful Paint. The complexity is front-loaded — once your mental model clicks, the development experience is excellent.
