Page reload very slow, unbundle DX for large web app is not satisfactory

[yArna]

When i use Vite on a real world large web app, we encounter a poor experience: page reloading is extremely slow, and using the network panel in Devtool may result in freezing for several minutes.

The reason is that Vite's current unbundle mechanism is not suitable for large web app development, as it reloads a large number of code files and generates numerous requests on every page refresh. While Vite has Dependency Pre-Bundling to solve third-party dependency issues, for large web app, our own codebase is also substantial. When a page has 500 source files simultaneously, the development experience becomes terrible, and this number is not uncommon for large web app. Our real projects have 1500 to 2500 source files.

If the page undergoes hot reload, the speed is very fast, but not every code modification can be hot reloaded. Furthermore, page reloading (including page navigation) is often required during development and testing.

Users initially have a good experience using Vite for faster development. However, as the project grows, they find that page reloading becomes slower and freezing may occur for several minutes when using the network panel in Devtool. At this point, users may discover that tools like Parcel, which bundle during development, provide a better experience. Although Parcel may have a slower startup, it becomes fast once it is up and running, and the network panel in Devtool does not freeze.

For large web app, the current unbundle mechanism is not suitable because there will always be a significant number of requests. Perhaps Vite can provide an option to bundle during development, where the majority of code files are bundled, or find other ways to reduce the number of requests.

I believe this is a pressing issue that Vite needs to address because over time, the projects of Vite users will continue to grow. When users realize that the development experience with Vite is deteriorating, they will face the dilemma of migrating to development bundling tools like Parcel. Vite has excellent development experience and ecosystem, and I hope it can solve this problem and retain users of large-scale web apps within the Vite ecosystem.

Numbers

• Recorded over 5 runs
• 2.4 GHz Intel Core i5 - MacBook Pro

	Vite (4.3.9)	Parcel (2.9.3)
Components	2500	2500
Requests	2514	4
Page Load	5.88s 100%	0.12s 2%
Devtool Network Freeze	75.28s 100%	1.02s 1.3%

Reproduction

Parcel vs Vite Reload Benchmark

[noisyscanner]

Have also found this to be an issue using Purescript, as all Purescript dependencies are also built at the same time as app source code rather than being pre-built under node_modules.
It would be great if we could use optimizeDeps or similar to tell Vite to also pre-bundle some of the built dependencies at output/<module_name>/index.js (where compiled Purs code goes).

Perhaps by providing a regex matching our module names, Vite could pre-bundle everything else under output/.

[patak-dev]

Improving the experience for large apps is definitely on our radar. The performance work we did in Vite 4.3 was in part triggered by this. Our current thinking then was that the bottleneck isn't at the number of requests but in the time it takes to process them. Even with these improvements in place, there is a limit though. Loading 2500 modules is going to take a few seconds to load. The dev tools network freeze seems something that should be improved/reported on Chrome's side (@bmeurer are there issues you are aware tracking this problem?).

It is also recommended to codesplit your app using dynamic imports, which would help a lot the experience. But we know this may not be possible for all apps.

We also discussed how to pre-bundle parts of your apps. To add the mechanism needed to select what to prebundle and properly invalidate, we may end up replicating the tools that monorepos already offers. So maybe it is better to break down large apps into smaller packages so pre-bundling can take care of this.

Anthony Fu created a vite plugin to explore this solution on user space:
https://github.com/antfu/vite-plugin-prebundle. Maybe you could try it out and give feedback.

Note: the repo is using vite-plugin-swc-react-refresh, it would be good to migrate to @vitejs/plugin-react-swc

[yArna]

Devtool network freeze is Chrome bug, It seems to be fixed in the latest version on Chrome 115.

I think for large pages the bottleneck is the number of requests, because:

1. Browser has a limited number of http concurrent requests (even http2). Most of the time spent in request stalled, I tested fetching these 2500 requests with nodejs, and it took only 1.4s, while it took 8.5s in the browser.
   

2. In addition to waiting for the concurrency limit, the time consumption of each request is also very objective, especially for large projects with many small files. Compared with processing code, the fixed consumption but a very high proportion.

3. The extra time consumption caused by a large number of requests cannot be compensated by caching.

In my real project, I have used methods like dynamic imports to reduce the number of files loaded on first load, But for large projects, where the number of files is very high, these means have very little effect.

