Moving rendering from a Client Component into a Server Component in the Next.js App Router removes JavaScript from the bundle, but the work is not free. What does the browser download instead, and how does that cost behave differently from a JavaScript chunk?

## Two different currencies The naive framing of Server Components is "less JavaScript, therefore faster." The honest framing is that you are trading a **code-sized, cacheable, one-time** cost for a **data-sized, recurring** one. A strong answer names both and says when each wins. ## What a client chunk costs When a component is a Client Component, its module and everything it imports are compiled into browser chunks. That cost has a specific shape: - **Sized by code**, not by data. A table component costs the same whether it renders 10 rows or 10,000. - **Downloaded once.** Chunks are served under content-hashed filenames with long-lived immutable caching, so a repeat visitor pays nothing on the wire. - **Reused across routes.** If three routes use the same component, they share the chunk. - **But re-parsed and re-executed.** Every load pays JavaScript parse, compile and execute time on the main thread — the expensive part on low-end devices — and the component then renders in the browser. ## What the RSC payload costs When the component is a Server Component, the browser instead receives the RSC payload for that render. Conceptually it is a stream of instructions describing the rendered output: element trees, text, and references to client components together with the props they should be mounted with. - **Sized by data.** Render 10,000 rows on the server and 10,000 rows' worth of markup description crosses the wire. - **Fetched per navigation.** On a fresh document load the payload is inlined alongside the HTML; on a client-side navigation Next fetches the payload for the target route rather than a new HTML document. - **Not shared across routes.** Two routes rendering similar trees each produce their own payload. - **But nearly free to apply.** There is no user code to parse or execute for the server-rendered parts; React reconciles the described tree. Next does keep a client-side Router Cache so that going back to a route you just visited can reuse its payload, and prefetching warms it. The important caveat for interviews: **the staleness defaults of that cache have changed across Next majors** (this answer assumes Next 15/16 App Router), so answer in terms of "there is a client router cache, keyed per route segment, and here is how I would verify what it is doing" rather than quoting a number. ## When each side wins Server rendering wins when the output is much smaller than the code that produced it: markdown parsing, date and currency formatting, i18n, syntax highlighting, chart data preparation, anything driven by a large dependency that emits modest markup. It also wins when the component is rendered once and never re-renders in response to user input. Client rendering wins when the same code is reused across many renders of large or rapidly changing data. A grid whose sorting, filtering and virtualisation happen locally ships its sorter once and then re-renders thousands of rows with zero network cost; pushing that to the server means a round trip and a fresh payload per column click. ```tsx // Server-side: 60 kB of formatting code stays home, ~2 kB of text ships <PriceList items={items.map(i => ({ ...i, label: fmt.format(i.price) }))} /> // Client-side: 6 kB sorter ships once, sorting 5,000 rows costs no network 'use client' export function SortableTable({ rows }) { /* sorts locally */ } ``` ## The measurement that settles it Do not argue this from first principles in a real codebase — measure both sides. `next build` reports First Load JS per route, which is the client half. The payload half you observe in the network panel: on a client navigation, look at the size of the request Next makes for the target route. A change that removes 40 kB of JavaScript and adds 200 kB of payload per navigation is a regression, and only the numbers tell you. ## The failure mode to name The classic mistake is moving a data-heavy render to the server and treating the resulting payload as free because "there is less JavaScript now." A list of 5,000 fully rendered rows serialized on every navigation is worse than the small client component that rendered them from a compact JSON array. Pushing rendering to the server is a win when it shrinks *code*, not when it merely relocates the *data*.