Respect Cache-Control of serialized SSR fetch responses during subsequent client-side navigation

[Conduitry]

Describe the problem

The fetch responses that are serialized as part of the SSR response are currently only used during the initial hydration of the app. If the same URLs are requested during subsequent client-side navigation, these requests are performed (at least) once more, regardless of the Cache-Control headers in the responses.

Describe the proposed solution

It would be nice if, even after the initial view is hydrated, the fetch function that's passed to load still checked with the serialized responses to see whether any of them are still valid. We should already have the information we need to make this decision, because the response headers for all of these requests are also serialized into the server-rendered HTML.

Alternatives considered

No response

Importance

would make my life easier

Additional Information

I have a fairly large chunk of data I want to expose throughout my app. When I request it in the root __layout load and expose it through stuff, this results in the data being requested again after navigating, regardless of the Cache-Control header in the response.

Currently, my workaround is to fetch the data during the handle hook and expose it through session. From here, the root __layout can then still expose it to the rest of the app with stuff without requiring widespread code changes.

[Conduitry]

If possible, we should also ensure that any etag returned in these responses is manually added as if-none-match in the first request to a given URL, so we can also take advantage of that type of caching. I'm not sure whether browsers or the Fetch API let you control that.

[dummdidumm]

I'm not sure if the added complexity of implementing this is worth it