React Server Components change where your code runs and how much JavaScript ships to the browser. Here's what actually changes for a real project — and when it's worth adopting.
For most of React's history, every component you wrote ran in the browser. React Server Components (RSCs) change that assumption for the first time since React shipped in 2013 — and the change is bigger than a new API. It's a shift in where your application's logic actually executes, which affects bundle size, data fetching, and how you structure a codebase from day one.
As a React development company building production applications on Next.js's App Router, we've migrated existing projects to Server Components and started new ones with them from scratch. Here's the practical version of what changes.
What a Server Component Actually Is
A Server Component renders entirely on the server — it never ships its code to the browser, and it never re-renders on the client. It can read from a database, call an internal API, or read a file directly, all without an API route in between. The HTML it produces streams to the browser already built.
A Client Component is what React looked like before: it renders on the server for the initial HTML, then "hydrates" in the browser so it can respond to clicks, hold state, and re-render. You opt into this explicitly with a "use client" directive at the top of the file. (Terms like hydration and server-side rendering are also broken down in our glossary if you want a quick refresher.)
The default in the App Router is now Server. You add Client Components only where you need interactivity — a form, a dropdown, anything with useState or an event handler.
Why This Matters for Bundle Size
Every Client Component's code — and everything it imports — ships to the browser as JavaScript. A Server Component's code never does. In practice, this means a data-heavy dashboard page that used to ship its formatting logic, date libraries, and markdown renderer to the client can now keep all of that server-side, sending only the interactive controls as client JavaScript.
For a content-heavy page — a dashboard, a marketing site, a blog — this commonly cuts client-side JavaScript substantially, which shows up directly in Core Web Vitals: faster Time to Interactive, lower Total Blocking Time, and a real improvement in mobile performance on slower devices.
Data Fetching Gets Simpler, Not Harder
Before Server Components, fetching data in a Next.js page typically meant either getServerSideProps, a client-side useEffect with a loading state, or a dedicated API route your frontend called. Server Components let a component await data directly in its function body — no API route required for data that's only ever consumed by that page.
This removes an entire class of "waterfall" bugs, where a client component fetches data, then renders a child that fetches more data, adding round-trips and loading spinners at every level. Server Components can fetch in parallel and stream results as they resolve.
Where It Gets Genuinely Harder
The trade-off is real, and any honest guide has to say so. Server and Client Components can't freely mix — you can't pass a function or a class instance as a prop from a Server Component into a Client Component, because that boundary is a serialization boundary, not just a naming convention. Passing event handlers down, using context providers, and working with third-party libraries that assume a full client-rendered tree all require deliberate placement of the "use client" boundary.
Debugging also changes. Server Component code runs in a Node environment during rendering, so browser devtools won't show you what's happening inside one — you're back to server logs for that layer, and a mental model shift for a team used to inspecting everything in the browser.
When We Recommend Adopting Server Components
- Content-heavy sites and dashboards — marketing pages, blogs, admin panels with lots of read-only data benefit the most from moving rendering off the client.
- New projects on Next.js 13+ — starting with the App Router's Server-first default is far easier than retrofitting an existing Pages Router app.
- Teams comfortable with a server-first mental model — if your team is used to thinking in terms of "what runs where," the migration is straightforward. If everyone on the team has only ever worked client-side, budget time for the adjustment.
We'd hold off on a full migration for highly interactive, real-time applications — dashboards with live collaborative editing, canvas-based tools, or apps that are essentially one continuous client-side session. Those still lean heavily on Client Components, and the Server Component benefit is smaller relative to the migration effort.
The Practical Takeaway
React Server Components aren't a trend to chase for its own sake — they're a genuine architectural option that reduces the JavaScript your users download, simplifies data fetching, and rewards teams willing to think about a component tree as spanning two environments instead of one. For a new Next.js project, starting with Server Components as the default is close to a free performance win. For an existing app, it's worth evaluating page by page rather than attempting a big-bang rewrite.
