• Use this when you want to reduce client-side JavaScript by running data-fetching and rendering on the server
• This is helpful for improving performance with zero-JS-cost server-rendered components in Next.js 13+ App Router

• Use Server Components (default in frameworks like Next.js App Router) for data fetching and non-interactive UI
• Add

  'use client'

  directive only to components that need interactivity (event handlers, state, effects)
• Server Components can use heavy libraries (markdown parsers, date formatters) at zero client bundle cost
• Server Components complement SSR — they are not a replacement for it
• Use Server Functions or Server Actions (

  'use server'

  ) for form submissions and mutations when your framework supports them

Update (React 19 / modern frameworks): React Server Components are now a production feature for framework users. Unlike classic SSR, RSCs let you render part of your UI on the server without shipping that component's JavaScript to the client. The Container/Presentational pattern is a strong fit here: the "container" can be a Server Component that fetches data and passes it to an interactive Client Component.

In Next.js App Router, you no longer use

getServerSideProps

—instead, any React component in the

app/

directory can be async to fetch data on the server. React Server Components are not a replacement for SSR—they complement it. You typically use RSC for the majority of the page (rendered and streamed as part of SSR), and add

'use client'

directives for components that need interactivity.

The

'use server'

directive is for Server Functions or Server Actions, not for marking a component as a Server Component. Server Components have no directive; they are the default in frameworks that support them unless you opt into

'use client'

.

• The React Server Components reference is the best current overview.
• The RFC is still useful for deeper implementation context.
• Next.js App Router documentation for the modern approach to Server Components
• Shopify Hydrogen and Server Components

[RFC]: Developers constantly have to make choices about using third-party packages. Using a package to render some markdown or format a date is convenient for us as developers, but it increases code size and hurts performance for our users

// *Before* Server Components
import marked from "marked"; // 35.9K (11.2K gzipped)
import sanitizeHtml from "sanitize-html"; // 206K (63.3K gzipped)

function NoteWithMarkdown({text}) {
  const html = sanitizeHtml(marked(text));
  return (/* render */);
}

[RFC]: If we migrate the above example to a Server Component we can use the exact same code for our feature but avoid sending it to the client - a code savings of over 240K (uncompressed):

import marked from "marked"; // zero bundle size
import sanitizeHtml from "sanitize-html"; // zero bundle size

function NoteWithMarkdown({text}) {
  // same as before
}

React.lazy()

// *Before* Server Components
import React from "react";

// one of these will start loading *when rendered on the client*:
const OldPhotoRenderer = React.lazy(() => import("./OldPhotoRenderer.js"));
const NewPhotoRenderer = React.lazy(() => import("./NewPhotoRenderer.js"));

function Photo(props) {
  // Switch on feature flags, logged in/out, type of content, etc:
  if (FeatureFlags.useNewPhotoRenderer) {
    return <NewPhotoRenderer {...props} />;
  } else {
    return <PhotoRenderer {...props} />;
  }
}

• Outside of a meta-framework (like Next.js), you often have to tackle this optimization manually, replacing

  import

  statements with dynamic imports.
• It might delay when the application begins loading the component impacting the user-experience.

import React from "react";

// one of these will start loading *once rendered and streamed to the client*:
import OldPhotoRenderer from "./OldPhotoRenderer.client.js";
import NewPhotoRenderer from "./NewPhotoRenderer.client.js";

function Photo(props) {
  // Switch on feature flags, logged in/out, type of content, etc:
  if (FeatureFlags.useNewPhotoRenderer) {
    return <NewPhotoRenderer {...props} />;
  } else {
    return <PhotoRenderer {...props} />;
  }
}

• Code for Server Components is never delivered to the client. In many implementations of SSR using React, component code gets sent to the client via JavaScript bundles anyway. This can delay interactivity.
• Server Components enable access to the back-end from anywhere in the tree. In older Next.js data APIs, logic often had to live in page-level functions like

  getServerSideProps()

  . With Server Components, data fetching can live closer to the component that needs it.
• Server Components may be refetched while maintaining Client-side state inside of the tree. This is because the main transport mechanism is much richer than just HTML, allowing the refetching of a server-rendered part (e.g such as a search result list) without blowing away state inside (e.g search input text, focus, text selection)

• Locates all Client components
• Creates a mapping between IDs => chunk URLs
• A Node.js loader replaces imports to Client components with references to this map.
• Some of this work will require deeper integrations (e.g with pieces such as Routing) which is why getting this to work with a framework like Next.js will be valuable.

• patterns.dev/react/react-server-components