vite-plugin-prebundle is a very good attempt. In the test repo, it reduced the reload time from 6~8s to less than 1s. but it still has some problems (can't be used with vue plugin) and can't be used in real projects.

Very much looking forward to its future progress.

A little personal thought, may be available in the future proposal-module-declarations simply merge the module files together directly, without code bundle, In this way, you don’t need to go through the bundling system, just work on the dev server module directly.

[noisyscanner]

Thanks @patak-dev. Actually dev tools freezing was our main issue, the page itself actually loads fine.
I gave vite-plugin-prebundle a go with our 2500+ modules, but actually this made Vite itself freeze - sometimes even ctrl+c did not stop it and I had to kill it - so unfortunately in its current form this won't work for us.

Code splitting is definitely something we would like to add, but for us this comes with its own Purescript-specific hurdles (unrelated to Vite).

From our side actually I don't think we actually need Vite to decide what to prebundle outside of node_modules. We can easily get that with a simple glob('output/!(KeepThisModule)/*.js') - we just need a way of providing this to Vite.

[bmeurer]

As @yArna said, the Network panel slowness was a Chrome DevTools bug (https://crbug.com/1447912), which has been fixed.

On the loading side, I'm not an expert, but I'd expect that with something like 2000+ requests, you are stretching the limits of what can be done fast in the browser.

[yyx990803]

Just tested the linked repo with latest Vite (5.0.4) and @vitejs/plugin-react-swc (3.5.0).

Results on my M2 Pro MBP:

• 1000 React components

  • Initial load ~300ms
  • Initial load with network tab open ~450ms
  • Full page reload ~250ms

• 2500 React components

  • Initial load ~620ms
  • Initial load with network tab open ~1000ms
  • Full page reload 460~690ms

Could just be that my machine is too fast... but then I tested with Parcel + 2500 components, and it took Parcel 3.16s to build before the page showed anything. In other words, Vite is actually faster than Parcel in your benchmark (at least on my machine).

[yArna]

Looks like my MacBook Pro 2019 is a bit outdated

[yArna]

More test results：https://github.com/yArna/vite-vs-x

[ShaharIlany]

Does anyone have some hack on Chrome that will allow it to load all the resources in parallel? I am using vite with 3000+ components and the actual issue is to load it when the DevTools is open...

[exones]

I would like to backup the results of @yArna (great job 👍) : we are experiencing exactly the same symptoms on our large React app. We are moving away from CRA and we experienced the degradation of the dev experience, not the improvements.

Most of the time is spent in stalls indeed (I attach a HAR file): the majority of the load time is taken by the dependency chunks loading (rather stalls).

Here's the app stats:

It takes around 10-15 seconds to load the page.

Half of the time nothing happens network-wise which suggests that actual loading time could be ~4-5 seconds, not 10-15 seconds:

slow-vite.zip

I hope this helps to further improve. We are now scratching our heads to understand if we should stick with ViteJS or move to other solution.

[patak-dev]

Could your provide a cpuprofile? (using --profile, then P+enter after loads end)

About the stalled requests, you could try the new option in this PR (that I hope we could merge soon, and it will be in vite 5.1):

• feat(optimizer): holdUntilCrawlEnd option #15244

Also a good idea to check extensions: https://twitter.com/patak_dev/status/1745427465617433005

[exones]

@patak-dev Thanks for the quick response! I did a clean test with no extensions, with cold load + --profile and attach the new HAR (~25 seconds loading time) + Vite profile

vite-profiles.zip

Addition: after the first cold load, subsequent loads take ~10 seconds instead of 25 (with caching disabled in browser).
Hope it helps

[patak-dev]

You can open the profile in https://www.speedscope.app/ to review it

Some quick finds, 43% of the server time is spent on plugin-inject. It is better to find another way to do this. Maybe you could evaluate https://github.com/unplugin/unplugin-auto-import

sass takes another 22% of processing time, it would be better to switch to postCSS, but preprocessors may get a speed up if we merge #13584

You should also enabled cached fs trees, see: https://twitter.com/patak_dev/status/1734509163978301594

[g6th8b]

Is there any news on this we have the same issue and behaviour in the browser in our large app.

[patak-dev]

Check this comment #13697 (reply in thread), maybe you could share your cpuprofile and check it out with speedscope, and check the performance guide to see what can be applied to your app.