React Server Components: Six Months in Production

React Server Components promised to change how we think about the server/client boundary in React applications. After six months running RSC in production on a mid-size application, the reality is more nuanced than either the enthusiasts or the skeptics suggested.

Where RSC Genuinely Delivers

Data-heavy components that previously required client-side data fetching are the clearest win. Moving the data fetch to the server eliminates the loading state, reduces JavaScript bundle size, and improves LCP. For pages where the initial content is the most important thing users see, the user experience improvement is real and measurable.

The Mental Model Shift Is Real

The server/client component distinction requires building a new mental model, and the boundary between the two is easy to violate in ways that produce confusing errors. The most common mistake: trying to use client-only APIs (window, localStorage, hooks) in server components. The error messages have improved, but the learning curve is genuine.

Caching Complexity

RSC’s caching model is powerful and complex. Understanding which fetches are cached, for how long, and how cache invalidation works requires careful reading of the documentation and empirical testing. We had two caching-related production bugs in the first two months that would not have existed with a simpler client-side data fetching approach.