Should updated warm the new build’s assets before the forced reload?

[alexbjorlig]

When kit.version.pollInterval detects a new deploy, the documented path is to force a full-page navigation (beforeNavigate + location.href, or data-sveltekit-reload). That works, but the reload is a cold cache: every hashed /_app/immutable/* file is new, so the first load after deploy is slow.

preloadCode / data-sveltekit-preload-code can’t help here — they use the running client manifest, i.e. the old hashes.

A small custom workaround: when updated.current becomes true, fetch the current URL with cache: 'reload', parse same-origin /_app modulepreload / stylesheet links from the new HTML, and fetch those so the subsequent hard reload hits the HTTP cache.

Questions:

1. Is that the intended app-level pattern, or is there a Kit API we missed?
2. Has anyone considered doing this in Kit itself when a new version is detected (related to Proactively handle version updates #3666, but just warming assets for the reload — not swapping the route manifest)?
3. Any reason this is a bad idea (auth HTML, saveData, racing the next navigation, etc.)?

We already poll and hard-reload; this is only about making that reload cheaper for tabs that were open during the deploy. Closed tabs / first visits are unchanged.