Persistent Cache

https://github.com/vitejs/vite/issues/1207#issuecomment-753564633

Vite’s current biggest performance bottleneck is first page load with large amount of modules. This is mostly caused by congestion at the browser network layer, since every module results in a full HTTP GET request on fresh server start.

To improve this, we can dump the in memory transform cache to disk on server close, and “hydrate” the module graph on next server start (the hydration should only fill in the cache for files with still fresh mtimeMs). The cache can be dumped in one file so it should be relatively fast to deal with. This allows the server to directly send 304s even on a restart.

[AlonMiz]

we started to migrate our monorepo to vite. our biggest frontend project has around 2800 modules on load. we were able to reduce it to 1800 with lazyload after some work. currently, we offer vite as an alternative alongside webpack, but it’s not the default bundler yet, in dev. the main reason why we can’t deprecate our webpack dev in favor of vite alternative is that it takes a long time to reload the page. the load of 1800 creates a great bottleneck, and in our case, it can take from 10s to 20s depending on how much load there’s on the developer machine.

Suggestion: cache the files with a service worker, that after the first load, at least any consecutive load would be fast, and when a module is being changed that info can be transmitted by the hmr mechanism/websocket and deprecate the out of dated module.

[AlonMiz]

@AlonMiz, curious if you’ve improved your load performance in the interim – we’ve got a project on a similar scale facing the same sorts of issues. Would love to compare notes!

Unfortunately, we’ve halted the vite migration from webpack. We couldn’t find an intermediate solution for this. Developers preferred one slow load and fast refreshes than fast first load and long refreshes