RSC and CDN interaction makes next.js inefficient for highload projects about next.js

[dankain]

Hi @samcx I have created a video to explain

RSC.CDN.GH65335.mp4

[1kuzus]

same problem

Edit by maintainer bot: Comment was automatically minimized because it was considered unhelpful. (If you think this was by mistake, let us know). Please only comment if it adds context to the issue. If you want to express that you have the same problem, use the upvote 👍 on the issue description or subscribe to the issue for updates. Thanks!

[samcx]

@dankain This is what I get on the latest canary (after doing these exact steps).

1. Load in next start
2. Client-side navigate to category 1
3. Navigate to /category/2

Can you confirm if you are seeing the same on the latest canary? →

[dankain]

Yes I have tried on the latest canary and it is the same. You need to go to category 1 and then category 2. Above I just see the navigation to category 2. If you go to both categories you will see there are 2 different rsc requests for the same product data

[RedVelocity]

This is causing issues for me as well, the random rsc string in the end always results in CF CDN cache MISS

[ztanner]

I'm trying to understand why the rsc has is different when it is always returning identical data?

In this case the Next-Router-State-Tree and Next-Url will be set on where you are coming from and do not necessarily have an impact on the data need for the page we are going to. The Vary header will again have an impact on the CDN

For some context, the ?_rsc hash is mean to mirror the Vary header. It was added because there are CDNs that don't honor the Vary header (example). If these headers don't change, the query parameter will be the same, signaling that given the same request headers, the response will be the same.

The reason the Vary header exists is because these headers actually can change the response from the server. For example:

• interception routes rely on the Next-URL header to decide if the request should respond differently (and return RSC data for the intercepting component).
• partial rendering relies on the next-router-state-tree header from the client to decide if the server should respond with the shared layout data, or only the page data, to avoid over-fetching and improve performance.

This is obviously not a solution to the issue you're describing, but I wanted to provide some color as to why app router is doing this. If those responses are cached, and the RSC data for a page returns a tree that corresponds with the request from a different page, things will start behaving incorrectly. For example, see:

• #49140

[dankain]

Thanks @ztanner , that helps with the context. Partial rendering is a great concept, but if it means I can't use a CDN effectively then that is an issue.

The problem with the next-router-state-tree is it is only something that the server can understand. The state trees for each of my categories and products are all different, only the server knows that they each have the same layout, therefore the transition from category 1 to product 1 or category 2 to product 1 would need identical data, even with partial rendering. Would it be possible to have the same vary header and RSC hash when the data is the same? It would require the client to understand the layouts?

If this is not possible do you have a suggestion on how to deploy next for a global site? Our site is hosted in Europe, but has southern hemisphere customers. Do I now need to somehow push the page building, HTML cache and data cache to an edge location?