React Server Components in Production: One Year In

About a year ago we shipped our first production app using React Server Components as the default rendering model. Since then we have built six more on the same stack, watched a few teams retrofit RSC into existing Next.js apps, and helped one client decide it was the wrong fit and stay on a client-rendered architecture. This is the post we wish we had read 12 months ago.

The short version: the wins are real, the pain is real, and the answer to "should we use RSC?" is no longer reflexively yes for every project. Here is the honest accounting.

1. What React Server Components Actually Are, in Plain Terms

Strip away the marketing and React Server Components do three things. First, your components run on the server by default. The browser receives the rendered output, not the component code. Second, because they run on the server, they can read from a database, hit an internal service, or open a file directly without going through a REST or GraphQL endpoint. Third, only the components you explicitly mark with "use client" get shipped to the browser as interactive JavaScript.

The practical effect is that a typical page is a tree of server components with small islands of client components for the bits that need to be interactive. A product page might be entirely server-rendered, with a single client component for the "Add to cart" button and the quantity selector.

This is closer to how PHP or Rails apps worked in 2010 than to how a typical React SPA worked in 2022. That comparison sounds dismissive but it is not. The model has clear advantages. The challenge is that an entire generation of React developers has muscle memory for the SPA model, and unlearning it takes real time.

2. The Wins Are Real and Measurable

The first thing you notice is bundle size. On the content sites we have moved from a Next.js Pages Router setup to App Router with RSC, JavaScript shipped to the browser dropped between 30 and 60 percent. For a marketing site we rebuilt last summer, the initial JS payload went from 312 KB to 118 KB. Lighthouse performance scores on mid-tier mobile devices went from 71 to 94.

The second win is time to first byte. Because the server can stream HTML as soon as the first part of the tree is ready, users see content faster. On a content-heavy dashboard we shipped in October, TTFB dropped from 680 ms to 240 ms after moving the bulk of the rendering to the server.

The third win, and the one that surprised us most, is how much code disappears. On the SPA version of one app, we had a Next.js API route, a React Query hook, a loading state, an error state, and the component that consumed all of it. On the RSC version we have an async server component that awaits the database query directly. Four files collapse into one. For read-heavy views this is a real productivity gain once the team is past the learning curve.

The fourth win is data fetching co-location. The data fetch lives in the component that renders the data. No more chasing through three files to figure out where a piece of state comes from. This sounds small. It compounds across hundreds of components.

3. The Pain Points That Marketing Glosses Over

The mental model is harder than the marketing suggests. The boundary between server and client components is not always intuitive. A common trap is importing a server component into a client component, which fails in confusing ways. Another is passing non-serializable data (functions, class instances, dates in some cases) across the boundary, which also fails in confusing ways.

The "use client" directive feels simple until your component tree gets deep. You add "use client" to a leaf component because it needs an onClick handler. Now everything below it is also a client component. You restructure to push the client boundary further down the tree. You do this 40 times across an app and the architectural overhead is real.

Error messages have improved significantly over the year but are still rough. Hydration mismatches in particular are painful. The browser HTML does not match the server HTML, the error tells you almost nothing actionable, and you spend an afternoon binary-searching through the tree to find which component drifted. We have lost real days to this.

Third-party libraries are the other recurring tax. Many React libraries written before RSC assume they will run in the browser, use browser APIs at module load time, or rely on context providers in ways that do not work in server components. The ecosystem has caught up significantly in the last six months but you will still find a charting library or a date picker that needs a "use client" wrapper and some delicate dynamic imports to avoid breaking the server build.

For teams coming from a pure SPA background the first month is humbling. Senior engineers feel junior again. Plan for it, communicate it, and do not start the migration during a crunch quarter.

4. When RSC Is the Right Call

RSC is the right default for anything that looks like a content site, a marketing site, a documentation site, a blog, an e-commerce storefront, or a dashboard that is mostly displaying data. Anything you would have built with traditional server-side rendering 10 years ago is a strong candidate.

It is also a good fit for the read-heavy sections of larger apps. A SaaS product might have a customer-facing portal that is mostly read views (account history, invoices, reports) and an internal admin tool that is mostly write views (forms, drag and drop, complex state). The customer-facing portal benefits from RSC. The admin tool may not.

If your project is one where SEO matters, where mobile performance matters, where conversion rate is tied to load time, RSC pays for itself within months. The same firm that saw their Lighthouse score climb 23 points also saw their organic search traffic increase 18 percent in the following quarter. Correlation is not causation, but the timing is hard to ignore.

Most of our new web development projects in 2026 default to RSC unless we have a specific reason not to. The performance ceiling is higher and the developer experience, once your team is up the curve, is genuinely good.

5. When to Skip RSC and Stay on a Client-Rendered Stack

RSC is a bad fit for highly interactive single-page apps. Think collaborative editors, design tools, real-time dashboards with constant client-side state. Anything where the bulk of the experience is users manipulating state in the browser. The benefits of RSC are smaller because you end up with most of the app behind "use client" anyway, and you pay the architectural complexity for little gain.

It is also a poor fit for internal admin tools and back-office apps. The user is logged in, performance is acceptable on a desktop with good network, SEO is irrelevant, and the team values shipping features fast. A traditional client-rendered React app or even a tool like Retool will get you there with less ceremony.

Prototypes are another skip. The two to four week learning curve is dead weight on a project meant to validate an idea in two weeks. Build the prototype on whatever stack you know best. Migrate later if the idea becomes a product.

Finally, if your team has zero existing React experience and you are choosing a stack from scratch, consider whether RSC is adding more complexity than value for the project at hand. The model rewards teams that already understand React deeply. It punishes teams who are still learning the basics.

6. Migration Reality Check for Existing Apps

The conversation we keep having with clients is whether to migrate an existing Next.js Pages Router app to App Router and RSC. The honest answer is "it depends, and probably not all at once."

The migration is not a weekend. For an app of meaningful size (50 plus pages, 200 plus components) plan for a month of focused work plus a long tail of fixing edge cases. The Pages Router and App Router can coexist in the same Next.js app, which lets you migrate incrementally. Start with the highest-traffic public pages where performance gains pay off most. Leave the deep authenticated sections for later or never.

Be honest about the business case. If your existing app is performing fine, your team is shipping features at a healthy pace, and your users are not complaining, the migration is a cost without a clear return. The strongest migration cases we have seen are sites where Core Web Vitals are hurting search rankings or where bundle bloat has become a real problem on mobile.

7. The Honest Recommendation a Year In

For new content-heavy projects in 2026, default to RSC. The performance wins are large enough and the ecosystem is mature enough that the tradeoff is worth it. Budget the team learning curve into the project plan, expect the first three weeks to feel slower than your old stack, and trust that productivity recovers.

For new highly interactive apps, internal tools, or prototypes, stay on a client-rendered React stack or pick a different framework entirely. Do not feel pressure to use RSC because it is the new shiny. The framework should fit the project, not the other way around.

For existing apps, migrate selectively if at all. Start with the public-facing pages where performance and SEO matter, leave the rest, and be ruthless about whether the work earns its cost.

A year in, our take is that React Server Components are a meaningful step forward for one large category of apps and a poor fit for another. The discipline is figuring out which category you are in before you start writing code. Most of the regret stories we hear come from teams that picked RSC because it was new, not because it solved a problem they actually had.