Next.js 16 and React Server Components: The Mental Model Every Engineer Needs

1. Zero-Bundle-Size Server Execution

React Server Components (RSC) change what "component" means in a Next.js 16 app. A server component runs exclusively on the server, once per request, and never ships its own code to the browser. The output isn't HTML in the traditional sense either — it's a serialized React tree (the RSC payload) that the client runtime reconciles into the DOM. This means every import a server component pulls in — a date-formatting library, a markdown parser, a database client — stays on the server. It never touches the client bundle, never gets parsed by V8 in the browser, and never counts against your JavaScript budget.

In practice this reframes how you think about dependency weight. Before RSC, adding a heavy library like a syntax highlighter or a PDF renderer to a page component was a bundle-size decision you made carefully, often reaching for dynamic imports to defer the cost. With server components, that calculus mostly disappears for anything that doesn't need interactivity: you import it directly, it executes at render time on the server, and the client receives only the resulting markup and props. A blog rendering Markdown to HTML, for example, can import a full markdown-to-AST pipeline with zero client-side cost.

The App Router in Next.js 16 defaults every file under `app/` to a server component unless it opts out with `use client` at the top of the file. This default-server posture is deliberate: it forces you to justify client-side execution rather than justify server-side execution, which is the inverse of how the pages directory and most SPA frameworks worked. The practical effect on real applications is substantial — teams migrating dashboards and admin panels routinely see their client JavaScript payload shrink by half or more, simply because data-fetching and formatting logic that used to ship to the browser now never leaves the server.

2. Streaming SSR with React Suspense

Traditional server-side rendering is all-or-nothing: the server can't send a byte of HTML until every data dependency for the page has resolved. If one query takes 2 seconds, the entire page waits 2 seconds, even if the rest of the content was ready in 50ms. Streaming SSR, built on React Suspense, breaks that dependency. The server sends the page shell and any content that's ready immediately, then streams in additional HTML chunks — wrapped in inline `<script>` tags that reposition them — as slower data becomes available, without a client-side re-fetch or a second round trip.

You opt into this per-subtree by wrapping a slow server component in `<Suspense fallback={...}>`. The boundary you choose determines the granularity of the streaming: wrap the whole page in one boundary and you get one big flush after the slowest fetch; wrap each independent section (a sidebar, a comments list, a recommendations widget) in its own boundary and each streams in as soon as its own data resolves, independent of the others. This is the single highest-leverage lever for Time to First Byte and Largest Contentful Paint on data-heavy pages, because it decouples "page is visible" from "slowest query has returned."