We have shipped three production projects with React Server Components in the last six months. The wins are real, the gotchas are real, and the conventional wisdom on the internet is about 60% accurate. Here is what we actually learned.
What genuinely got faster
- Initial page loads: large render trees moved to the server, and bundle sizes dropped 30 to 50% on content-heavy pages.
- Database-driven content: no client roundtrip to fetch and render. The savings are real, but smaller than the marketing claims.
- Forms and mutations: server actions are dramatically simpler than the REST endpoint they replace.
What did not get faster
Interactive parts of the app. RSCs are not magic for interactivity; you still need client components, and the boundary between them takes some thinking. We spent more time deciding what should be server vs client than the framework documentation suggested we would.
The mental model that finally clicked
Server components are template engines. Client components are React. The boundary is where you commit to shipping JavaScript.
Once we stopped thinking of RSCs as a new kind of React and started thinking of them as "the part of the page that gets templated," composition got much clearer.
Patterns we wish we knew
- Top-down server, bottom-up client. Build the page hierarchy from server components down to client islands, not the other way around.
- Pass data, not props, across the boundary. Server → client gets serialized; functions, dates, and Sets do not survive. Convert at the boundary.
- Suspense everywhere. Streaming is the default; data starting late should not block the rest of the page.
- Cache control is now part of the component. Each fetch has a cache strategy; treat it as a first-class concern.
Debugging
The error messages are getting better but are still terrible compared to client-side React. We have learned to read the server logs first, the browser console second. Sometimes it is faster to "comment out half the page and bisect" than to interpret a hydration error.
Would we use them again
Yes, for content-heavy apps with a clear separation between presentation and interaction. Maybe not, for highly interactive apps where almost everything carries client state.