Splitting fetch request in two loaders - optimizing for prefetch and HTTP/CDN cache

[chrisvltn]

We're starting to experiment with HTTP Cache (Cache-Control header) and CDN cache (in our system, also works with a HTTP header), and have seem quite some improvements for the client in terms of performance, mainly in combination with <link rel="prefetch"> to eagerly request those pages and cache them in the browser.

The problem now comes when the route handles authenticated data - session, cookies, etc. Here, we obviously can't use CDN caching, but instead a short HTTP cache, at best. The problem is that this route also requests static/public data, which could be cached.

Is there a way React Router provides to split a route loader into two? One for the "private" data, which goes uncached, and another for the "public" data, that can be cached?

Example:

Let's say we have a product page for an e-commerce. Part of the data is normal product data - images, name, price, etc. These rarely change, so we could have, say, 5 minutes of cache in CDN. On top of that, we want to display the delivery time of the product, which depends on the address of the logged-in user. For this, we'd use a different endpoint to get that.

So once the user clicks on a <Link> to that product page, the does 2 requests:

• /my-product.public.data: Gets the public product data
• /my-product.private.data: Gets the "private", user-specific product data

Before:

After:

Main goals

The main advantages and goals for this are:

1. Less load on the server
2. Less browser wait time, earlier TTFB

Considered approaches

1. Fetch additional endpoint in the page Component

Problem: Doesn't run on server-side render, and only happens after first endpoint finished

2. clientLoader to fetch additional endpoint

Problem: Doesn't run on server-side render, and only happens after JS of the Component is fetched

3. Use a "public" Layout route, "private" main route

Problem: HTTP headers still can't be separate due to Single Fetch.

[sergiodxa]

You need to create two nested routes, this way you can have a route loader with only public data and another with only private data.

Then add a clientLoader to the public route, this will make that route be separated from the rest of the routes, so you can cache it individually.

This will only work for non-SSR requests, as SSR is a single request always, the only option you would have in that case would be to SSR with only public data, or with only private data, and then fetch the other one client-side.

---

That said, using a server-side cache would be better, cache the public data in a shared cache key using something like Redis or Cloudflare Worker KV, then read from there. This will also let you easily invalidate the data (you can just purgue your cache), and even share it across users/devices.

You could also cache the private data, just ensure the cache key somehow identifies the user so other users won't reuse the cache.

[chrisvltn]

Thanks for the tip!

I attempted this here: https://codesandbox.io/p/devbox/upbeat-feather-drhkhd?workspaceId=ws_V1YfYhJY4PusFRseBUhmXL

It works... partially.

Adding the clientLoader was indeed the secret to make RR send separate requests for the "private" and the "public" routes.

But, adding the Cache-Control header to the public route also added it to the private route, even though the requests are done separately.

Adding a headers function to the private route to clear the public route's headers also didn't solve, as this cleared the public route's headers too 😅. Is it an expected behavior, that even though the routes parameter during the .data request explicitly asks just for the private/public route, the header from both routes gets executed and parsed?

[chrisvltn]

Another point to this 👆 I noticed using clientLoader to split the loaders makes the <Link prefetch="viewport"> not prefetch the route loader.

So even though the routes get split, we'd still have to wait for the user to click on it (to execute the clientLoader) before fetching the data, making prefetch mostly useless. 😞

https://web.dev/articles/link-prefetch

Prefetched files are stored in the HTTP Cache if the resource is cacheable, otherwise it will be discarded and not be used.

[brophdawg11]

A public/private split like this is a bit against the original goal of single fetch which was to more closely align how document/data requests work. We found the default behavior pre-single-fetch meant that folks very often messed up the caching for one scenario or the other. If we were to add a split like this we're right back into the same boat where you can't cache document requests but you can partially cache data requests.

As noted above, clientLoader is the "sharp knife" to carve out singular requests - but you may have identified a small gap there since we don't give you the request in headers, you can't properly decide if you should cache as public or private. We recently merged a new unstable flag to give you more visibility into the request in loaders/actions so you could adopt that and then I think at the moment you'd need to set a custom header in the loader you could key off of in headers to know when to clear or not. Maybe we should just be handing the request to headers as well...

My suggestion for this scenario through would be to just use a fetcher against a resource route for the private data. This has a number of benefits:

• re-enables caching of document requests
• re-aligns caching behavior of document versus data requests
• allows targeted headers control from a resource route without the need to do headers logic

And the main tradeoff is that the request initiation is delayed slightly because it has to happen on the client. On client side navs, you could manually prefetch the fetcher URL from your own link hover/viewport logic to eliminate this delay.

[brophdawg11]

We also have an open RFC for more advanced client-side prefetch behavior on Link which would give you a more ergonomic place to put this fetcher prefetching so keep an eye on that too.