Data preloading expiration and opt-in/out per route

[rChaoz]

Describe the problem

Data preloading is often enabled site-wide by including data-sveltekit-preload-data="hover" in app.html. This can then be disabled/enabled per-section/link, which is not ideal. Also, I am not quite sure if preloaded data ever expires.

I have a data-intensive dashboard page, on which data can get outdated quite fast (a few minutes), so I don't want pre-loading on it. This is linked in multiple places, so I had to manually add data-sveltekit-preload-data="none" on every link to this page, making sure not to forget any, also remembering to disable preloading if I later add another link to this page.

The main issue, however, is that, once hovered and the data is loaded, it never seems to expire. So, if you use the default preload-on-hover behaviour, and you follow these steps:

1. Hover a link
2. Wait 5 minutes doing other stuff on the current page
3. Go to the link

The data will be outdated (from 5 minutes ago).

Describe the proposed solution

Some pages don't do well with preloading, but this is per-page, not per-link. It makes more sense to say "this page can get outdated fast" rather to specify per-link (why would a link to page X need preloading but a different link to the same page X not need it?). There should be a export const dataPreload = false in +page.ts to prevent data preloading for a specific page.

As for the main issue, there should be a way to tell SvelteKit to not hold onto preloaded data for too long.

Importance

nice to have

[kran6a]

I think a better solution would be honoring the Cache-Control header in the load function response. If according to Cache-Control the response is fresh, it should be reused. If Cache-Control says cached data cannot be served when the actual navigation occurs, then refetch.

This way we don't reinvent the wheel nor increase SvelteKit API surface. Maybe SvelteKit's fetch implementation could track Cache-Control headers returned by fetch calls inside load functions and take the shortest one by default so you don't need to set the headers on every load function.

Also I think we should be configuring preload at the link level and not at the +page.ts level because there are use-cases where you may want different behavior on different places (e.g: on a CRM, the page listing staff members may be preloaded on hover if navigated from the sidebar but you may want to preload it on tap if navigated from the "edit staff member" page as otherwise it might not include changes you just made).