2 October 2026 ·Engineering·1 min read

Server Components in practice: what moved, what stayed

After shipping several production sites on the Next.js App Router, here is where server rendering paid off and where we kept things on the client.

Xavour Team · Engineering

React Server Components change where work happens. After a few production projects, a pattern has settled for us.

What we moved to the server

Data fetching. Pages read their data directly, with no loading spinners and no waterfall of client requests.
Content-heavy pages such as articles, case studies and docs. They ship almost no JavaScript.
Anything with secrets. API keys never leave the server, by construction.

What stayed on the client

Anything that reacts to the user right now stays interactive: menus, filters, forms, animation. The trick is to keep those islands small and pass them plain data from a server parent.

// Server component: fetches and passes plain data down
export default async function Page() {
  const posts = await getPosts();
  return <PostFilter posts={posts} />; // client component
}

The rule we use

Start on the server. Add "use client" only to the smallest component that truly needs state or browser APIs. When a client component grows large, that is usually a sign to split it.

The result is faster first loads, smaller bundles and, honestly, simpler code.