Why is a page with only client components requesting a RSC Payload?

[nareshbhatia]

Summary

I am trying to understand a performance issue when using only React Client Components on a page (+ App Router). It's a list-detail page. When I click on different items in the list, the client hits the Next.js server for an RSC Payload on every click. I don't understand why.

I would have assumed that all code for that page should be on the client after the first render, and from then on, the client would not have to load anything from the server. Can anyone help me understand this behavior and a potential workaround?

Please see details below.

My Use Case

1. Application data is changing frequently – data freshness is important. So data caching should be disabled.
2. Data is obtained from an external service that exposes a REST or GraphQL API.
3. FCP, TTI are not important (not a marketing or shopping site).
4. Responsiveness to user interactions is most important - as the user clicks on items in the list, we want to show the LATEST detail as soon as possible – the application should not feel sluggish.
5. Application is to be used in the field. Assume a Fast 3G connection at best.

Here's a screenshot of my POC – a movie list on the left and the selected movie's detail on the right. Granted this is not fast changing data, but it will do for the POC 😃

Implementation Details

I have implemented the requirements 4 ways to compare the performance:

1. Server Components: The entire page is built using React Server Components. Both list and detail data are fetched on the server.
2. Client Components: The entire page is built using React Client Components. Both list and detail data are fetched on the client. This is the preferred option give the requirements.
3. Fake Child: A variation of option 2, to improve performance (not successful). Here we are faking the nested child component by returning undefined (see here). This allows us to maintain the URL structure as /movies/id, but serve the detail as a hard-coded child (see here).
4. Query Params: Abandon the nested layout approach. Use a query parameter to get the detail. This approach also did not improve the performance.

Also, to meet the requirements, I have done the following:

1. Server-side fetches use the no-store option – see here.
2. Router Cache has been disabled - see here.

Example

• Live demo: https://nextjs-nested-layouts-ruby.vercel.app/
• Repo: https://github.com/nareshbhatia/nextjs-nested-layouts

Steps to Reproduce

Given that Client Components is my preferred option (option 2), let's first demonstrate the issue.

1. Point your browser to the live demo, which is the production build.
2. Open the Chrome Dev Tools (right click > Inspect).
3. Click on the Network tab.
4. Change network speed to Fast 3G.
5. In the application, click on the Client Components tab. The movie list appears on the left. The initial display may be slow because the API server may be cold starting, however subsequent loads should be fast.
6. Now start clicking on different movies in the movie list. You will see a loading indicator and then the movie detail appearing after ~1200 ms. This is the interaction that I am trying to speed up.

Analysis

Again, this analysis is focused on the Client Components option (option 2).

1. The parent layout is marked as a client component using 'use client' – see here.
2. The nested child is also marked as a client component using 'use client' – see here.

In spite of this entire page consisting of client components only, the browser is making two network calls on each movie click:

1. Call to the Next.js server to get the RSC Payload
2. Call to the external API to get the movie data

See the Chrome Dev Tools snapshot below for clarity:

I can understand if the RSC Payload is requested just the first time a movie is clicked. However, for subsequent clicks, we shouldn't have to download the RSC payload again because we are rendering the same client component repeatedly (just with different data). We are wasting 572 ms per click!

I would love to get (1) an explanation of why this behavior is happening and (2) a workaround where all we see is one call to the API server for each click.

This is hampering my ability to deliver a responsive user interface for this use case with Next + RSC. This would be a no-brainer to implement as a traditional React SPA.

[versecafe]

Your layout root is a server component to start and I think there are a few others spaced in there

[nareshbhatia]

Hi @versecafe, I tried adding use client to the root layout as well as the root page. But it makes no difference - the client is still trying to get the RSC Payload for each click. Below is the result of first 2 clicks:

Also note that adding use client to the root layout makes the entire application a client app, which defeats the purpose of using Next.js. I'd like to find a solution which retains the ability to mix server and client components.

[gkielwasser]

Hi @versecafe, I tried adding use client to the root layout as well as the root page. But it makes no difference - the client is still trying to get the RSC Payload for each click. Below is the result of first 2 clicks:

Also note that adding `use client` to the root layout makes the entire application a client app, which defeats the purpose of using Next.js. I'd like to find a solution which retains the ability to mix server and client components.

Hi @nareshbhatia I think this ticket The RSC payload includes server data from all segments, including those from shared layout might give you some insights about RSC payload and how it behave when mixing server and client components.

[nareshbhatia]

Thank you for pointing to your ticket, @gkielwasser. It seems to be related to my issue but not the same. In any case, I tried adding const dynamic = 'force-dynamic' to both routes (/ & /child-components) – for their layout.tsx as well as page.tsx components. Unfortunately it did not force the bundling to become dynamic and I am still seeing the RSC payloads when clicking on list items. Please see below:

Based on Next.js docs, Client Components are rendered entirely on the client on subsequent navigations (see here). In my use case, I am seeing exactly the opposite.

Would love to get a detailed explanation from Next.js folks regarding this:

1. Does the React Server Components RFC address this use case? As far as I can tell, pagination and partial refetches are listed as open areas of research.
2. How has Next.js implemented navigation after a full page load? Is there room for optimization?

An explanation, regardless of a potential solution, would help me make better decisions.

cc: @leerob

[rajeshdavidbabu]

The answer is that even if you place "use client" at the very top of your component tree, including your root layout.tsx, the Next.js server is still fundamentally involved in every navigation, and an RSC payload will still be requested.

The App Router's Core Philosophy: Server-Driven Navigation

The Next.js App Router is not a traditional Single-Page Application (SPA) router that operates exclusively in the browser. It is a server-centric router that uses React Server Components as its underlying primitive.

Think of it this way: the "use client" directive does not turn off the RSC architecture. Instead, it acts as a boundary marker that tells the server: "Stop rendering on the server at this point. Instead, send a placeholder and a reference to a JavaScript bundle that the client should download and execute."

• Here's what happens on a page switch, even if the destination page and layout are marked with "use client":
  • Navigation is Intercepted: When you click a component, the App Router intercepts the navigation event. It does not immediately try to render the new page on the client.
  • A Request is Made to the Server: The router's first action is always to make a request to the Next.js server for the new route.
  • The Server Generates the "Blueprint" (RSC Payload): The server receives the request and processes it. Because your entire page is a Client Component, the server's job is simple but essential. It generates an RSC payload that is effectively a set of instructions for the client-side router.