Persistent Cache

[yyx990803]

#1207 (comment)

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.

[lubanproj]

@yyx990803 Recently, I found that pre-binding has been implemented through esbuild in the optimizer directory.

Is this problem solved?

[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.

[kjeske]

The idea of persistent cache sounds great. It's been a while since the issue was created. What's the current status?

[carl-jin]

最近把老项目从 webpack 迁移到 vite 时又遇到这个问题了，记录了下优化的方法， 虽然没有从实质上解决问题，但是也加速不少，https://carljin.com/vite-resolve-request-files-a-ton.html

[zheeeng]

Any discussion opened for this issue? Hope to apply a service worker as @AlonMiz mentioned to do some pre-tasks with a more heuristic pre-bunding discovery algorithm and persist them.

[davidwallacejackson]

@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!

[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

[davidwallacejackson]

@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

Thanks for letting me know. Did HMR/Fast Refresh work for you at all? Curious because I'm currently betting big on optimizing my own app for HMR.

[AlonMiz]

@davidwallacejackson yes it did pretty well in most cases, some issues in edge cases, but not something significant.
eg. developing react components worked great

[carl-jin]

Hi, guys, I found a couple steps to optimize browser loading performance. Although it cannot solve the problem from the root cause, but it speeds up a lot.

If u want to quickly feel the changes after optimization.
Here are some suggestions

1. use Chrome dev version as u dev browser
2. Install as less browser plug-ins as possible,Especially The AdGuard and AdBlock who tracking every record you request when opening the page.
3. use https and make sure ur certificate is valid, vite-plugin-mkcert. like this issue mentioned https dev server does not use browser cache #2725. You don't want 304 cache not working, right？
4. As mentioned in the article, optimize your pre-build https://vitejs.dev/config/#optimizedeps-include

I recently migrated the aPaaS project from webpack to vite and optimized it according to the above steps. The following is a speed comparison

tool	Server startup time	First time page loaded (no cache)	Second time page loaded (with cache)	HMR	built
Webpack	83s	4.78s	3.35s	4.78s	3mins 37s
Vite	4.72s (second time 0.72s)	1.71s	1.33s	less then 300s	51.45s

[carl-jin]

Hi, guys, I found a couple steps to optimize browser loading performance. Although it cannot solve the problem from the root cause, but it speeds up a lot.

If u want to quickly feel the changes after optimization. Here are some suggestions

1. use Chrome dev version as u dev browser
2. Install as less browser plug-ins as possible,Especially The AdGuard and AdBlock who tracking every record you request when opening the page.
3. use https and make sure ur certificate is valid, vite-plugin-mkcert. like this issue mentioned https dev server does not use browser cache #2725. You don't want 304 cache not working, right？
4. As mentioned in the article, optimize your pre-build https://vitejs.dev/config/#optimizedeps-include

I recently migrated the aPaaS project from webpack to vite and optimized it according to the above steps. The following is a speed comparison

tool Server startup time First time page loaded (no cache) Second time page loaded (with cache) HMR built
Webpack 83s 4.78s 3.35s 4.78s 3mins 37s
Vite 4.72s (second time 0.72s) 1.71s 1.33s less then 300s 51.45s

This is the details of optimization step and why https://carljin.com/vite-resolve-request-files-a-ton.html

[carl-jin]

@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

I successfully migrated a large project from webpack to vite. The biggest problem I face is that some packages do not support ESM, you have to write compatibility or re-fork and release. For example, ant-desgin-vue needs to write a vite plugin to solve the ESM problem in their code. It took me about 1 week to process the migration, and now I am very satisfied, because the HMR speed of vite is so dope, once you experience it, you can’t forget it.

[userquin]

If anyone interested I open this repo to play with this (POC), recenlty pushed and still not working: https://github.com/userquin/vite-dev-sw

The sw is being registered with type: 'module' and so we can use esm on it: in fact I'm using import.meta.env.BASE_URL on the sw rn.

Initial gist from @davidwallacejackson.

EDIT: rn it is also working with F5 and Crtl + F5, we can now play with the sw

[userquin]

we can also inject some resources such as precaching on the plugin, rn we read it from file, if we have the transform cache on disk we can inject it on the sw.

[Bunkerbewohner]

The slow initial page loads are still the main issue we have that impacts vite adoption. On some pages of our app there are 1900 module requests, and especially on Linux laptops it can take up to 30 seconds to do the initial load, even if no files were actually changed and it was just vite that was started again.

For this reason we have kept webpack around and some devs prefer using webpack especially when they work mostly on the (Python) backend of the app, since then bundling only happens once and afterwards all page loads are fast.

Any way to speed this up, whether it's using a persistent file cache, service workers, or something else, would be great.

[ArnaudBarre]

If you're using React you can get a speed up by using https://github.com/ArnaudBarre/vite-plugin-swc-react-refresh

[justinbhopper]

Has anyone considered using websockets to get around the HTTP connection concurrency limits?

[lovetingyuan]

always use http2

[milahu]

less then 300s

@carl-jin less than 0.3s?

[WangJincheng4869]

不仅仅是大型项目加载慢，我的项目只有两个页面，登录页和首页，组件不超过10个，但是首屏加载竟然需要45秒，惊呆我了...

[ArnaudBarre]

Hi everyone,
The current decision of the team is to make the core faster so cache is not needed. And if one plugin/processor is slow, the cache should be done at this level, not for everything.
You can help make Vite faster by providing link to slow apps or sending profile output (vite --profile and press p when the page is loaded)

Also http1 is not the limitation: https://github.com/ArnaudBarre/esm-dev-server-limit

[brillout]

With RSC, an increasing number of npm packages will need transpilation. If an RSC app has 20 npm packages that need transpilation, then it seems to me that we'll need a cache. Especially considering that RSC code living at node_modules/ can't be transpiled by esbuild alone but will require a slow JavaScript plugin vite-plugin-react-server-components.

E.g. a global cache ~/.local/share/vite/cache/npm/some-npm-package/ for npm packages. Essentially something like this: #8721 (reply in thread). A bit like pnpm's global cache ~/.local/share/pnpm/store/.

[ArnaudBarre]

Let's see how this RSC move plays out in the ecosystem, but I'm confident that either someone will make a fast transformer for it, either a small cache on top of the RSC transformer will be good enough and easy to implement (or maybe the RSC architecture will not play nicely with Vite, but that's another issue)

[brillout]

👍 I agree.

Although a global cache could be a pretty cool addition nevertheless: a global cache guarantees that Vite's dev speed stays instantaneous (library sizes increases while on-demand user code size doesn't).

On a tengent: a global cache would allow use to aggressively transform npm packages, e.g. to remove CJS-ESM compatibility problems.

But, I agree, let's see how things turn out.

[JiangWeixian]

For RSC case, the cache problem is something like this? https://github.com/Shopify/hydrogen-v1/blob/v1.x-2022-07/packages/hydrogen/src/framework/plugins/vite-plugin-hydrogen-client-components-cache.ts

[lovetingyuan]

不仅仅是大型项目加载慢，我的项目只有两个页面，登录页和首页，组件不超过10个，但是首屏加载竟然需要45秒，惊呆我了...

这不太可能是vite的问题

[WangJincheng4869]

不仅仅是大型项目加载慢，我的项目只有两个页面，登录页和首页，组件不超过10个，但是首屏加载竟然需要45秒，惊呆我了...

这不太可能是vite的问题

没必要洗地的，官网已经承认现在vite的性能就是差，在想办法优化。只要用了SCSS就会卡，你可以试试配置element plus 自定义主题，配置scss之后明显变卡。

[burdiyan]

Lack of persistent cache and annoying unnecessary rebuilds is my main frustration with Vite in comparison with Parcel 2 (which has its own flaws too, but speed and annoying unnecessary rebuilds are not those).

[Priestch]

不仅仅是大型项目加载慢，我的项目只有两个页面，登录页和首页，组件不超过10个，但是首屏加载竟然需要45秒，惊呆我了...

这不太可能是vite的问题

没必要洗地的，官网已经承认现在vite的性能就是差，在想办法优化。只要用了SCSS就会卡，你可以试试配置element plus 自定义主题，配置scss之后明显变卡。

项目使用了 less，sass 是会显著降低打包工具的性能，vite 目前是按单个组件来进行 transform，随着组件的增加，性能肯定会变差。

但是两个页面，不超过 10 个组件，极大可能是哪里配置的不合适，是可以优化的。最近接触了两个产品项目，一个使用 Less(Ant Design Vue)，一个使用了 Scss(Element Plus)，使用 Less 的不论是开发还是打包，都需要 45-50 秒，使用 Scss 的打开开发环境 14 秒左右，打包将近 50 秒。

我把使用 Less 的项目打开开发环境优化到了 5s 左右，打包 18s。主要是 preprocessorOptions 的 less.modifyVars 配置的有问题，导致在 transform 每个组件的样式前都需要把整个 ant design 的所有 less 文件都 compile 一下，但常规项目只需要把相关的变量处理下就好了。