Open hediet opened 2 months ago
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.
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.
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).
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 👀
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?
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
Description
For very large applications (such as the monaco editor), caching with
Cache-Control: no-cache
+ Etag is good, but it could be even better. This is the network profile reloading the monaco editor from the vite dev server:Every request is a 304 Not Modified, but it still takes 1.4 seconds. This is because the browser still does 860 requests to check if the cache is valid. (However, when the dev tools are closed, it is much faster, though I don't know how to measure that - also, usually, while developing a site, the dev tools are opened)
Suggested solution
If the vite dev server would
?t=${devServerStartupTime}
to every module linkCache-Control: max-age=3600
(or bigger value) for modules it servesfetch(changedModuleUrl, {cache: "reload"})
for every changed module to force-refresh the cachethen, reloading after a change gets down to less than 400ms (with dev tools open):
If nothing changes, the browser doesn't have to fetch anything from the vite dev server. If something changes, only the cache of the modified modules are invalidated. If the server restarts and the HMR websocket connection closes, the
?t=...
parameter makes sure the browser does a full reload.Btw. nice work on this tool!
Alternative
No response
Additional context
No response
Validations