React Server Components in production: nine months of learnings

React Server Components are genuinely good. After nine months in production across three projects, I'll say that clearly — they solve real problems and the performance benefits are measurable. But the mental model shift is significant.

The boundary problem

The most consequential decision in an RSC application is where you draw the client boundary. The rule we've converged on: the client boundary should be as low in the component tree as possible, and should contain only what genuinely needs to be interactive.

Streaming and Suspense

Being able to send the shell of a page immediately, stream in content as it becomes available, and show meaningful loading states without JavaScript — the user experience improvement is real. First Contentful Paint dropped 30–40% on the projects where we've measured carefully.

The data fetching model

Data fetching happens in server components colocated with the components that use the data. No prop drilling, no context gymnastics, no loading states for data the server already has.

What genuinely doesn't work yet

Real-time features. If you need WebSocket connections or live updates, you're in client component territory, and the seam between your RSC application and the real-time layer requires careful thought. The patterns here are still maturing.