React Server Components: what actually changes
Past the marketing, here is what is different in practice once you build this way.
The clearest change is not speed but where code runs. When a component can execute on the server, data fetching moves next to the thing that uses the data instead of being threaded down through layers.
A side effect is that the JavaScript sent to the browser shrinks, because server-only code never enters the bundle at all. A date-formatting library or a Markdown converter no longer spends the visitor’s bandwidth.
The thing to watch is the server/client boundary. Dropping a use client directive at the top of a page turns everything beneath it into client code, quietly returning you to where you started.
What works is keeping pages and layouts as server components without exception, and pulling out only the parts that genuinely need state or events into small components that declare use client for themselves.
Secrets are another common confusion. Environment variables without a public prefix are not shipped to the browser — but reference one inside a file marked use client and it lands in the bundle immediately.
The summary is that this model does not make a site fast on its own. It puts the performance decisions much more visibly in the hands of the person writing the code.