A Fundamental Shift in React's Model
Since its creation, React has been a client-side library. Components render in the browser, JavaScript bundles ship to users, and data fetching happens through API calls from the client. This model works, but it comes with trade-offs: large bundle sizes, waterfall data fetching, and the need for a separate API layer between your frontend and your data.
React Server Components (RSC) change this equation fundamentally. With RSC, React components can render on the server and stream their output to the client as a serialized format. These server components never ship any JavaScript to the browser. They execute entirely on the server, with direct access to databases, file systems, and backend services.
At StrikingWeb, we have been building with React Server Components through Next.js 13's App Router since its release, and the impact on both developer experience and end-user performance has been substantial. This article explains the technical changes, practical implications, and adoption considerations.
Server Components vs Client Components
In the RSC model, every component is a Server Component by default. Server Components execute on the server during the request and produce HTML and a serialized representation that the client can use to reconcile the component tree. They have several distinctive characteristics.
Server Components can directly access backend resources. You can query a database, read from the file system, or call internal APIs directly within the component function. There is no need for a separate API route or data fetching library. The component simply awaits the data it needs.
Server Components produce zero JavaScript bundle impact. Because they never run on the client, their code, their dependencies, and the data they process are not included in the browser bundle. A Server Component that imports a heavy markdown parsing library adds nothing to what the user downloads.
Server Components cannot use browser APIs or React state. They have no access to useState, useEffect, event handlers, or any browser-specific functionality. They are purely for rendering output based on server-side data.
Client Components, marked with the "use client" directive at the top of the file, work the traditional way. They ship JavaScript to the browser, can use hooks and event handlers, and handle interactive UI elements. The key insight is that most of a typical web application is actually non-interactive content that benefits from being a Server Component.
The Data Fetching Revolution
The way RSC handles data is perhaps its most impactful change. In the traditional React model, data fetching follows a predictable but suboptimal pattern. The page loads, components mount, useEffect triggers data fetching, loading states render while waiting, and finally the data arrives and the UI updates. When nested components each need their own data, this creates a waterfall of sequential requests.
With Server Components, data fetching happens during rendering on the server. Each component independently fetches the data it needs, and React handles deduplication and parallel execution. The server has direct access to the database or backend services with minimal latency, and the component renders with its data before anything reaches the client.
This eliminates several problems simultaneously. There are no loading waterfalls because the server resolves all data before streaming the response. There is no client-server API layer to build and maintain for data that only the UI needs. There is no risk of exposing sensitive data or credentials in client-side code because the fetching logic never reaches the browser.
For a typical content-heavy page like a blog post, product page, or dashboard, this means the user sees complete content almost immediately, without the flash of loading spinners that characterizes many single-page applications.
Bundle Size Impact
Bundle size reduction is one of the most measurable benefits of RSC. Consider a product detail page on an e-commerce site. It might use a markdown renderer for product descriptions, a date formatting library for reviews, a price calculation utility, an image optimization component, and various data transformation functions. In a traditional client-rendered React application, all of these dependencies ship to the browser.
With Server Components, only the interactive parts of the page contribute to the bundle. The add-to-cart button, the quantity selector, the image gallery with swipe gestures, and the review submission form are Client Components that include their JavaScript. Everything else, the product description, specifications table, review listings, related products grid, and breadcrumb navigation, render as Server Components with zero JavaScript cost.
In our projects, we have seen JavaScript bundle reductions of 40 to 60 percent after converting appropriate components to Server Components. For users on mobile devices or slow networks, this translates directly to faster load times and better interactivity metrics.
The Composition Pattern
One of the most elegant aspects of RSC is how Server Components and Client Components compose together. A Server Component can render a Client Component as a child, passing server-fetched data as props. A Client Component can render Server Components passed to it as children through the children prop.
This creates a natural architectural pattern. The outer page structure, layout, and data fetching happen in Server Components. Interactive islands within that structure are Client Components. The Server Component fetches the data and passes it down; the Client Component handles the user interaction.
For example, a dashboard page might be a Server Component that queries the database for the user's metrics. It renders a static header, navigation, and data summary as server-rendered HTML. Within the layout, it renders a Chart Client Component (which needs JavaScript for interactivity) and passes the pre-fetched data as props. The chart renders instantly with data already available, no loading spinner required.
Streaming and Suspense
RSC works hand-in-hand with React Suspense and streaming to provide a progressive rendering experience. When a Server Component needs to wait for slow data, it can be wrapped in a Suspense boundary with a fallback. React streams the rest of the page immediately and replaces the fallback with the actual content once the data arrives.
This means the user sees a meaningful page almost immediately, with slower sections filling in progressively. Unlike traditional loading patterns where the entire page waits for all data, streaming allows the fast parts of the page to render while the slow parts load independently.
In practice, this is transformative for pages that aggregate data from multiple sources with varying response times. A dashboard that combines real-time data, cached analytics, and third-party API responses can stream each section independently, showing the fastest data first.
Next.js App Router: RSC in Practice
While React Server Components are a React feature, Next.js is currently the primary framework for using them in production. The Next.js App Router, introduced in version 13, is built entirely around the RSC model.
In the App Router, every component in the app directory is a Server Component by default. Routes are defined by directory structure, with page files for route content and layout files for shared structure. Loading states, error boundaries, and not-found pages have dedicated file conventions.
The App Router also introduces Server Actions, a way to handle form submissions and data mutations from Server Components without building API routes. A Server Action is an async function defined with the "use server" directive that can be called directly from a form or Client Component. The function executes on the server, and the page revalidates automatically to reflect any changes.
When to Adopt RSC
React Server Components are particularly beneficial for content-heavy applications, where large portions of the UI display data without user interaction. E-commerce product pages, blog platforms, documentation sites, dashboards, and admin panels are all excellent candidates.
Applications that are primarily interactive, such as collaborative editors, drawing tools, or real-time communication apps, will see less benefit because most of their components need client-side JavaScript regardless.
The migration path for existing React applications is gradual. You do not need to rewrite everything at once. Start by identifying the most content-heavy, least interactive parts of your application and converting those to Server Components. Over time, push interactivity to the edges and let Server Components handle the data-heavy core.
React Server Components represent a genuine paradigm shift in how we build web applications with React. They resolve long-standing tension between developer experience and performance, and they point toward a future where the server-client boundary is an implementation detail rather than an architectural constraint. For teams building data-driven web applications, adopting RSC is no longer experimental; it is becoming the standard approach.