React Server Components — when to use them and how they change architecture • Meteora Web Agency

If your React app fetches data from APIs and you feel the JavaScript bundle is too heavy, React Server Components are what you need. They are not an alternative to Next.js — they are a paradigm shift that separates what runs on the server from what runs on the client. At Meteora Web, we have used them in real projects, and we'll show you exactly when they make sense and how they change your code structure.

What Are React Server Components and Why Do They Change Architecture?

React Server Components (RSC) are components that run exclusively on the server, never sent to the client. They can directly access databases, file systems, and internal APIs. Their output is a serialized stream of React elements. The client receives only HTML and a small piece of JavaScript for reactivity. The architectural shift is radical: instead of fetching in useEffect, you fetch directly in the component body.

// ProductList.server.jsx — Server Component
import db from '@/lib/db';

export default async function ProductList() {
  const products = await db.query('SELECT * FROM products LIMIT 10');
  return (
    
      {products.map(p => {p.name} — €{p.price})}
    
  );
}

Notice the use of async directly in the component. No useEffect, no client-side fetch. The resulting bundle is nearly zero. At Meteora Web, we've seen projects where migrating to RSC cut initial JavaScript by 60%, directly impacting LCP and FID.

When to Use a Server Component Instead of a Client Component?

The rule of thumb is simple: if the component doesn't need interactivity (clicks, state, effects) and can be rendered with static or server-side data, use a Server Component. Concrete examples: layouts, headers, footers, product lists (if not filtered client-side), CMS content, static pages. Components with forms, inputs, carts, animations must remain Client Components. The main discriminator is the use of hooks like useState, useEffect, useReducer. If you use any of these, it cannot be an RSC.

Operational tip: start with all Server Components by default and move to Client only when interactivity is needed. This mental inversion is the key to a performant architecture. We applied this on a clothing e-commerce: the catalog became a pure Server Component, while the cart (with add/remove) remained a Client Component. Result? The product page bundle dropped from 1.8 MB to 450 KB.

How to Set Up a React Project with Server Components?

The easiest way is to use Next.js with the App Router, which enables RSC out of the box. If you prefer Vite or a custom setup, you need to add the react-server-dom-webpack plugin. Here are the steps:

npm install react-server-dom-webpack

Then in vite.config.js:

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import { serverComponentsPlugin } from 'react-server-dom-webpack/plugin';

export default defineConfig({
  plugins: [
    react(),
    serverComponentsPlugin()
  ]
});

For new projects, we recommend Next.js. With create-next-app you get an RSC-ready architecture immediately. Note: not all npm packages are compatible with RSC — check that they don't use client-side APIs (e.g., window, localStorage).

What Is the Impact on Performance and SEO?

Performance: The reduction in JavaScript bundle size is the most obvious benefit. Data is serialized as JSON and included in the initial HTML. No fetch waterfalls. First load becomes almost instant. We measured on a client dashboard: 50 components, 45 converted to RSC. The bundle went from 2.3 MB to 480 KB. Time to Interactive from 7s to 1.8s.

SEO: Content is already in the HTML, so Google sees it directly. Perfect for e-commerce and blogs, where search engines need to index descriptions and prices. With old client-side rendering, crawlers often saw an empty page. With RSC, that problem disappears.

A concrete example: a client selling gym equipment had a Next.js site without RSC (Pages Router). After migrating to the App Router with Server Components, organic traffic grew by 35% in three months thanks to better indexing of product pages.

How to Manage State and Interactions with Server Components?

Server Components cannot have state, but they can be nested with Client Components. The typical pattern is: a Server Component fetches data and passes it as props to a Client Component that handles interactivity. Here's an example:

// ProductPage.server.jsx
import ProductList from './ProductList.server';
import AddToCart from './AddToCart.client';

export default async function ProductPage() {
  const products = await getProducts();
  return (
    
      
      
    
  );
}

// AddToCart.client.jsx
'use client';
import { useState } from 'react';

export default function AddToCart({ productId }) {
  const [added, setAdded] = useState(false);
  const handleClick = () => {
    // add to cart logic
    setAdded(true);
  };
  return (
    
  );
}

Notice the 'use client' directive to mark the client boundary. You can also transfer functions and data between Server and Client, but be careful: functions cannot be passed as props from Server to Client (they can't be serialized). Pass only plain data.

For global state across multiple Client Components, you can combine RSC with libraries like Zustand or Redux (only in client context). At Meteora Web we prefer Zustand for its lightness and RSC compatibility.

What to Do Next

Analyze your app: identify components that are only presentational and don't use hooks. Convert them to Server Components.
If you use Next.js with Pages Router, start planning your migration to the App Router. Server Components are one of the main reasons to do so.
Measure before and after: use Lighthouse or WebPageTest to compare bundle size, LCP, TTI. The numbers speak for themselves.
Learn the limitations: no access to window, localStorage, or browser events in RSC. Components that need them must stay Client.
Dive deeper with our main React guide, part of this pillar: React.js from zero to advanced (English version of the pillar page).