-
-
Notifications
You must be signed in to change notification settings - Fork 6.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dev Server: Cache Modules Unconditionally + HMR Cache Invalidation #16587
Comments
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? 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. |
In that case, the server could change the url of all the resources (e.g. |
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 👀 |
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
The text was updated successfully, but these errors were encountered: