RSC payload, prefetching and the client cache

A Next.js page is rendered on the server into the RSC payload (React's Flight format): the output of Server Components, placeholders and chunk references for Client Components, and the serialised props passed to them. On a first visit the server also turns it into HTML; the browser shows the HTML, then React uses the payload to reconcile and hydrate Client Components.

On client navigations no HTML is fetched: the router requests the RSC payload for the changed segments only and merges it into the current tree, so shared layouts keep their state. A Server Action response carries both the action's return value and, if it revalidated data, a fresh payload for the current route in one round trip.

Prefetching: <Link> prefetches routes as they enter the viewport or on hover. With Partial Prefetching (the default in new apps), the router prefetches each route's App Shell (static content plus session data); prefetch={true} additionally renders cached, URL-dependent content per link at the cost of a server invocation each. Prefetched payloads live in the client cache for their stale lifetime (from cacheLife, or staleTimes config).

What makes navigation slow: dynamic routes without a loading.tsx or Suspense boundary (nothing can show until the server responds), dynamic params not covered by generateStaticParams, large payloads (props passed to Client Components are serialised into every payload) and slow networks. useLinkStatus() can show pending state on the clicked link.