The bundle problem they solve
Traditional React ships every component's code to the browser as JavaScript. Markdown parsers, syntax highlighters, date utilities — all sent to every user, even though they only transform data once.
The four concrete wins
- Smaller bundles. Server Components contribute zero bytes to the client bundle. Heavy data-shaping libs stay on the server.
- Direct data access. Query Postgres, read files, call internal services without an API hop — same data center, same process, microsecond latency.
- Security. API keys, DB credentials, internal URLs never leave the server.
- Streaming. Server Components can stream HTML progressively. Cheap parts ship instantly, slow parts stream as data arrives.
The real-world bundle math
A blog post page using marked (~200KB) and highlight.js (~800KB) on the client costs every visitor 1MB of JavaScript. The same page as a Server Component ships zero bytes for those libraries; the rendered HTML is what reaches the browser.
Look for client dependencies whose only job is to transform data into display output. Markdown parsing, syntax highlighting, and large date libraries can often stay on the server while the browser receives only their rendered result. Measure the resulting client chunk, not just the source diff.
Zero client bytes does not mean zero cost. The server still runs the library and sends HTML. If the work repeats on every request, compute can become the new bottleneck. Cache stable results and measure response time along with bundle size. Move one heavy display dependency across the boundary and compare JavaScript transfer, hydration work, server duration, and a cached repeat request. A successful optimization improves the total path rather than moving an invisible bill.