Dev Server: Cache Modules Unconditionally + HMR Cache Invalidation about vite

[ArnaudBarre]

This is an interesting idea but we need a way to cleanup the cache when the server sends a full reload event because things changed that requires a reload and the expected behaviour is that the browser will ask for the new version of the changed file that could not be hot replaced.

It would also requires using some local-storage timestamp to differentiate between manual reload and "close the tab and re-open one minute later".

I've personally experimenting with content based caching that persists accros dev server restart, pinging @patak-dev that was once asking for real world timing of the difference between 304 and cached 200.

[patak-dev]

I think content based caching is still an interesting idea to explore. I'm not going to be able to do it for a while as the current focus shifted after the perf optimizations we got in 5.1. Maybe something to look back again once the Environment API work lands.

@hediet do you have extensions installed? Would you check the time diff using an incognito window in that case?
Last time I checked, with an incognito window, the diff between having the dev tools open or not was not that big (https://x.com/patak_dev/status/1745427467480039580, https://x.com/patak_dev/status/1745681046681563153).

I agree it would be better to find a way to avoid the 304s though. If someone wants to explore in a PR, we could discuss the tradeoffs there.

[hediet]

This is an interesting idea but we need a way to cleanup the cache when the server sends a full reload event

In that case, the server could change the url of all the resources (e.g. ?t=${t++}) and just ask the browser to reload the html file (which will never be cached).

[ArnaudBarre]

Yes but in that case you trade off good reload on manual reload against bad reload on dev server reload. That's something to be discussed but for me the real solution is content based caching 👀

[hediet]

Yes but in that case you trade off good reload on manual reload against bad reload on dev server reload.

Ah yes, I didn't think of that.

I'm not very aware of all the possible http caching strategies, can you clarify what you mean with content based caching?

[ArnaudBarre]

I mean using a hash of the content of the transformed file into the URL so that you don't need to invalidate the browser cache when nothing change. This requires a big shift in Vite philosophy to be 'on demand' and I'll wait after Vite 6 to see if this is something that can be added