React Server Components One Year Later: Our Honest Assessment

We have shipped six production projects using React Server Components via Next.js App Router. We started as enthusiastic adopters and settled into pragmatic users. Here is our honest assessment.

The genuine wins are real. Bundle size dropped 38% on a content-heavy marketing site we migrated from Pages Router. Components that only render on the server contribute zero bytes to the client bundle. Data fetching with async/await in server components is about 60% less code than the equivalent client component with useEffect, useState, and error handling. For pages displaying data without complex interactivity, this is a clear improvement in both developer experience and user performance.

The friction is also real. The mental model tax is persistent. After a full year, our team still occasionally gets tripped up by the client/server boundary. You cannot pass a function as a prop from a server component to a client component. You cannot use hooks in server components. Context providers must be client components, meaning any tree needing context is client-rendered.

The "use client" directive proliferates faster than expected. In theory, most components should be server components with "use client" marking interactive leaves. In practice, interactivity is pervasive. Every dropdown, modal, form, sorted list, and paginated table needs "use client." On our SaaS dashboard projects, 60-70% of components end up as client components. RSC works beautifully for data fetching and layout, but the interactive leaves are most of the application.

Performance is not automatically better across the board. LCP improved 15-20% on content-heavy pages, aligning with smaller bundles. But INP was comparable or slightly worse on interaction-heavy pages, because server rendering adds latency that a purely client-side re-render avoids.

Caching remains the weakest part of the system. Next.js has changed its caching behavior multiple times. Understanding when a server component re-renders, when data is cached, and how to invalidate that cache requires careful empirical testing. We have spent more debugging hours on caching than any other RSC concern.

Our current approach: App Router for all new projects, deliberate about boundaries. Data fetching and layout are server components. Everything interactive is a client component. Do not force server patterns where client components are simpler. For existing Pages Router projects, do not migrate unless RSC solves a specific problem. The effort is substantial and the gains are incremental.